procmail (in)security

[Matthias Andree]

Todd Underwood <todd-bogofilter at osogrande.com> writes:

> since i run qmail primarily for its security properties, introducing 
> something as complex and with such a poor security record as procmail is 
> definitely a no-no.

As a side note, when talking about qmail and security: The default qmail
1.03 install has always been prone to a memory exhaustion exploit (now
the fifth year...) via qmail-smtpd. Dan later stated it was the admin's
task to put proper resource limits in place -- however the qmail
documentation doesn't tell you that.

Also, qmail's maildir delivery code was found to be faulty quite some
time ago (Early 2001 IIRC) and again in a wider discussion earlier this
year; it is not robust and can cause name collisions that result in mail
loss later unless you only access with qmail-pop3d.

If you want a secure and robust mailer, consider Postfix. It has indeed
had a similar fault to qmail's, but that was fixed long ago; the maildir
delivery code has been fixed, and Postfix supports chrooting to some
extent and is way faster. The drawback is that Postfix doesn't read
.qmail files. It understands ~/.forward+extension files (with one level
of extension) if the admin configured recipient_delimiter=+ though.

> and, as you said, the recipies are complex.  very few people i know are 
> able to get them right with any regularity (and testing always involves 
> bouncing or losing mail).

The most common mistake -- to my belief -- is the omission of

:0e
{
        EXITCODE=75
        HOST
}

after each other recipe that makes sure that mail doesn't end up in the
wrong mailbox to the user's surprise on write errors ("disk full, quota
exceeded, ...")

> i'd take maildrop or just .qmail files any day.

Maildrop is indeed easier to use and more robust when the user hoses his
.mailfilter file.

-- 
Matthias Andree