From plug-admin@lists.q-linux.com Wed Sep 18 15:27:27 2002 To: plug@lists.q-linux.com Subject: Re: [plug] email server question... User-Agent: Mutt/1.4i From: Rick Moen Quoting Ian C. Sison (ian.s@qsr.com.ph): > And of these points not a single ONE of these address anything > technical in nature, Technical comparisons of MTAs (Mail Transfer Agents, i.e. SMTP daemons) are difficult; meaningful ones, more so, because much is inherently debatable. Even the comparisons of throughput capacity I've seen have been such. (See remarks by J C Lawrence near the end of http://www.grin.net/~mirthles/pile/contra_majordomo_plus_MTA_stuff.html) Qmail (like Postfix) benefits from carefully modular design, with attention paid to trust relationships and the nature of inter-modular communication. (By comparison, both Sendmail and Exim both spawn as SUID-root processes, then drop privilege according to the role of each process. Many comments commonly seen about Sendmail are outdated in failing to credit it with that improvement: Sendmail processes formerly always used root privilege regardless of role. Fixing this design flaw seems to have very dramatically improved Sendmail security.) Per J C Lawrence, Qmail, Postfix, and Exim all seem to generate similar throughput numbers, with difference in system loading characteristics. Sendmail's in the same ballpark, but with less well optimised delivery and spooling. (Again, it's alleged that Sendmail's been improved in those areas.) Postfix and Exim both support all of Sendmail's command-line modes, which means either is a drop-in Sendmail replacement (once you have a suitable conf file). Qmail supports some of the switches, but not all. Qmail _can_ be made to support mbox format (via modifications to /var/qmail/rc to support procmail as your MDA (Mail Delivery Agent), or possibly other MDAs such as maildrop); author Dan Bernstein disapproves of mbox format, so you have to customise. Patches: Because of Dan's licensing (see below), third-party Qmail patches effectively never get regression tested against one another. In my experience, departing from the Dan-approved way, generally, tends to cause headaches. To pick one of the more extreme examples: Making it FHS-compliant would be a career in itself. (Not coincidentally, Dan disapproves of the Filesystem Hierarchy Standard.) Sendmail sports the Configuration File from Hell -- which in theory you can avoid by working only with m4 files. But somehow, everyone keeps getting sucked back into directly modifying sendmail.cf . There are still some types of rewrite rulesets and delivery modes that only Sendmail can do. (UUCP used to be a leading example; recently, Postfix and Qmail, at least, have been used with that delivery mechanism.) Arguments based on security history are dubious, for multiple reasons including failure to take into account fundamental changes (such as newer Sendmail versions dropping privilege according to process role) after some past incidents.[1] (If one were to judge MTAs on the basis of past exploits, then any brand-new MTA would automatically win without regard to merit.)[2] Build problems: Exim is/was reputed to use a rather eccentric and brittle Makefile setup. (Can't comment, and, if this was true, I'm not sure it still is.) Qmail suffers the peculiarity that Dan doesn't believe in automake/autoconf _at all_, and consequently his coding style is really strange and difficult to read, let alone port. It's not just that all source-code files are in a single directory; it's not even that the man writes his own custom replacement for stdio.h(!) -- you really have to try to read his code to understand how peculiar it is. If you run the GNU Mailman mailing-list manager, Exim has really seamless, easy, automated integration with it. (All four[3] MTAs will work well enough with the general run of mailing list software -- Mailman, Listproc, Listserv, Majordomo, Majordomo2, Sympa -- with varying degrees of hassle. Qmail can additionally work with ezmlm, which is Qmail-specific and closely integrated. Exim can be made to perform SpamAssassin checks on incoming mail _during_ the SMTP transaction, letting you reject detected spam without even accepting delivery: http://marc.merlins.org/linux/exim/sa.html Both Qmail and Postfix have easy virtual host support, and in general have administrative characteristics that scale well to large sites. Exim's configuration/administration is perfect for small sites. The configuration files for Qmail one either loves or hates; they're eccentric, in any event. Qmail's mail spool cannot[4] be backed up or migrated to a different host, because it uses inode numbers in spool filenames. (Dan feels this is justified for performance reasons.) Postfix does more or less the same thing. Last, of course, Qmail is the only one of the four under a proprietary (albeit generous) licence -- the main consequence of which is that the project cannot be forked, and that if/when Dan loses interest or dies, without some additional licence grant the package will become effectively unmaintainable and a dead project. Likewise, modified Qmail may not be distributed (except as patchfiles), nor may Qmail be ported, without Dan's explicit permission. [1] The people most often guilty of this fallacy are Qmail advocates, who also will characteristically speak _only_ of Qmail/Sendmail comparisons, whereas the most-natural comparisons would be Qmail/Postfix and Exim/Sendmail, on account of design category (modular vs. monolithic). My guess is this is mostly a holdover habit from the days when Qmail was the sole significant challenger to Sendmail's status as the default, standard MTA. However, it's also true that Sendmail is an easier, more-facile debate target than is Postfix. To that extent, this Qmail-fan-trademark debate tactic of targeting poorly-briefed Sendmail admins, and failing to inform them of the obvious third alternative, is a serious disservice to them. Ditto Qmail advocates' tendentious habit of begging the question by labelling designs differing from Dan's (e.g., Sendmail and Exim's being monolithic binaries that drop privilege according to role) as "not correct design". It is fallacious to try to decree security outcomes ex-cathedra by pronouncing a design "not correct": The proof is always in the pudding. [2] If one is studying MTA history regardless of its dubious relevance, one should be aware that Postfix had an extensive early history under its original name, VMailer, when it was a project mostly internal to IBM Corporation. [3] Courier, http://www.courier-mta.org/, should also be included in this discussion, but I don't know enough about it. [4] No longer true: Workarounds have appeared in the form of either of two third-party utilities, queue-repair and queue-fix, both findable via http://www.qmail.org/top.html. Either will let you migrate or back up Qmail queue contents without lossage. My thanks to Dek on the PLUG mailing list for pointing this out. -- Cheers, Live Faust, die Jung. Rick Moen rick@linuxmafia.com From rick Tue Aug 6 16:56:00 2002 Date: Tue, 6 Aug 2002 16:56:00 -0700 To: balug-talk@balug.org Subject: Re: [Balug-talk] Re[2]: [svlug] mail relaying, jitterbug and me User-Agent: Mutt/1.4i Quoting Bill Moseley (moseley@hank.org): > Can anyone give a basic overview of the differences between Exim and > Postfix, and when one would be preferred over the other? http://www.grin.net/~mirthles/pile/contra_majordomo_plus_MTA_stuff.html http://starbase.neosoft.com/~claird/comp.mail.misc/MTA_comparison.html http://mailsoftware.cjb.net/ http://www.zmailer.org/zman/ztut-some-comparisons.html http://www.debianplanet.org/node.php?id=641 ObDisclaimers: 'Ware obsolete data. Mind the gap. Cave canem. -- This message falsely claims to have been scanned for viruses with F-Secure Anti-Virus for Microsoft Exchange and to have been found clean. From: Ted Cabeen To: Ralf Dreibrodt Cc: WebMaster , debian-security@lists.debian.org Subject: Re: postfix in qmail out proftpd in pureftpd Date: Wed, 02 Oct 2002 13:17:34 -0700 In message <3D9B4C3A.F56AFBC0@mesos.de>, Ralf Dreibrodt writes: >I was talking about pureftpd. >qmail itself perhaps had no security problems, but other programs, e.g. >vpopmail or vchkpw. Exactly. IMHO, qmail has avoided many security bugs because it's feature-poor. Many new features that are provided as standard in other mail servers are unsupported patches to stock qmail. Thus, qmail avoids some of the holes that appear in other servers, because they are adding features instead of standing still. However, the underlying design concepts of qmail are quite solid, which is why postfix uses a similar architecture. That said, they're both very good mail servers, just with slightly different focuses. - -- Ted Cabeen http://www.pobox.com/~secabeen ted@impulse.net Check Website or Keyserver for PGP/GPG Key BA0349D2 secabeen@pobox.com "I have taken all knowledge to be my province." -F. Bacon secabeen@cabeen.org "Human kind cannot bear very much reality."-T.S.Eliot cabeen@netcom.com Date: Thu, 3 Oct 2002 00:54:01 +0200 From: Bastian Blank To: debian-security@lists.debian.org Subject: Re: postfix in qmail out proftpd in pureftpd On Wed, Oct 02, 2002 at 10:57:55PM +0200, Jose Luis Domingo Lopez wrote: > At least not for me. But a reward offered 5 years ago that not only > hasn't been awarded, but even has not even been asked for, maybe is a > proof of a piece of software without grave bugs in 5 years. http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html bastian RM adds: Above URL is a detailed list of unfixed qmail security holes / RFC violations. Elsewhere, a qmail fan posted a point-by-point rejoinder: http://www.geocrawler.com/mail/msg.php3?msg_id=9506623&list=513 Most of those rejoinders amount to "Yes, Qmail violates various RFCs and other conventions, but those RFCs and conventions are bad and/or inconvenient." The author of Courier-MTA wrote it largely in order to solve the problem of key functionality missing from qmail. See: http://www.courier-mta.org/history.html