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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
