[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: |
Alain Magloire |
Subject: |
Re: cmu-sieve: starting to work, patch about paths. |
Date: |
Mon, 28 May 2001 00:34:05 -0400 (EDT) |
Bonjour
> > > 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?
How about to commit it in mailutils/sieve, the old template can go, it
was done in an hour on a rainy day.
> 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
Much cool.
> 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.
Proposal for the API extension?
>
> - 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?).
How about ${HOME}/.mailpass, without too much effort I can quickly
write(during the week) an auth_t/ticket_t that will fetch the user/pass in
the file and send it. Should make your life easier?
>
> 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
Actually, I think there is a bug in the IMAP client, its trying to be too
smart and will not open a second connection for the second mailbox you
create since it is on the same hostname. So when you do things like
mailbox_append_message (), it checks the hostanme and maps This to
a COPY command instead of downloading the entire message and resending back
again. I will not bother correcting this since I'm rewriting the IMAP4 client.
(See other mail on the mailutils documentation).
> 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.
ACAP or maybe RADIUS?
> 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.
Why not extend sieve to incoporate a new cammand like ":passwd" or something
and put in sieve-scrit.sv:
require "passwd"
require "fileinto";
passwd ~/.mailpass
if header :contains ["to", "cc"] "address@hidden"
{
fileinto "+l.mailutils";
}
In this specific case, when you move your sieve script you will have to move
the .mailpass also.
>
> 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.
And even in .mailpass have a redirection to the ACAP server. Is there
an URL std for ACAP? icap://..
> - 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.)
Jakob was suppose to come with a generic (mail) configuration scheme ...
but he's a little busy and will be for quite some time 8-(.
>
> **
>
> 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.
<Wish>
If you ever tackle the configuration problem, can you try to make it generic
so it can be reuse?
--
alain
- Re: cmu-sieve: starting to work, patch about paths., (continued)
- 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, 2001/05/27
- Re: cmu-sieve: starting to work, patch about paths.,
Alain Magloire <=
- 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