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

[Sam Roberts]

Quoting Alain Magloire <address@hidden>, who wrote:
> > > > url_path.c: Expand ~/box to /home/user/box, ~foo/box to /home/foo/box,
> > > >   and +box or =box to /home/user/Mail/box.
> 
> This is now in mailbox/mbx_default.c:mailbox_create_default()
> i.e use this instead of the bare mailbox_create ().

Thanks, works great.

> > p.s. I'll mail you or put up for ftp whatever I've done with sieve
> > by sunday night. Remember, we're talking pre-alpha here, but it
> > might spark conversation on how it can be used.
> 
> Any news on this front?

Sure, I think it's about a 200k tarred and zipped, who would like
it mailed to them?

This works:

---- t-mailutils.sv --
require "fileinto";

if header :contains ["to", "cc"] "address@hidden"
{
        fileinto "+l.mailutils";
}
----------------------

$ sieve -f pop://address@hidden  t-mailutils.sv


I've spent the day doing a little tweaking, reading through some mailutils
source, the RFC that I'll need to implement to reject mails, etc. I need
to do some design work, and there are some API issues.

I don't want to on at length, briefly:

 - The mailer API will need to support submission of a message where
   the envelope from and to is NOT parsed out of the message.

 - I need to find a way to deal with IMAP and POP passwords. In the
   example I did above I was prompted, this isn't good. Also, the
   ability to do:
     fileinto "imap://address@hidden";
   is critical to me, so I need a way to either:

   1 - outside of the sieve script associate authentication information
       (what goes in ticket_t, user/pass, commonly) with a URL, maybe
       in a config file (.netrc? .sieverc?).

   2 - extend the URL syntax to include authorization information. I know
       the POP url syntax explicitly disallows this (and assume that
       its the same for IMAP) and I understand and mostly agree with that
       decision.
        
   But... if I can file mail into two imap accounts on the
   same server, with different passwords for each account, from the
   same script, then I need to build a good URL<->ticket_t database
   somehow. Also, if I do the simple thing which is have the user
   configure the URL to password mapping in a config file, which will
   work fine for me when I run a script against the Domino IMAP
   server what do I do when I take a sieve script and upload it to a
   good server that supports server-side filtering? The script is
   no longer so self-contained.

   There's also no security advantage. The "no passwds in urls" seems
   to assume urls will be public web pages, this isn't the case for
   me. Assuming that the user's sieve script, and the possible
   .sieverc both have permission 0600 in ~/, then there is no security
   advantage to having the passwords in .sieverc rather than the
   script, either way they have to be somewher on the system so the
   script can be run automatically/unattended.
   
   This could probably be dealt with with ACAP. ACAP has (it appears from the
   titles of some of the sieve-related RFCs) been extended to allow the
   storing of scripts on the server, I guess authentication information
   could be as well. Still no security advantage though, again we've
   moved the password out of wherever scripts are stored, to wherever
   ACAP (or LDAP, or whatever) data is stored.
 
 - Some other information that seems like configuration info, that might need
   to be gathered from a file, and thus the config file interface may
   be useful integrated into mailutils:

   - which mailer to use, smtp or sendmail <- especially this one
   - default mailbox
   - base location for mailboxes (~/Mail, etc.)

**

Next on my todo list is tightening up the logging and error reporting,
it's a little schizophrenic right now, then I'm going to implement
the redirect command. This will require the mailer to send a message
to a specified address, not to any of the addresses in to,cc,bcc, and
I'll also need to deal with configuration to figure out which mailer
to use.

Sam

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