cmu-sieve: starting to work, patch about paths.

[Sam Roberts]

The fileinto actions and the discard actions work for sieve
scripts, I've got more testing and and problems ahead.

I got REALLY irritated by haveing to type

$ sieve -f `pwd`/INBOX script.sv

Thus the following patch.

folder_mbox.c: If scheme has no ':' its not a url, adopt as a path. Fuly
  qualifying all paths sucks.
url_path.c: Expand ~/box to /home/user/box, ~foo/box to /home/foo/box,
  and +box or =box to /home/user/Mail/box. It tries to be smart about
  finding where /home is, or at least not too dumb, and it just assumes
  that your mailboxes are in ~/Mail, I don't know if there's some kind
  of standard environment variable for that.


If what it does isn't horrifying, how it does likely is, feel
free to rearrange, rename, or reject!

Sam

p.s. Anybody have an example of how to make an auth object? I
don't want a sieve daemon trying to prompt the console for
a password for pop and imap boxes, and that this implementation
of sieve will allow url specification of mailboxes since it's
based on mailutils is one of the cooler features of it.

p.p.s. If anybody is interested in a snapshot, let me know, I hope
to have the basic stuff working more robustly this weekend. At
that point I'd be interested in comments on how to integrate this
into a mail system. Right now it looks like:

$ ../sieve -h
usage: sieve [-hnvcd] [-f mbox] script

   -h   print this helpful message and exit.
   -n   no actions taken, implies -v.
   -v   verbose, print actions to be taken.
   -c   compile script but don't run it against an mbox.
   -d   daemon mode, sieve mbox, then go into background and sieve.
        new message as they are delivered to mbox.
   -f   the mbox to sieve, defaults to the users spool file.

So you run the sucker against a mailbox, and it filters it, and the
-d isn't implemented, but I was thinking that mailutil's observable
interface would let me sit back and run the filter on new messages
when I'm notified of new messages in the mailbox. Is that possible?

This would let people like me, who's companies use lousy proprietary
email packages but who grudingly give Unix users access to an
IMAP port, the ability to filter their mail on arrival in the
IMAP box to various local mailboxes, and to discard mail sent to
"everyone" from marketing.

The other useful thing would be to have it be able to act as a local
delivery agent, so it can accept mail from an MTA. Then I could
maybe get the envelope to and from addresses from the MTA, which
would be nice.

The spec talks about IMAP servers doing the filtering. This makes
me think that another possibility is that if the MTA delivers
mail by appending it to an IMAP INBOX, that maybe the IMAP daemon
could run the script on each new message it puts in the INBOX.
This would maybe fit into the funky "notify" proposed extension
to sieve.

Anyhow, food for thought.

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)

smarter-path.diff
Description: Text document