Ben Walton [Sun, 7 Jun 2009 23:44:37 +0000 (19:44 -0400)]
Bounce Message Hook
Determine the command used to bounce a message based on a Hook instead
of a configuration option. Instead of writing an external script that
can send the message properly based on the recipient addresses, rely
on a hook that can return the command based on the From header in the
mail being bounced as well as the intended recipients. This is more
in line with the sup philosophy.
The default is still to strip any -t from the sendmail command of the
default account.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Ben Walton [Sun, 7 Jun 2009 16:38:41 +0000 (12:38 -0400)]
Add message bouncing capability
Bouncing a message is akin to redirecting a mail with a .forward
entry. It is passed back to the mail system as it sits on disk.
By pressing ! while viewing a message, you can now re-inject it to the
mail system using either the command defined in bounce_sendmail or the
sendmail command for the default account with any instance of -t
removed. The user is prompted for the recipients of the message and is
offered a chance to confirm the bounce before it is sent.
The message is _not_ stored in the sent box, as this doesn't make
sense with bounced messages (and would not show up uniquely anyway).
The bounce_sendmail configuration item allows users that require
different sendmail commands depending on where the bounce is destined
to write a wrapper around their local mail tools to pick and choose
the appropriate injection method for the message based on the
addresses passed in. Most systems can likely use: sendmail -oem -i
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
William Morgan [Mon, 18 May 2009 19:12:25 +0000 (15:12 -0400)]
bugfix: label counts not set correctly on new messages
New labels were being deleted when label-list-mode was brought
up before they were sync'ed to disk. This fixes that, although
this whole thing should be changed. (See comments.)
Marcus Williams [Wed, 13 May 2009 09:02:31 +0000 (10:02 +0100)]
Chronic context fix
Chronic should use a context of :past for email date searches as emails
tend to be in the past. This fixes a problem when the wrong year is
guessed. To search for emails in the future you now need to be less
ambiguous (1 apr 2099 instead of 1 apr).
William Morgan [Mon, 4 May 2009 12:29:54 +0000 (05:29 -0700)]
make sup-sync's --start-at actually useful
Using --start-at with sup-sync will now seek forward to the next valid message
if given an offset that's not on a message boundary. This makes it possible to
use that option without going through the laborious process of finding the
exact message boundary.
Also die unless --start-at is used with only one source, since using it across
multiple sources is almost definitely an error. (And if that's really what you
want, you can just call sup-sync multiple times.)
William Morgan [Tue, 28 Apr 2009 13:34:27 +0000 (09:34 -0400)]
fix mbox splitting regexp
I dunno. This helps with the "From problem", but at the expense of being
too specific than the mbox spec really demands. I don't think there's a
really right solution, in general (due to the mbox format being a
fundamentally broken one), but I'm hoping this will work with all modern
mbox files.
William Morgan [Sun, 26 Apr 2009 22:18:26 +0000 (18:18 -0400)]
don't automatically parse header on Message#new
You must now explicitly call #parse_header (e.g. when loading
from the index) or #load_from_source! (e.g. when loading from
disk).
This prevents redundant loading from the source when adding to the
index, as #snippet must be called before adding, and that requires
loading the entire message from the source.
William Morgan [Sun, 26 Apr 2009 22:16:48 +0000 (18:16 -0400)]
make Index#sync_message take an extra speedy arg
Previously it would check the index if docid and entry were nil,
even though nil is a valid result of a previous check. Add an
extra argument controlling whether this check is performed again.
William Morgan [Sun, 26 Apr 2009 15:44:37 +0000 (11:44 -0400)]
change email header parsing. MASSIVE SPEEDUP!
restructure the email header parsing code to improve speed and to
improve API. MBox::read_header now returns a hash containing all
headers, with keys downcased but nothing else.
update Message#parse_header to accept this new format.
update unit tests to reflect new format.
The exciting news is that changes in how the parsing works have resulted
in a 480% speedup in message parsing speed (634 message/s vs 132
messages/s on my machine), across ALL source types. hell yes.
Resync listable_labels and applyable_labels with reality
The listable_labels method listed all labels except unread
which seems an unneeded complication/restriction, so it's
renamed to all_labels. The applyable_labels was in fact
user-defined labels so it's renamed to user_defined_labels.
When responding to an email with a recipient_email field (i.e. an Envelope-To
header), look up the name in the account list, but keep the original email
address.
William Morgan [Wed, 25 Mar 2009 15:49:56 +0000 (08:49 -0700)]
overwrite from and to fields in index when saving a message
See comments in the code. This allows you to forcibly update the from/to
address stored in the index for messages, which means you can correct
the bad stuff stored in there due to previous versions of Sup that
canonicalized email addresses.
William Morgan [Wed, 25 Mar 2009 13:25:48 +0000 (06:25 -0700)]
rework Rakefile for "rake gem" and "rake tarball"
Move version into sup-version.rb and filelist into sup-files.rb. Rake gem
now builds the gem; rake tarball builds the tarball. No Hoe involved.
Update release-script accordingly.
William Morgan [Wed, 25 Mar 2009 12:33:45 +0000 (05:33 -0700)]
make ThreadIndexMode#save optionally threaded
The call to #save during #cleanup needs to block because this is where
state gets saved immediately before exit. Other calls to #save, e.g.
those triggered by "$", can be backgrounded.
William Morgan [Mon, 23 Mar 2009 15:55:09 +0000 (08:55 -0700)]
don't add :unread and :inbox for dupes
Allow merging in of labels from duplicate messages, EXCEPT for
:unread and :inbox labels. (These two have special semantics
and, in contrast to the other special-semantics labels, might
appear on a new message.)