Re: Postfix as default MTA?
On Mon, Jun 28, 1999 at 03:26:14PM +0200, Christian Meder wrote:
> On Mon, Jun 28, 1999 at 11:30:22AM +0200, Thomas Quinot wrote:
> > Wietse Venema just announced that, starting with the latest snapshot
> > (19990627), Postfix will be released under the IBM Public License,
> > which is DFSG-free.
> >
> > Postfix is generally regarded as being far more secure than other
> > MTAs such as Sendmail or Exim, and is also very fast and easy to
> > configure.
> >
> > My personal opinion is it would be great to make it the new default
> > MTA for Debian GNU. What do you think of this proposal?
>
> First let's put it in main and wait a few months until more developers
> gave postfix some real world experience wrt configurability. If
> postfix is fast that's nice but the _default_ Debian MTA should be
> _very_ configurable too as it's used in setups ranging from dialup
> home systems to heavily loaded mailinglist managers.
I agree with the proposal to make postfix debian's default mailer, and
i also agree with your suggestion to trial it in main for a few months
first. there are bound to be some issues which we need experience in
dealing with before we can recommend it as the default MTA...would also
be good to come up with a sendmailconfig type script for postfix.
i've been using postfix since around December last year...here's some of
my impressions about it:
postfix is secure, very fast, and very configurable...and it's probably
the easiest of all the MTAs to configure. in short, it's an ideal MTA -
it has all of qmail's advantages (speed, security), with none of it's
disadvantages (incompatibility, license, attitude problem); it is a
"drop-in" replacement for sendmail; it's very easy to configure; it has
excellent anti-spam features (including regexp header checking).
the regexp header checking alone is worth it - i've been wanting that
feature for years...it has many uses, e.g. it's great for blocking spam,
and it can be used to protect majordomo's *-outgoing exploder aliases.
postfix would also be useful on lists.debian.org as the anti-spam check
can be applied at any stage of the receipt...so we'd finally be able to
block spam sent to aliases and .forwards.
postfix's modular design makes it simple to extend - for example, i
wanted X-Envelope-To: headers added to mail being delivered to virtual
mail domain pop accounts (to allow for sorting/filtering based on the
envelope RCPT TO address rather than just the To: header). it took me
less than a day to figure out how to write a "vpop" transport (a shell
script which uses formail) to do that - with no previous experience in
writing transports for postfix.
> I have got no postfix experience yet and I want to compare it to exim
> before judging if it's better suited as Debian's default MTA.
i've installed postfix on many debian systems - it is now the only MTA
i install (after trialling all of the MTAs offered by debian, i had
previously settled on both sendmail and qmail, depending on the type
of system i was building). it works well on systems of all sizes, from
mail servers for small offices and schools to big mail servers and list
servers for ISPs, and it's built-in LDAP support makes it ideal for
corporate environments.
(apologies for the length of the following example...but i need to
describe the problem as well as the solution)
one system provides a great example of why postfix is so good. this
machine is a P-166 with 64MB RAM. it only runs two smartlist mailing
lists (announcement/newsletter type lists, not discussion lists), one
with ~50,000 and one with ~23,000 subscribers...both growing by several
hundred new subscribers per week.
under sendmail, a message sent to a list would take around 6-8 hours
before it was even finished queuing, with the load going up to 11 or 12.
the messages would then be delivered over the next day or so.
with this many subscribers there were a lot of bounces due to users
changing ISP or whatever. when a bounce arrived, sendmail would deliver
it to smartlist immediately (sendmail's model is based on delivery ASAP,
not queueing). this resulted in several dozen of procbounce scripts
running simultaneously, all reading and writing the smartlist dist
file. load average sky-rocketed. with luck, the machine would just keep
running very slowly. more often than not, though, the machine would run
out of file descriptors or memory (causing random processes to die) or
just lock up. as the lists grew, we could count on at least one crash
per mailout.
i finally decided to switch it to postfix...i'd been putting it off
because the machine was so important. even though it died under sendmail
we were reluctant to risk changing something that sort-of worked. i
should have done it much sooner. the conversion to postfix took less
than half an hour (admittedly i had practice installing postfix on other
machines by then).
the speedup was phenomenal. postfix didn't take 6+ hours to queue the
mail and a day or so to deliver it. it had *delivered* nearly all of the
mail within 2 or 3 hours of the message being sent, the only queue items
left were those to hosts which were not accepting connections.
the way it handled bounces was brilliant, too. instead of immediately
delivering incoming bounces to smartlist, postfix just put it in the
queue. the queue manager (qmgr) then delivered them, with rate limits
set by various configuration options. even the default settings had
no more than 4 procbounces running at one time. since postfix was
installed, the load average on that machine has never gone over 4, and
it hasn't crashed once.
queuing mail rather than attempting immediate delivery is a big
win...not only does it keep the load down to reasonable levels, it
actually ends up delivering the mail much sooner.
the switch to postfix has gone so well that there is no need to upgrade
the machine (we were considering replacing it with a dual PII/256MB),
and it is now running two more mailing lists (with less than 5000
subscribers each so far)
apart from qmail, nothing else could have performed anywhere near as
well. the problem with qmail is that it would have taken days to get
smartlist working (i have managed to get both smartlist and majordomo
working with qmail on other systems...it's possible but ugly. majordomo
particularly so)
postfix gets my vote. it just plain works, even under extreme load.
anyone who is comfortable with de-facto standards like /etc/aliases and
.forward should have no trouble coping with postfix - everything works
exactly as you would expect it to work.
(another neat feature of postfix is that you can have multiple
aliases files - makes it easy to have a script which generates all
of the aliases required by majordomo lists...e.g. /etc/aliases and
/etc/aliases.majordomo...no need to worry about preserving the
non-majordomo aliases because they're in another file)
craig
--
craig sanders
Reply to: