Choosing a new MTA
Nicholas Gareth John OBrien
a bit *wonky* ]
Hi,
We are in the need of some advice and were wondering if the people on
this newsgroup could help please.
We are a large university in the UK and we currently use PP as our
central email system. We are planning to replace PP this summer due to
the fact support is being dropped for it, and we have been seeing
major performance problems with it.
We have been looking at several possible replacements: sendmail,
exim, qmail, zmailer, Post.Office, MMDF, Netscape Messaging Server,
PMDF, and the Sun Internet Mail Server (SIMS). At the moment exim
and sendmail appear to be the front runners but we are keeping our
minds open.
What we are planning to do is to choose the best 2 or 3 alternatives
and then test them in the Spring and move to the best one during the
summer.
We would be grateful to hear what people's advice and suggestions
not only on what would be the most suitable replacement for PP
but also on the best way to proceed, and other related matters.
Below is the configuration of our mail server:
Sun Ultra Enterprise 3000
Solaris 2.5.1 (although we are planning to upgrade to 2.6/2.7)
512Mb RAM
c. 450M swap
8.6Gb mail spool
and below are our general requirements for our mail system:
- Local delivery
Should be capable of delivering to local mailboxes for access though
one of the required client protocols.
- SMTP with RFC822 addressing
- POP/IMAP access
Client mail reading should be permitted via both the POP[3] and
IMAP[4] protocols. (This is not necessarily a function of the MTA
software, but it should do local delivery to a mailbox format for
which POP and IMAP servers are available, with appropriate locking to
avoid data loss caused by race-conditions.)
- Hub (== relay/router)
The server should be able to relay mail on to internal MTAs, possibly
after performing header rewriting. The internal MTAs should be
subject to special forwarding rules and not use normal DNS/MX-based
routing (which external mail will use).
- Scalable: we're [currently] handling...
* ~60,000 message deliveries per day (~20,000 messages in)
* ~20,000 users with local mailboxes
* ~500 lists (currently PP mlist and majordomo)
* ~20 'subdomains' (internal MTAs)
(not only ability to handle, but practical to manage a system of this
size)
- Aliases
Both with and without header re-writing.
- Lists with:
* open/close membership
* hypermail archives
* hierarchical and meta-lists
* majordomo / mlist compatibility/migration
(We are resigned to migrating our PP mlist based mailing list
to another package).
- User-controllable processing:
* .resend / .forward
* .filter / .procmail
(perhaps with PP migration / compatibility support, .resend)
- Monitorable with good logging / debugging
Included spot-debugging of troublesome domains / users (c.f. current
PP tactic of putting domain into test channel and looking at that).
- Supported / well-used / 'current'
With active / helpful user base, mailling list, etc. Either
commercial through helpful company or freeware (of some description)
with helpful community.
- Integration with UNIX/NIS
As all our email user accounts are in our NIS password file.
- Configurable / flexible
Capable of doing everything listed here + extra things in future.
'Plug-in' support through shell services, etc.
- Easy to understand
So easy to debug, maintain, etc.
- Secure through design
No cryptic management with unforeseen holes, etc. Run as root only
when necessary, etc.
- Testing
Ability to test / dry-run delivery / configuration (much like PP's
ckadr command).
- Multiple domain support
Through envelope rewriting and relay.
- Aim for "single-point" configuration
e.g. add the details of a mailing list to a file and all the appropriate
tables, configuration entries, WWW page archives, etc. are created.
- Block list
Blocks by user, domain, hosts to eliminate spam problems, unregistered
IP addresses, etc.
Rgds.,
Nick
--
========================================================================
"Who are you? What do you want?" - Lorien, B5
Nick O'Brien Phone: +44 118 931 8432
Computer Officer Email: N.G.J....@reading.ac.uk
Reading University, UK Web: http://www.rdg.ac.uk/~suq98ngo/
Bennett Todd
>We are in the need of some advice and were wondering if the people on
>this newsgroup could help please.
Always. Just try to _prevent_ people from advising you in these parts:-).
You've got a pretty long shopping list there. Looks like you're already on top
of this, but do remember that some of your checklist items aren't MTA; POP
daemons and IMAP daemons are a separate issue, and interoperability with an
MTA is not a problem --- the POP or IMAP daemon is just another MUA. And
mailing list management is the job of your mailing list manager, and threre
are plenty of nice choices there.
One of your items I really like, since I regard it as one of the more
important issues, and it narrows the choices right down:
> - Secure through design
> No cryptic management with unforeseen holes, etc. Run as root only
> when necessary, etc.
That makes it easy: Look at the only two candidates, qmail[1] and Postfix[2].
They are similar in a lot of ways. Personally I prefer Postfix for most
settings. The other MTAs are not secure through design. And in fact, I don't
expect that they are secure.
While it's not entirely, perfectly relevent, I attatch a note I wrote recently
comparing MTAs, mostly from a point of view of how they came to be.
[1] <URL:http://www.qmail.org/>
[2] <URL:http://www.postfix.org/>
-Bennett
------------------------------------------------------------------------------
(
posted by Bennett Todd to the inet-access mailing list at
1998-12-30-19:16:40 GMT under the subject
"Re: Postfix Vs. Sendmail"
)
1998-12-29-20:25:39 Rick Stockley:
> I hate to start this but, we are looking at switching from sendmail
> to postfix. I remember some discusion about postfix before. I would
> love to hear pro's or con's for switching. Any takers?
Whew. This should help warm up a cold holiday season:-).
Sendmail is an amazing piece of work. It has been the experimental reference
implementation of a great many new features in mail transport agents for c. 20
years now --- it was the reference implementation during the development of
SMTP. When sendmail was developed, the problems it needed to address included
routing email properly between many different mail systems, including Bitnet,
CSnet, Berknet, UUCP, and arpanet email, with SMTP under development; many,
perhaps most of these required message format conversions as well.
Since then, the problems an MTA has to solve have gotten a lot simpler. A vast
majority of sites need nothing but SMTP transport, DNS MX-record routing, etc.
--- the normal internet email setup. A few sites need more exotic things, but
nothing as flamboyantly evil as the neighborhood where sendmail grew up.
Bitnet was JCL batch queues bolted together over leased lines. The kind of
thing you don't look back on fondly:-).
So sendmail carries a lot of complexity baggage with it that's no longer
needed to do the job. That complexity baggage can be found residing in
sendmail.cf, the single nastiest configuration file to be found anywhere on a
modern computer system.
Meanwhile, sendmail also grew up in a kinder, gentler age, when _nobody_
outside of military intelligence (ahh, love that phrase) was thinking about
design principles of secure software, confining authority, access domains, and
so on. Sendmail is a _very_ large and complex piece of software; it's an SMTP
daemon, an SMTP client, a queue manager, a rewriting engine, etc., all in a
single humongous setuid-root whale of a binary.
Furthermore, when Eric Allman started writing sendmail back in the late '70s,
nobody had ever done the job that sendmail ended up doing --- most of the job
spec evolved during the lifetime of sendmail. This is a critical point: the
only way to come up with a really great design for a complex problem is to
have a pretty good understanding of that problem when you start. It's amazing
that sendmail has survived as long as it has. Sendmail is no longer a good
design for an MTA.
Given this background, the time has clearly come to revisit the design of an
MTA. The first serious attempt I know to bring modern security and performance
concepts to bear on the current email environment was Zmailer; it didn't get
widespread acceptance, but it certainly opened peoples' eyes to a better way
of looking at the problem.
Meanwhile there were a couple of other MTA efforts; I'm specifically thinking
here of smail and exim; but they're sendmail replacements, single monolithic
programs; by and large their big claim to fame is they don't have a
sendmail.cf file, but they don't have a superior security architecture.
Then Dan Bernstein <djb> came up with qmail. Qmail was very, very close to
the last MTA the world needed. It's got a beautiful architecture, it's fast,
it's magnificently secure, it's reasonably simple to configure, it's almost
perfect. Only problem is, it's maintained by djb, and not just everyone can
get along with djb. There are a lot of people who don't want to use qmail
solely because of djb. If Dan doesn't like something, that something won't be
supported or worked around or whatever by his code. If Dan notes that mbox
delivery to an NFS-mounted mail spool cannot be made 100% perfectly reliably
in all settings, his code will not support NFS-mounted mail spools with mbox
format folders. Just to name a for instance:-). More broadly, goals that
qmail does not attempt to pursue include effortless drop-in compatibility
with sendmail, and workable SMTP interoperability with every other MTA in the
universe no matter how broken.
So this left a Wietse-shaped hole. Wietse Venema is another respected
security-minded Unix systems programmer. Over the last couple of years he's
been developing his own MTA, just released a few weeks ago under the name
Postfix. It's very, very fast, possibly a little faster than qmail at the
extreme margins (I'm not certain about that). Pretty likely no slower than
qmail. It's got a strong security architecture. It's very very easy to
configure and maintain. It has been used in a lot of high-traffic production
settings for many months now, by people on the closed alpha testers list.
Wietse is out to replace sendmail. If someone has an environment where Postfix
cannot fit, because it's missing some important feature, then the discussion
will be about how to best add the missing functionality to Postfix and when
that can happen, not whether the someone should rearrange their environment to
fit Wietse's preferences.
Postfix is still really, really young; until a few weeks ago only a few
hundred people had a chance to bang on it, and I'd say only a few dozen at
most really hammered it and grovelled around through its bowels. Shortly after
it was released, djb pointed out a design defect, that made it possible for
local users to possibly disrupt email sent by other local users, if they are
willing to blugeon the system to death in the process. djb regarded that as a
horrific, catastrophic disaster. The rest of us regard it as a nit worth
fixing, while we chuckle at the shrieking djb over in the corner:-). A
workaround to further narrow the vulnerability was posted right after the
initial comment, and a comprehensive fix was just released.
Where do things stand now? I've been using Postfix since early in the closed
alpha; I'm very glad to be running it on every machine where I have a mailbox,
and happily deploy it into production on client machines and low-visibility
mail servers. I'll probably be willing to deploy it on really high-visibility
critical mail servers after it has weathered a couple more months of public
review and use, and will replace qmail on high-visibility firewalls protecting
major critical resources in maybe a year-ish, assuming no important security
problems are ever found in Postfix.
As to whether you should use it, I'd strongly recommend switching from
sendmail to _either_ qmail or Postfix. <URL:http://www.qmail.org/> and
<URL:http://www.postfix.org/>, respectively. Personally I like Postfix better.
D. J. Bernstein
> More broadly, goals that
> qmail does not attempt to pursue include effortless drop-in compatibility
> with sendmail,
Your information is horrendously out of date.
dot-forward, the final component necessary for sendmail compatibility,
was released in 1997, when my department at UIC replaced sendmail with
qmail. It's a fully supported option in qmail 1.03.
> and workable SMTP interoperability with every other MTA in the
> universe no matter how broken.
What are you talking about? There's quite a bit of code in qmail to deal
with garbage from broken MTAs. Exactly which MTA do you claim has
trouble talking to qmail 1.03?
> If Dan notes that mbox
> delivery to an NFS-mounted mail spool cannot be made 100% perfectly reliably
> in all settings, his code will not support NFS-mounted mail spools with mbox
> format folders.
qmail has always been able to deliver to NFS-mounted mboxes. I couldn't
prevent people from using unreliable filesystems even if I wanted to.
However, unlike commercial UNIX vendors, I have no interest in hiding
the fact that these filesystems are unreliable.
[ the IBM Secure Mailer ]
> Shortly after
> it was released, djb pointed out a design defect, that made it possible for
> local users to possibly disrupt email sent by other local users, if they are
> willing to blugeon the system to death in the process.
With the first public release of the IBM Secure Mailer, any local user
can anonymously watch the mail queue and destroy selected messages. No
``bludgeoning'' is necessary.
> djb regarded that as a horrific, catastrophic disaster.
I said nothing of the sort. You'll have to ask your users how disastrous
they think message destruction would be.
> I'll probably be willing to deploy it on really high-visibility
> critical mail servers
Under the IBM Secure Mailer license, you are required to destroy every
copy of the software upon IBM's request. Has IBM granted you some sort
of special exemption from this threat?
---Dan
Dana Booth
suq9...@news.reading.ac.uk (Nicholas Gareth John OBrien) wrote:
> We have been looking at several possible replacements: sendmail,
> exim, qmail, zmailer, Post.Office, MMDF, Netscape Messaging Server,
> PMDF, and the Sun Internet Mail Server (SIMS). At the moment exim
> and sendmail appear to be the front runners but we are keeping our
> minds open.
FWIW, I'd been happily running Exim on two machines, when a
person I'll not mention pointed out that he'd had some concerns
over the security of Exim. This person is involved in UNIX pro-
gramming, and said that while he'd not had the time to do a full
review of Exim, an initial grepping through the source exposed
some code that deserved further investigation, in his opinion.
This concerned me, and I wrote to one of the Exim people in
England, and asked if there were any documents available
regarding any security auditing or other such stuff undertaken
by Exim or any other sources. The reply I received was very flip,
and suggested that maybe I ought to go do it.
Since then, I have installed Zmailer on the two machines. When
Postfix became available, I installed it on one of them, replacing
Zmailer.
Both Zmailer and Postfix have performed very well. I know that
both are still in heavy development, and security is a high
concern with each.
Anyway, just my $0.02.
---------------------------
Dana Booth <dana[at]oz.net>
Tacoma, Wa., USA
---------------------------
Philip Hazel
|>
|> This concerned me, and I wrote to one of the Exim people in
|> England, and asked if there were any documents available
|> regarding any security auditing or other such stuff undertaken
|> by Exim or any other sources. The reply I received was very flip,
|> and suggested that maybe I ought to go do it.
I'd better respond to this, as the author of Exim. I hope it was not I
that gave a "flip" answer, because that would never have been my
intention. If it was, I apologize.
In the Exim manual there is a chapter (chapter 50 in the latest edition)
which attempts to describe the ways in which Exim addresses some
security concerns. It starts with the following paragraph:
For reasons that this author does not understand, some people have
promoted Exim as a 'particularly secure' mailer. Perhaps it is because
of the existence of this chapter in the documentation. However, the
intent of the chapter is simply to describe the way Exim works in
relation to certain security concerns, not to make any specific claims
about the effectiveness of its security as compared with other MTAs.
Exim does not introduce any new security model. When I started to write
it, I was interested in extending the facilities provided by Smail 3, and
being a newbie in MTA writing, I essentially copied the security model,
though I did arrange for it never to run as root when actually receiving
or delivering messages (in the recommended configuration). [And here I
mean setuid not-root rather than seteuid not-root.]
In early versions of Exim I made the mistake of not being paranoid enough
about some of the string-handling functions. (If only I could have written
it in a better language than C ... but that's a different point.) This was
tidied up around 18 months ago. However, I don't know of anybody who has
done any kind of formal "code audit". Clearly I am not the right person to
do this.
The authors of qmail and Postfix have both introduced new models of
security. This is a Good Thing in general because it extends the thinking
on how to do these things. As I understand it, there has been a lot of
discussion (to put it politely) about some of these issues. The conclusion
I draw from all of this is that Unix plus C is not a good environment for
writing this kind of program. If it were, everybody would know what the
One True Way was.
Sorry about the length of this. It is an attempt to put the record
straight. I am not trying to persuade you (or anyone else) to run Exim. I
wrote it for use on our systems. The fact that some other people like it
and run it is gratifying, but of course there are always competing
products with different pros and cons. As far as software goes, the
phrases "one size does not fit all", "horses for courses", and "better
mousetrap" will always be relevant.
--
Philip Hazel
University Computing Service, Cambridge, England.
Giulio Concas
I'm looking for an e-mail Server who can manage 500,000 mailbox, adn
implement SMTP, POP3, WebMail and IMAP.
I need that this system can authenticate the users via LDAP with my
accounting server.
I've have just seen many solution, commercial and free, but the only
who have been tested with so many users is "Software.Com", i've read
there is many other self-made solutions based on free SW, like qmail.
Someone know any solution???
I can buy a solution based on modified version of free SW.
Thanks Giulio
Timothy Brush
really tricky... especially since the scaling of the hardware and software
is slightly different for each protocol. To complicate things,
administration can be a real bear and service levels hard to maintain.
Questions (to help zero in on the appropriate solution):
1. Are you required to use a commercial solution?
2. Are you looking for a single or multi-vendor solution?
3. What level of vendor support (hardware / software) is required
/acceptable? (24X7, business hours, none)
4. What is the time frame for implementation? (1 week, 1 month, 1 year)
5. What is the current solution and do tools exist to aid in migration?
6. What service levels are considered acceptable? (performance, uptime,
troubleshooting)
7. What level of knowledge will be required of the administration staff?
(account administration, maintenance, support, programmers)
8. What budgetary constraints exist? (unlimited, 1 million, 5 million,
$250,000)
Unfortunately the above list is too short an analysis. To properly
design an electronic mail infrastructure that can support that number of
mailboxes, it has to be properly architected. I have previously designed a
500,000 user solution for an ISP using Sendmail 8.8.x, Qpopper 2.x and
Procmail 3.x... I have also worked with a 50,000 user LDAP directory and
IMAP / Web-based mail solution... all of the above questions came into play
sooner or later... and scaling the environment for these 2 cases were
completely different.
Other concerns that should be considered:
1. DNS (critical to electronic mail)
2. Security (with 500,000 mailboxes, probably critical as well)
3. Bandwidth (500,000 users, estimate 1 - 2 million messages/day -
average size 2 - 4 KB, internet users, more if corporate users)
(Note: rough estimates from past experience)
4. Footprint and power requirements (most data centers are just too full
these days... ;-) Odds are you won't have a single server)
Although I have unfortunately not really offered any hardware/software
solution for your problem, the list of solutions should be reduced
considerably with the answers to the above questions. If you have any
questions, please let me know. :-)
Timothy Brush
mon...@yahoo.com
mon...@zdial.com
Giulio Concas wrote in message <36ACAB51...@tiscali.it-xxx>...