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.
If it's not broken, don't fix it.. But if you don't know it, don't learn it if there's something that's pretty much as good but much easier..
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.
I understand windows, I like windows, and windows works. Forgive me if I don't feel the need to use some random unproven OS.
Security is the answer my friend.
I've just spent enough time to learn how sendmail works that I don't see learning yet another MTA as being especially necessary. Besides, you can do some neat stuff with sendmail.
------------
At my organization we use it to relay around half a million messages per day
Yo Ralsky ! Loong time no see buddy !
All jokes aside, half a million messages/day isn't really that much. Does anyone know which software the spammers use ?
When will I end this grieving ? When will my future begin ?
Sorry, I have to post this as an AC..
My employer has ~5000 employees across Canada. We have 8 or 10 MS-Exchange racks around the country (one per location and a big one in Ontario).
Two dual Xeons for primary and backup and another for the domain controller. I *know* how much traffic we have and this is gross overkill. Mind you, Exchange needs a lot of horsepower for the bloat. Anyhow, some rough numbers showed that we could eliminate all the Exchange servers with a *single* dual CPU FreeBSD 5.x box running Postfix.
Would the bureaucrats listen? No, in fact one fellow gave an ultimatum that if we didn't run Exchange, he'd quit.
So around the country we have little Unix systems popping up that act more reliably and without the spam (we use blackhole lists)
I use Exim on my home network. It runs on my firewall machine (yeah, I know... probably not the safest thing to do, but port 25 is blocked from coming in... it's local only) so that my wife, kids and I can use it as our SMTP server, to quickly send stuff out. I also use Fetchmail, SpamAssassin, and Procmail to filter spam and nasty attachments. We use IMAP, so everything gets backed up from one place.
I use Exim, because when I installed it with Debian, it asked about 5 reasonable questions, and then it just ran. That's it. There's no point in trying to learn Sendmail's complex file format, when we only need to serve 4 users. It's a great way to get an e-mail server up and running quickly for a small network. I was quite surprised, though, about the post above that said they use it for 1/2 million messages a day! I didn't know it could handle such a big load!
dochood
FUD! It seems that people don't realize that sendmail 8.12 now has an excellent security model and very advanced queuing features. In fact, in comparison qmail in particular looks very outdated.
We used to use sendmail at work. The justification being that's what we always used, and that's what the support contracts listed.
Then the mail admin was on vacation for a week, and nobody noticed the security alert for the remote relay exploit. A spammer found us, and we had to shut down all mail for 6 hours until we could figure out what happened. And are still trying to get our IP off some spam lists.
Since then, we've gone to exim, and it justs works.
If anybody needs half a dozen sendmail books, let me know :)
Do you even lift?
These aren't the 'roids you're looking for.
I'm having trouble understanding why people here are trashing exim; as someone else already said, Debian uses it as their default mail server; it asks a few easy to understand questions, and just works. It's much friendlier than sendmail.
:-).
As for security, I haven't audited the code myself (honestly, have you?). However, I *do* subscribe to the BUGTRAQ mailing list, and have seen maybe two advisories on exim over the last two years -- as opposed to literally dozens for sendmail.
Oh, and the configuration file doesn't look like line noise
ERROR 144 - REBOOT ?
I work at an organization with over 34,000 employees. We tried Linux/Sendmail, it was too complicated and the admin GUI sucked. We switched to Exchange, but the box had pointy edges and was hurty.
Realizing that it was all very complex, we emailed all our employees their final message. It was a link to the SMTP RFC and a short list of instructions on how to use Telnet. Then we shut down the mail server and ate lunch.
Management reported an immediate profit increase projection for that month. While I'm sure this was due to productivity improvements facilitated by my fine IT department, some skeptical colleagues of mine think it was the mass exodus of employee resignations that took place around the time the new "mail system" went into place. I'm sure it was due to the rat problem in the cafeteria but nobody will listen to me.
# Erik
I seen EXIM handle over 750,000/hr on a little old 450mhz desktop with 265Mb ram. It is very easy to install and configure. We had it handling over 120 domains (5000+ users), with spamfiltering (spamassassin).
I like it. No it's not as configurable as sendmail, but nice and easy to deal with.
Why worry? Each of us is wearing an unlicensed "nucular" accelerator on his back.
Sig changed for readability by G.W.
Exim does not want to be extended, it wants to assimilate everything, making the result too big to be understandable by anyone
.haeger
So, it looks like we'll have our MS-Exchange replacement afterall?
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
" To steal ideas from one person is plagiarism; to steal from many is research. "
For those saying that exim code is a crap, Philip is
also the author of PCRE - Perl Compatible Regular Expressions, used in many others GPL softwares, like
postfix and apache.
So i will asassume, after looking the organized and helpfull exim code, that Philip codes very well.
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?"
What a steaming pant-load! I work for what you might interpret as a "spammer", we send out millions of messages today. There's no chance in hell that you're getting 750,000 per hour out of a 450mhz desktop PC.
/dev/nulling the inbound bounces -- you're still going to be using disk time since you've gotten your box into swap with all those outbound messages. Has it reached your ankle yet? Oui oui!
I've built big mail systems in the past four years around qmail and postfix both.
1. You need a sustained ~9 megabits per second link to handle a 5K message at that delivery rate. On top of that, there are tarpits, connection limits per MX host, and all manner of obstacles thrown up by ISPs (both national and local). qmail and postfix do not have the capacity to intelligently handle these sorts of things. Exim is no different. You've tried to pinch it off, but you've failed.
2. Regarding mail IO (gotta store the message somewhere in order to deliver it). And don't give me that "transient" shit - you're not going to queue that much mail in memory since you've only got 256mb. So, you're obviously going to either THINK you're queueing into memory and it's going into swap or you're queueing directly to disk. Your little IDE spindle drive is not fast enough. You'll need, at minimum, a dual-drive SCSI array. Also, remember that each process, thread, and network connection takes RAM! You've got everything in swap at this point! Can you feel it sliming its way down the back of your leg yet?
3. CPU time. So your little 450 is handling bounces and delivery. Yes, there's inbound non-conversational bounces to process. Holy god! Now we have double the disk I/O load on the poor box! Writing to the queue or simply
4. What's your load average? Even if you dicked with the kernel enough to allow that many inbound connections, I promise you, the source ISP is going to give up since it's going to take 10 minutes for the SMTP connection to respond. You've tarpitted yourself. Your load average is probably well over 200 at this point. Your Linux 450mhz super box is now choking on cocks and you're leaving a nice little shit footprints behind you while you walk into HR to collect your pink slip.
And I do realize you're talking about INCOMING messages. Local delivery or remote delivery, my points above are still valid. Sorry scat head, you lose.
There's nothing wrong with Postfix. My experience with it was that it seemed to be well written, solid, and capable. But I never could figure out the configuration files. I looked at the docs and read everything. But I never *grokked* them. On the other hand, Exim was a snap. I understood what I was looking at right away.
There are those who say exactly the opposite: they understand Postfix, but have no clue about Exim's configuration files. So now what I recommend to people is to stay away from Sendmail, then look at both Postfix and Exim. Pick the one that seems most natural to you, and stick with it.
If tits were wings it'd be flying around.
I've never understood the *nix reaction (although it has spread to windows/regular PC users) that escalates any difference in opinion to a religious war...
That being said, I have experience on three of the "big four" MTA's out there (sendmail, qmail, and exim) and currently use exim on my personal site (which also hosts a number of mailman lists for OpenSource project and friends of mine) and it handle's about 20k messages in/out on a linux box.
I also use qmail on my work servers (cluster of quad-procesor ultrasparcs) and although I can't say I would have chosen qmail if I'd been in charge of building the servers (I inherited them from "the architect") it handles millions of emails a day just fine.
I can't say i miss m4 (although I know real sendmail admins don't bother with wimpy scripting languages), sendmail also served it's purpose back in the day.
Could exim handle the load on the ultasparcs? possibly, I haven't checked. Could I put qmail on my personal box? sure, but if Exim works, why not.
To comment further on one thing, Philip has a good explination of monolithic vs modular on the exim website, which explains why he does things the way he does. At least read it before blindly attacking the system.
Please send all UCE to scally@devolution.com so I can f
I ordered the book on Exim version 3 from Amazone, and by the time it turned up (2 months later) Exim 4 was released :o(
If only they upgraded books in a similar fashion to programs - some kind of discount from the previous version would probably encourage more people to keep their library up to date. (Although in this instance the migration from 3 to 4 was pretty painless.)
Beep beep.
As every spammer knows, the more you send out, the more $$$s you make!
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Exim finally getting a guide for the masses is a good thing. It is true that postfix has a leg up in some areas, but I really like the configuration style and the ability for me to process 100,000 messages per hour vs. 50,000 messages per hour just isn't that big of a deal, just as it isn't for most people, since we don't come anywhere near that volume.
Also, when you're connecting it to a database backend to pull all the delivery info as I and many others do, it's going to be orders of magnitude slower on both platforms anyway.
Hopefully in the future exim can polish off some more of the rough edges, but in the mean time, it's still a damn nice tool.
Answer me this then - how do I get all mail going through my qmail system (not setup by me, but I'm one of the admins) to go through SpamAssassin, but with per-user settings - i.e. after the decision has been made on who to deliver the mail to - without losing the ability to use .qmail files? Oh, and ideally without lots and lots more patching - there's a lot to be said for a stable system, but it's a real problem when the author doesn't seem to be planning any more releases, but the license forbids people from distributing patched releases...
Or to put it another way: qmail may be better for security, but I've had a lot of trouble working out how to hell to administer it, since it seems to ignore most of the tradition UNIX rules on 'how stuff works' in favour of newer, cooler, but random-seeming rules...
Paranoia isn't an infectious condition, it's a way of life
Yes. I've used qmail, Exim, Postfix and all of them perfomed better and delivered mail faster than sendmail. They're also easier to configure. I'm using Postfix now because I can't cope with /var/qmail and well Exim was pretty damn good too, but I got too used to Postfix. Haven't tried 4.x yet, but I was very pleased with Exim 3.x when I used it. I've also heard that zmailer performs well too. With the recent root compromise bug, Sendmail is not an option. Blah blah, it has new features and everything but it's still the same old crappy sh^H^H sendmail.
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/
IMHO. Exim and Postfix are each remarkable mail systems in their own right and have way simplified the process of setting up a mail server.
;) It is wonderful... especially since the config files make sense (at least, it does to me). I never truly had control of sendmail because I didn't really understand everything in the config file.
I myself have switched to using Postfix both at work and for my home server
Yeah, well, that's why some qmail people are moving to Courier instead.
I started with qmail, because I liked Maildirs much better than mbox format. But then I needed an IMAP server. And then I needed a webmail server. And then I needed e-mail filtering.
So instead of installing all the pieces separately, I just installed Courier.
While the DJB-style configuration directories are kinda interesting, I perfer Courier's more mainstream configuration files.
Still using DJBDNS though. Small and simple, which is what I like.
If it's baroque, postfix it ....
Infuriate left and right
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
Admittedly, it's kind of a small one- but I wasn't able to find a single document for it online. Evidently you're supposed to look through the sample configs to learn things and read the comments.
For some reason I prefer exim's really incredible online docs to this approach- probably just because I can use the index.
Anyways, I'm not a zealot in this case, but I am an exim guy. While people complain that it 'may be' insecure, it doesn't seem to be that insecure to me where I've used it.
--Loki77
I understand Hotmail, I like Hotmail, and Hotmail works.
Escape Pod Films: Sketch Comedy and Web Series