[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cmu-sieve: starting to work, patch about paths.
From: |
Sam Roberts |
Subject: |
Re: cmu-sieve: starting to work, patch about paths. |
Date: |
Sun, 27 May 2001 21:44:30 -0400 |
User-agent: |
Mutt/1.3.16i |
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!)
- Re: cmu-sieve: starting to work, patch about paths., (continued)
- Re: cmu-sieve: starting to work, patch about paths., Alain Magloire, 2001/05/10
- Re: cmu-sieve: starting to work, patch about paths., Sergey Poznyakoff, 2001/05/10
- Re: cmu-sieve: starting to work, patch about paths., Sergey Poznyakoff, 2001/05/10
- Re: cmu-sieve: starting to work, patch about paths., Sam Roberts, 2001/05/11
- Re: cmu-sieve: starting to work, patch about paths., Alain Magloire, 2001/05/19
- sys_siglist compatibility., Sergey Poznyakoff, 2001/05/21
- Re: sys_siglist compatibility., Alain Magloire, 2001/05/22
- Re: sys_siglist compatibility., Jeff Bailey, 2001/05/22
- Re: sys_siglist compatibility., Alain Magloire, 2001/05/22
- Message not available
- Re: sys_siglist compatibility., Jeff Bailey, 2001/05/22
- Message not available
- Re: cmu-sieve: starting to work, patch about paths.,
Sam Roberts <=
- Re: cmu-sieve: starting to work, patch about paths., Alain Magloire, 2001/05/28
- Re: cmu-sieve: starting to work, patch about paths., Sam Roberts, 2001/05/29
- Re: cmu-sieve: starting to work, patch about paths., Alain Magloire, 2001/05/30
- Re: cmu-sieve: starting to work, patch about paths., Sam Roberts, 2001/05/30
auth_t/ticket_t() was (Re: cmu-sieve:starting to work, patch about paths, Alain Magloire, 2001/05/14
Re: cmu-sieve: starting to work, patch about paths., Sam Roberts, 2001/05/26