Slashdot Mirror
The Exim SMTP Mail Server
A bit of history, first. Exim is currently in its fourth version, and is developed by Philip Hazel at the University of Cambridge Computing Service. The third release was accompanied by an O'Reilly book, also written by Philip, but there were enough fundamental differences that this release warranted its own volume. And what a book: more than 600 pages straight from the horse's mouth (as it were); you can't go wrong.
The structure is flat, being twenty-two chapters and two appendices long, but I'd say there were three main acts if you take it cover to cover. Philip begins with five chapters that introduce the reader to Internet mail, Exim, and some rudimentary runtime configurations. There's nothing to fear here, as the text is beautifully self-contained, covering topics from the DNS to routing lookups. As Exim's runtime configuration is both flexible and easy to read, the quite technical examples given early on can be understood without flicking to and from other chapters in the book.
The next four chapters cover in a rather succinct manner the parts of Exim that route and transport your messages. By this point you should have a grasp of the philosophy and design of Exim, which allows Philip just to give you the details. This section does feel most like a reference manual but I'm not sure there's another way he could present the information without confusing the reader. The remainder of the book covers each of the Big Features of Exim, one per chapter. I'm guessing that Philip just kept on writing until he ran out of features, rather than time or space! These chapters feel far more like the heart of the book, and the author treads a fine line between thorough process description and distracting technicalities. The two appendices cover regular expression syntax and special variables (both being available to Exim's configuration).
The book would be ideal if, for example, you manage a mail system on your own and don't have a great deal more admin experience close at hand. Its great strength is the vast number of scenarios that Philip has thought up; it seems that if you can think of something that you want the application to do, it'll be in there somewhere. At my site however we do have a good number of people who are familiar with Exim, so armed with a copy of the (equally well written) reference manual we can usually get along just fine.
Those expecting the chatty, irreverent style of an O'Reilly text may be in for a disappointment. Philip writes in a clear, precise manner, and obviously knows the subject matter (literally) inside-out; but there's no messing around and you have to be committed to learning about the subject in question. Having said that, I don't want these last two paragraphs to put you off. If there's even a whiff of a chance of you having to come into contact with Exim or its runtime configuration, then I can do nothing else but strongly recommend this book. The detail's there in spades, it reads very well, and is a fine complement to the reference manual.
For more information, see also the Exim home page, as well as this book's website. You can't yet purchase the book from American retailers, though if you're in a hurry, bn.com stocks the previous version. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Hefty 621 pages? The bat book is very nearly twice as hefty.
Random unproven MTA? I find that ironic coming from someone using sendmail.
If you want a drop in sendmail replacement, then maybe postfix would be a better choice.
Take the time to learn either qmail, exim, or postfix, you'll save more time in the long run.
Mandrake 9.1 defaults to postfix. I didn't look to see if sendmail was even an option.
So, it looks like we'll have our MS-Exchange replacement afterall?
Well, except exim actually works.
We are using Oracle Collaboration Suite, formerly known as Steltor CorporateTime formerly known as Netscape Calendar.
Server runs on Linux and Windows, clients are running on Linux and Windows. Multiple node ability, i.e. servers across continents are possible.
"Is it friday yet?"
Honestly, I don't know why Red Hat and others include sendmail.
Red Hat includes both Sendmail and Postfix on their CDs - sendmail is just the default.
You can install Postfix, and then use "redhat-switch-mail" to activate Postfix. And with that, you're running a not-Sendmail mailer.
That's because sendmail doesn't handle POP3 or IMAP, it only does SMTP. You can't criticise software for something it wasn't designed to do.
Then buy from Suse, they use postfix if I remember correctly, they have a webinterface that does everything outlook does, if I remember correctly, Outlook works with it too I think.
well, I haven't tried it, have no need for it.
New things are always on the horizon
Hold on just a second:
Yes, the daemon needs to be root initially, but it drops root privilages ASAP and does not, in fact run as root (unless you're insane and configure it to do so). Yes, it is a monolithic design, which may turn you off, but a remote exim exploit is not an automatic remote root exploit.
Personally, I like Exim a lot, and I haven't even upgraded to version 4 yet. Just be glad you have a choice of MTAs and aren't stuck with sendmail, as was the case not too long ago. (Though to be fair, sendmail is getting significantly better!)
noah
What, you mean like this? O'Reilly will give you a 30% discount if you own an older version of the book.
Fetchmail. He's grabbing his mail off of his ISP's POP3 server, and not accepting any with his smtp server. I had a similar setup and it worked quite well. It eliminated the 15 or so emails per day regarding how to lengthen my x-10 camera and refinance my viagra supply. Fetchmail seemed like overkill, though, so I used Getmail. Its written in Python, which should eliminate most/all buffer overflow exploits and its also very easy to configure.
http://www.masturbateforpeace.com/
To the Prince of Poop (The Anonymous Coward),
I'll even address your points one by one, and I'll use small words so you don't get confused.
1. It had a gigabit eth card on a 45 Mb DS3
2. Who said it used a single IDE drive? No one in their right mind would use IDE in a production environment.
3. Splitting the Queue works wonders, and yes the load was off the charts. I never said this machine is still running, or even how long it ran like that for. It ran like that for about an hour, we then blocked the spammer.
4. You also assume that this is the only machine on the network that handles mail? The load avaerage during that spammers time was well above 600. It also took about 36 hours to get all the mail out of the spool dirs.
So to the Arogant Prince of Poo, I say to thee... Get your head out of your ass and realize weird shit happens. Like I said, I've seen it, neither I nor the Box was very happy about it. And yes it was replaced 2 days later bye a dual proc box.
Why worry? Each of us is wearing an unlicensed "nucular" accelerator on his back.
Sig changed for readability by G.W.
Postfix, like Qmail, was designed with security in mind from the start, and uses multiple processes to enforce privilege separation. Basically, you can think of it as Qmail done right (no stupid license, much easier configuration).
:)
Exim, on the other hand, is a small, simple, easy-to-configure, and very flexible little MTA. It's monolithic, so it doesn't have privilege separation, but it makes it very easy to do some things that are either impossible or very difficult with other MTAs. It may not scale as well as the other three, but its combination of simplicity and flexibility can still make it an attractive choice.
I'd probably go with Postfix unless I needed the extra flexibility of Exim. On the other hand, I do (at present) need the extra flexibility of Exim, so that's what I'm currently using.
The second largest email provider in Germany has this in the mail headers:
Received: from [216.136.173.219] (helo=web14612.mail.yahoo.com)
by mx07.web.de with smtp (WEB.DE(Exim) 4.75 #2)
They have a Server farm of Linux boxen.
www.web.de
Maybe they are not as big as gmx.de (qmail on Sun), but from guessing the size of web.de (at least several million accounts) I would say it is save to say that exim is scalable.
Well, it's more work than just copying data. That's the easy part. Incoming mail messages must be delivered to the correct box. Some local users have mail forwarded elsewhere, which means rewriting some headers (to prevent mail loops and to document the path the message traveled) and stuffing the message back into the queue for delivery again. Other users take their mail locally, which means either appending to a file (which involves locking) or running a program like procmail to filter their mail. Either of these must be done as that user. Do it as root, and you take security risks; do it as some random user (like "nobody"), and you may not have enough permissions. Changing users to deliver a single message means interprocess communication and the creation and destruction of processes.
All messages (inbound and outbound) have another big hurdle to deal with. They must wait on the network. This is both because DNS can take some time and because remote servers can sometimes be very slow, allowing you to transfer only a few kilobytes per minute. Why does this matter? Well, if you hope to do 1000 messages per minute throughput, but each message takes 2 minutes to finish delivery, then you'll have 2000 processes running at once. This means your software damn well better be scalable with the number of concurrent processes! What if each of them uses 1 megabyte of private data? Then, you're going to need 2000 megabytes of RAM for those 2000 processes alone. Normally, it doesn't take a full two minutes to deliver a message, but sometimes servers will leave you hanging for longer than that. You could minimize memory usage by doing this with threads instead, but that makes programming more painful, and you'll need to adopt a dual model (several processes with multiple threads each) so that a threads-per-process limit doesn't cap your total capacity.
Complicating matters further is the queuing. For some applications, it would be OK to say "screw it" when there's a failure. But with mail messages, maybe part of the Internet is down and will be back in 30 minutes. Or maybe just the remote mail server is down. You need to retry, and you need to be intelligent about when you retry. If you retry every 5 minutes, you will crowd out all your other traffic with retries. Information about remote sites that are down ought to be propagated to other queue entries (or some kind of database) so that you don't have 1000 messages going to one remote site and have to learn the same lesson (that the remote server is down) 1000 times, each time tying up resources that could be used for other work that actually has a chance of succeeding in the near future.
Speaking of being intelligent with respect to separate messages that are all going to the same remote mail server, you don't really want to send 1000 messages in 1000 separate processes with 1000 separate TCP connections, do you? It's best to aggregate transfers like that. That's further overhead.
Also, back to queueing: what happens if you've delivered 573 of your 1000 messages to mail-server.example.com, but then suddenly mail-server.example.com breaks the connection in the middle of delivering a message? You want to mark 573 messages as delivered, and defer 427 of them until later (when you either explicity test or otherwise learn that mail-server.example.com is accepting messages again). You don't want to mark 1000 messages as delivered and defer/requeue none of them, nor do you want to mark 0 as delivered and defer/requeue 1000 of them. Nor do you want to mark 574 as delivered because you are counting one that's half-delivered. Oh yeah, and if you've accepted a message (locally or remotely) and promised the sender you have that message and will do your best to deliver it, you can't reasonably make the promise without having written everything to disk because of the possibility of power failure. So, every message sent and received requires at least one disk I/O at the point where you've taken responsibility for it and another w