Re: MTA Suggestion
On Sun, 9 Nov 1997, Jason Costomiris wrote:
> On Mon, Nov 10, 1997 at 09:16:01AM +1100, Craig Sanders wrote:
> : qmail might be excellent at what it does but it's incompatible with
> : /var/spool/mail.
>
> Yeah, and? It allows you to streamline your quota setup. It also allows
> you to have a smaller /var.
so? why is having a smaller /var so important? if you're storing enough
mail that it becomes an issue then /var/spool/mail should be a separate
partition or disk.
what does "the qmail way" allow you to do with quotas which you can't
do with the standard /var/spool/mail? i can think of one thing which
the standard way allows which the "qmail way" doesn't: having separate
quotas for /home and /var/spool/mail
> : the one time i installed it, i couldn't even get it to use procmail
> : as the local delivery agent instead of qmail-local
>
> Why do you need to do this? If your users need to sort their mail,
> it's quite easy to use procmail in conjunction with a stock qmail
> setup. You just need to read the FAQ.
The FAQ told me how to use it from a ~/.qmail file. i didn't want to
know how to do that (it's damned obvious), I wanted procmail as the MDA.
there are several reasons why i need to do this:
1. i don't have to have a "|procmail ..." .forward or .qmail file in
every user's home dir.
i see procmail as an INTEGRAL part of my systems' mail capabilities,
not as a tacked on piece of cruft.
2. procmail is part of my 4 tier spam filtering system.
- ipfwadm blocks connections from known spam-only networks like
cyberpromo and the nancynet scum.
- sendmail check_* blocks incoming spam from known spam domains
and spam users, and also prevents spammers from hijacking my
systems
- procmail as local delivery agent catches a large percentage of the
spam which makes it through tiers 1 & 2 with a handful of simple
rules in the system-wide /etc/procmailrc file
all spam caught at this stage is saved in
/root/mail/probable-junkmail, and i read through it every so
often. so far, it hasn't caught anything which it shouldn't
catch...if it ever does, i'll just bounce it to the intended
recipient.
This probably-junkmail folder is also used as food for the
check_* rules. When I have time, i go through it and extract
all the addresses and add them to either /etc/mail/Spammers or
/etc/mail/SpamDomains.
- anything which makes it through that can be caught by personal
~/.procmailrc files
yes, i could do all this another way. i don't want to. i've spent a lot
of time developing my anti-spam system and it works well. it takes me
only a few minutes to implement on every new system i build.
I have a cron job which uses make and ssh and scp to transfer
the various anti-spam rules files (e.g. /etc/mail/Spammers,
/etc/mail/SpamDomains, /etc/mail/SpamNets, /etc/procmailrc) to the
systems which i am responsible for. Any new rules on my anti-spam
"master system" (my workstation siva) gets propagated to all of my
systems and to several of my client's systems.
i suppose i should write up how i do all this as a howto
one-of-these-days<tm> - it's fairly simple to do and makes use of
commonly available tools.
> : there's also the 'minor' problem that only a few MUAs (i don't know of
> : one except for qmail-popper) will work with qmail's new maildir format.
>
> Uh, there's maildir2mbox, which you can use for that task. In addition,
> qmail comes with wrappers for pine and elm.
great. so i have to quit pine every so often and restart it so that the
wrapper script can move my mail to where it should have been in the
first place.
> : it's anti spam features don't seem as good as Claus Assman's check_*
> : rules for sendmail 8.8.x (which have been included with the latest
> : debian sendmail packages in unstable). they certainly don't seem
> : anywhere near as flexible.
>
> Uh, I've done a good deal of work constructing a set of check_* rules
> that I use to restrict relaying and drop spam. qmail was a snap by
> comparison.
what's so difficult about adding the following lines to
/etc/mail/sendmail.mc?
# to block incoming junk
HACK(use_spammers)dnl
HACK(use_spamdoms)dnl
HACK(check_mail)dnl
# to prevent relaying
HACK(use_ip)dnl
HACK(use_relayto)dnl
HACK(check_rcpt4)dnl
> : but the biggest problem with qmail is the author's attitude. it would
> : be fine if he said "here's the way i like things to run, so that's the
> : default...but if you prefer the old standard ways then make this change
> : and that change and everything will run sweetly". but he doesn't do
> : that, he says "the old ways suck so you can't have them. you have to do
> : it my way even if my way sucks for your particular setup. tough luck".
>
> Yes, Dan Bernstein is called the "Psycho Programmer from Hell" by many.
> However, qmail rigidly implements the RFCs governing SMTP mail, which
> is a Good Thing, IMHO.
yes, sendmail could be improved. and it is being improved all the time.
there's a very active development team working on making sendmail
better.
qmail might have some good features, and it might conform to the RFCs
a bit more closely than sendmail does, but i still don't see any
compelling reason to use qmail rather than sendmail. Maybe if i needed
to run huge mailing lists i might consider a dedicated server running
qmail.
> : he goes on about nfs locking problems with NFS, ignoring the fact
> : that most NFS locking problems are related to sloppy programming.
> : debian has managed to produce an NFS safe locking library, so it's
> : obviously not impossible. and any site running an automounter daemon
> : for user home directories would be overloaded by qmail insisting on
> : delivering mail to ~ (and would still suffer from the NFS locking
> : problem he is so worried about)
>
> As opposed to the machine becoming overwhelmed from delivering to
> a /var partition that's mounted accross several machines, as you
> suggested with home dirs?
the point was that his NFS argument against /var/spool/mail was
irrelevant because home directories are often NFS mounted too (and
would therefore suffer from the same potential problems) - and in that
situation, the load would be much worse because the automounter would be
mounting and unmounting user home directories whenever mail arrived.
> : finally, qmail is non-free. debian CAN'T use it as the default MTA.
>
> Hmmm.. It can be freely distributed, once the author approves of it.
> See ftp://koobera.math.uic.edu/www/qmail/dist.html for more info.
which means that it's non-free according to the debian free software
guidelines, which is what counts since we're talking about debian's default
MTA.
craig
--
craig sanders
networking consultant Available for casual or contract
temporary autonomous zone system administration tasks.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: