[KLUG Members] Forward with Sendmail

[members@kalamazoolinux.org]

>>Or, you can do it the right way, and run a real mail package like Cyrus
>>IMAPd and let users setup forwards/filters/blocks via SIEVE.  Then you
>>get really good vacation message functionality, etc... which otherwise
>>really sucks on UNIX/LINUX unless your a procmail hacker.
>/me tentatively raises his hand... :)

You were one of those kids that kept asking questions even after the bell rang
for the last class of the day?

>I'm not a procmail guru, but regexp and pipes (and the vacation program)
>aren't a huge deal. The most difficult thing about .procmailrc is setting
>the order in which the lines go.

The standard vacation program leaves a lot to be desired, frequently responds to
list postings (making you much hated) and has a long history of security issues.

>Logrotate, for instance, is nice enough, but it doesn't allow for much
>creative log file scripting. On the one hand, this reduces errors. On the
>other, this reduces possible new functionality. I just had a typo in the
>venerable (1987) savelog bash script -- nothing huge, just a missing
>double semi-colon in a select block -- but that did cause two daily
>scripts to abort. (More, if I hadn't moved this functionality to
>logrotate.)

I though one could embed scripts via pre and post rotate in the logrotate
configuration?

>However, I find myself looking at sieve with a certain amount of
>misgiving. I'm not saying the Cyrus people should have replaced it with
>procmail, as sieve is a different beast. And yes, I have written and
>installed a small sieve script by hand, using vacation and all that. But I
>do wonder about replacing much of the script extensibility of Unix with
>Another Small Language.

If you want a *L*O*N*G* litany of security problems then the procmail changelog
is an ideal candidate,  and I've read several posts by "intelligent" people who
think the procmail paradigm is fundamentally insecure.  Hence SIEVE.  SIEVE is
not a programming language, all it can do is filter messages and other related
tasks,  this is very much on purpose.  So it is less extensible by design, and
it certainly can't call out to arbitrary code, again by design.

>I've been looking at ESR's bogofilter:
>http://www.tuxedo.org/~esr/bogofilter/
>http://www.paulgraham.com/spam.html
>At CARES, I've installed the Cyrus POP3 server (hopefully a precursor to
>installing IMAP). I would be unable to try bogofilter except for Exim and
>procmail. See, cyrdeliver is the "local_deliver" transport, but the
>local_deliver transport is, by default, second choice to the "forward" or
>"procmail" transport. Which is to say, if you have these files in ~, Exim
>routes accordingly. So everyone else uses POP3 and I use procmail, which
>is just how I like it.

I'm not familiat with bogofilter.  But one problem evidenced here is
scalability, as this all results in forking.  Cyrus, SIEVE, and MDA-via-lmtp is
purely socket communication and thread allocation.  This performs much better.

>Now, when will the Cyrus people adapt bogofilter, or some future successor
>to bogofilter, into sieve? Or will I have to filter all mail through
>procmail, and have procmail deliver it with a cyrdeliver command to my
>particular internal mailboxes? Or should I pipe the mail, in exim.conf,
>through a bogofilter command that itself calls cyrdeliver?

I think this is the wrong approach.  If you need to filter ALL mail, as in a
virus filter, you should be using a milter daemon.

>What happens when you get a spam that gets filtered into your Inbox?
>Bogofilter has a method to retag a message, but how does the IMAP user use
>it? Since IMAP leaves one great function to the user, that of moving mail
>to and fro, I would imagine a Spam folder for mail tagged as spam, and a
>Toggle-Spam folder, where you would copy misdirected mail for the
>reassignment procedure.

I'm not familiar with bogofilter, which I think this pertains to.  We block
troublesome sources via sendmail's access control rules, which are stored in LDAP.

>The other method.... well, is pretty insecure. Burying code (even shell
>scripts and options) in sieve is scary. 

I believe this is deliberately impossible.

>I do hope, however, that ACL's,
>fine-grained permissions and threads allow Linux a lightweight sandboxing
>utility, and that we do can and do use it.

These certainly help.

>Anyway. This is just me bringing things up that have no practical value.

Maybe, but its fun.