[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

    - 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

      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

    - 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

    # to block incoming junk

    # to prevent relaying

> : 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

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

> : 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


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: