[Mailman-Users] Re: MTAs
dman at dman13.dyndns.org
Sat Mar 26 14:53:48 CET 2005
On Fri, Mar 25, 2005 at 11:55:46AM -0800, Heather Madrone wrote:
| We were going with Debian,
| which then announced that it's dropping sparc support,
Hold up. Debian hasn't announced any such thing. Don't pay attention
to the rumors. Some of the project's leadership *proposed* (notice
that it's just a proposal) and different way of supporting 11+
architectures and making releases manageable.
Even if the proposal is accepted, it doesn't say anything about
*dropping* any architectures. Rather, it proposes that the less
popular arches be managed independent from the most popular ones.
Sparc would still be supported, as long as anyone cares to use it.
| so we've switched
| to OpenBSD.
| The time has come to start seriously thinking about the MTA.
I recommend either postfix or exim. I use postfix now, and it is
rather easy to setup, has good performance, and can be instructed not
to trash the machine its on while under heavy load.
| OpenBSD comes with sendmail, but I'm not going down that road again.
| I've heard good things about postfix, but I've never used it.
| It seems somewhat more complex to set up than exim,
postfix is simpler because all of the logic is built-in, you merely
fill in some tables. I had quite a bit of experience with exim before
I started using postfix. postfix has better rate- and resource-
| and its integration with Mailman does not
| seem to be as seamless.
Its integration is nearly perfect -- see README.POSTFIX. All you
really have to do is put an entry in $alias_maps (and one in
$virtual_alias_maps if mailman will serve virtual domains) and you're
There is one hitch, depending on your setup, which is discussed here:
Grr. pipermail needs much better MIME support =p. You'll have to
read the message from me from the mbox archives instead:
but it won't matter to you unless the domain you specify in $mydomain
is in $virtual_mailbox_domains.
I'll comment on a few items from other posts in this, since I happen to
have a bit of knowledge in this area:
> I've seen Exim's logs. I was never able to make much of any sense
> out of them. I've also seen postfix's logs, and they seem to me to
> be the model of readability and understandability.
As a former expert on exim, exim's logs are extremely informative, but
they're also quite terse. You have to know how exim organizes things
before they'll make any sense, and then you have to know what the
single-character codes mean before you know what data you are seeing.
postfix logs everything very well. Each step of the process is
logged, and isn't anywhere near as terse as exim's logs. Both provide
adequate information to identify and correct any situations that will
> * Ease of configuration and administration.
> Postfix is the only MTA on the planet that can have a truly useful
> two-line configuration file. Moreover, it has the most intelligible
> configuration file that I have ever seen. Better still, it comes up
> "default secure", unlike every other MTA I've ever seen.
> I've seen Exim configuration files, and it's hard to tell what goes
> where, what is a router versus all the other ways that certain
> things could be handled, etc...
exim is only semi-easy to configure and administer. postfix is
easier. exim's model requires you, the administrator, to put together
all the pieces needed for mail handling (access control, routing,
transports) and then it requires you to put the logic in place so that
the right components interact the way you want them to. The biggest
drawback is the verbosity in the configuration file. The second
biggest drawback is the trickiness in correctly setting all the
conditions to handle very unusual and strange situations.
I would say that exim is actually more flexible than postfix, since
the admin controls so much of the logic. However, postfix is simpler
because Wietse already put all the logic in the code and the only
responsibility of the admin is to fill in the tables correctly.
> When looking at Exim and Mailman, there is a distinct issue that has
> to be kept in mind. The instructions for integrating Mailman 2.0.x
> are oriented exclusively towards Exim 3.x, and the instructions for
> integrating Mailman 2.1.x are oriented exclusively towards Exim 4.x.
> If you've got Exim 3.x and you want to use Mailman 2.1.x, you're
> no one should be installing and running Exim 3 these days.
I agree -- exim 3 is extremely old, no longer maintained, and exim 4
greatly simplified the configuration. I think it has been three or
four years, now, since exim 3 passed the torch on to exim 4, and I
can't think of any -good- reason to use it other than perhaps "if it
ain't broke, don't fix it" (but that includes not upgrading or
installing a new mailman on the exim3 server).
> With exim, trying to do VERP processing on the digest runs caused
> Mailman to flood exim, even when I turned the number of sessions and
> connections way down. It also brought my poor Mac, which was not
> meant to be a server, to its knees. I'm hoping that the sparc will
> be able to handle peak loads more gracefully than a Powerbook.
Have I got a story for you! I'll try to keep it succint. Basically I
moved from NY to IL for a co-op job a few years ago. While I was
moving, my computer was offline and so I couldn't receive any mail.
Due to circumstances, I couldn't get a public IP for a total of about
4 days. As an interim solution, I tried setting the router at my
parents' house as my backup MX. That router is a 25MHz 486 that had
8MB RAM at the time. The problem came when mail servers around the
world (ie lists.debian.org and others) noticed an accessible MX for my
domain. The ensuing load literally killed the machine. exim forked
too many processes causing extreme thrashing and the linux kernel's
OOM killer killed everything including init. I couldn't do anything
until I went back to NY and even then only a hard reboot was possible
(no init -> no ctl-alt-del).
Fast-forward a couple years to another time I moved, and didn't have
any network for a week or two. I again made that router my backup MX.
This time it was running postfix, and I told postfix to accept at most
2 simultaneous smtp connections. During that time the machine had no
problems, and I was even able to read my mail remotely while I was at
a conference (albeit slowly).
The difference is this: exim is wholly decentralized, and so it
didn't even know it was trashing the machine. It does have a
load-based limiter, however the problem on that router wasn't load
(cpu), it was memory. postfix has a central "master" process that
oversees all the other processes. With this mechanism it is capable
of limiting each component, such as incoming connections or the
various deliveries. For example, I now limit both the junk-scanning
and local deliveries to 2 (each) simultaneous processes. This
prevents bogging down the CPU when the network is restored after being
down for a time (eg a few hours or a day). I just let the messages
sit on the queue a bit longer, which isn't a problem since the machine
remains usable (it's my desktop/workstation too).
> How would you rate Postfix's efficiency? Is it fast?
Rather outdated now, but here is an empirical comparison:
> Does it limit network traffic to the necessary and keep its disk
> reads and writes down to a dull roar?
See the above narrative on how a woefully underpowered machine fared
when bombarded with mail running exim vs. postfix. (actually, that
was precisely the reason I started using postfix -- because it was
better suited on that machine _as a server_; then I learned how much
easier it is to use and have stuck with it)
My preference of MTAs is postfix, but exim is a good second choice,
IMO. Also, both Phil and Wietse (the authors) are quite respectable
-- they help users while providing quality software and addressing
"...the word HACK is used as a verb to indicate a massive amount
of nerd-like effort." -Harley Hahn, A Student's Guide to Unix
www: http://dman13.dyndns.org/~dman/ jabber: dman at dman13.dyndns.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://mail.python.org/pipermail/mailman-users/attachments/20050326/42d26159/attachment.pgp
More information about the Mailman-Users