Not to be outdone and at the risk of being accused of reviving a dead
horse...
On Sun, Jan 06, 2002 at 07:45:33PM -0500, Paul Lussier wrote:
>
> Sorry to be so late in responding to a thread which has not only been
> beaten to death, but pretty much buried already as well
> :)
>
[snip]
> Procmail doesn't need to deal with the folder format, all it has to
> do is invoke a command which *can*. For example, with mh style
> folders, I have procmail invoke the 'rcvstore' command which delivers
> the mail to the right folder and updates that folder's index files.
[snip]
> IMAP is for the transport of mail from server to client. Why would
> you use IMAP to deliver local mail? Mail comes in via smtp or esmtp
> gets handed of to the local mailer for deposit into the users mailbox
> and you're done with the server side of the problem. Getting the
> mail *to* the user now becomes an IMAP problem. Sorting/filtering
> the mail is a server side/local delivery issue best solved by the
> local mailer. This may be procmail, slocal, or any number of local
> mailers.
Well, actually, I concede that procmail may actually be the right
solution. But there are still advantages I see with sieve: it's now
an rfc (I forgot the reference), and part of the rfc is a defined
protocol (running on port 2000) for transfering scripts. There's
nothing wrong with retrofitting this to transfer procmail scripts
and put them in the right place. However, in the sealed server
situation, procmail may still allow too much, security wise.
I'm not sure there any commands that Cyrus provides that can actually
work with different folders of a user's mailbox. If not, that's actually
missing functionality from Cyrus, though, not a weakness with procmail.
> >I would think that procmail would need access to the user's password to do this?
>
> Why? Procmail is running *as* the user invoked by the MTA acting as
> the local mailer or MDA. There's no need for passwords here.
But can procmail run as a user only in my /etc/sasldb database? With Cyrus,
all mailboxes files are actually owned by the cyrus user.
> > If I'm not mistaken, sieve actually gets wired into the local delivery
> >process which in this case is cyrus-imapd, so the index files for each
> >folder will get updated correctly.
>
> Can you wire sieve into procmail instead so procmail acts as the MDA
> and invokes sieve to do the filtering/sorting?
>
> I know between little and nothing of cyrus imapd so I have no idea
> how it deals with it's folder format. But it seems to me that the
> imap daemon is a step removed from the mail delivery process. There
> has to be something between MTA and the IMAPD, namely the local
> mailer, no?
Yes, there is, but Cyrus handles that as well. The local mailer for
Cyrus is 'deliver'. Imapd and pop3 as well as sieve are all part of
the Cyrus package. I'm actually not sure where sieve comes in, but
I think it's called somehow by deliver.
> > Of course, I could be blowing smoke, too. :-)
>
> Well, there is that, but that just makes you like all the rest of us
> who do this for a living ;)
Here's what I see as basic requirements for mail filtering:
o Should allow operation on sealed servers -- i.e.: it needs to know
how to find usernames/mailboxes, regardless of format.
o Allow for the transfer (and maybe syntax verification) of scripts
back and forth between any mail client and the server without
needing anything but the mail client. The transfer should be
secured (ssl/tls) as well.
o Be powerful/flexible. (None of this crap that most search engines
have implemented as well as commercial mail clients: I WANT MY REGEXes!)
o Should be executed upon mail delivery like procmail.
o Should be able to notify any IMAP clients currently connected of new
mail in any folder when it arrives.
Someday I'll actually *learn* procmail *and* sieve as languages so I can
speak more authoritatively on both :-). For now, I'm just looking at the
how each ties into the mail system. Sieve may turn out to be more limited
as a language, but so far I think the way it ties into the mail system is
more to my liking.
--
-Paul Iadonisi
Senior Systems Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************
