Re: MTA Suggestion
On 11 Nov 1997, D. J. Bernstein wrote:
> > i couldn't even get it to use procmail as the local delivery agent
> > instead of qmail-local
>
> Change ./Mailbox to '|preline procmail' in the qmail-start invocation.
why isn't this in the FAQ?
> > qmail might be excellent at what it does but it's incompatible with
> > /var/spool/mail.
>
> qmail can run binmail as the delivery agent the same way sendmail
> does.
>
> Of course, I don't recommend this, since many systems have insecure
> versions of binmail. See, for example, CERT advisory 95:02.
on the other hand, NOT all systems have insecure versions. Some of
your concerns, especially re: security are quite valid....others,
however, like your insistence that ~/Mailbox is somehow superior to
/var/spool/mail, are too context-dependant.
For those that are insecure, there are other (less drastic) ways of fixing
the problem. e.g. 'login' is insecure on some systems...does that mean
that unix should throw away the entire method, or should it just fix the
problem? too many other things break when you arbitrarily make such
radical changes to the system.
The fact is that, for most people, the few improvements offered by qmail
are not worth the price of changing the way the rest of their systems
are organised.
> > it's anti spam features don't seem as good as Claus Assman's check_*
> > rules for sendmail 8.8.x
>
> By default, qmail refuses SMTP mail not addressed to the local host. You
> can selectively allow relaying from particular IP blocks; see FAQ 5.4.
what about relaying TO particular host/domain names?
> > debian has managed to produce an NFS safe locking library,
>
> That is incorrect. Debian mailbox locking will fail under high loads.
>
> libfilelock_0.1-2, like every other dot-locking library with stale lock
> removal, requires that clients actively refresh locks within a specified
> period of real time. Unfortunately, UNIX is not a real-time system.
i haven't tested this under high load conditions so i'll have to take your
word on it.
> > 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.
>
> maildir is an _option_ in qmail and mutt and exim. It is not the
> default; if you don't want it, don't use it.
>
> I find it very strange that you refer to this as a ``problem.''
what's the point of having your mail in this great new format if you
cant find a mail reader which can use it? i happen to dislike the way
mutt works, so i do see that as a problem. There are many MUAs which work
with /var/spool/mail mailboxes, there are several which can trivially be
modified to use ~/Mailbox. There is 1 which works with maildir.
> > and any site running an automounter daemon for user home directories
> > would be overloaded by qmail insisting on delivering mail to ~
>
> By default, sendmail looks for .forward in the user's home directory.
> Either you suffer through automounting or you have unreliable .forward
> handling.
>
> Of course, you can move .forward somewhere else---but the same is true
> of .qmail and Mailbox.
which illustrates the point i was making, which was that your NFS-based
arguments against /var/spool/mail are equally as valid against qmail's
~/Mailbox.
maildir may have some advantages in an NFS environment, but it reminds
me too much of the *.MSG format of fidonet - one file per message -
which gets obscenely slow when there are many files in a directory.
> > in summary, i think that his reasons for doing things the way he
> > does are, for the most part, ill-informed opinion and bigotry.
>
> Security and reliability are not matters of opinion.
there's more than one way to skin a cat.
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: