Slashdot Mirror


The Exim SMTP Mail Server

ollyg writes "Exim is a mail transfer agent that can be run as an alternative to Sendmail on most Unix and Unix-like systems. At my organization we use it to relay around half a million messages per day, although it's suitable for many other types of installation including those with local delivery, and far larger (or smaller) ISPs." Ollyg reviews here the official guide to Exim's current release, which weighs in at a hefty 621 pages. The Exim SMTP Mail Server: Official Guide for Release 4 author Philip Hazel pages 621 publisher UIT Cambridge rating Recommended reviewer Oliver Gorwits ISBN 0954452909 summary A thorough guide to the configuration and deployment of Exim v4.x

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.

4 of 233 comments (clear)

  1. Why would I want to use exim? by Captain+Tenille · · Score: 0, Flamebait
    I understand sendmail, I like sendmail, and sendmail works. Forgive me if I don't feel the need to use some random unproven MTA.

    It annoyed me to no end yesterday when I was installing Debian on my Ultra 1 and it went and installed exim for no apparent reason. As soon as I get around to it, I intend to remove exim and get sendmail on there. I want a functional mailer.

    --

    ------------
    /* You are not expected to understand
  2. Re:Exim's design is bad for security by Fefe · · Score: 0, Flamebait

    ROTFL, sendmail has an excellent security model in 8.12? Yeah, you can see that clearly when you read things like the last remote root exploit in sendmail 8.12.7, or are you now going to argue that 8.12 really starts with 8.12.8?

    And what "advanced queueing features" are you talking about here? If you mean milter, that is a kludge akin to fastcgi, and it typically involves linking untrustworthy sendmail code to your filter application. I don't know about you, but for me that is not an option. Never has been, never will be.

    And qmail looking outdated, that claim is so ridiculous, it does not even warrant an argument. Sorry, dude, but my little brother is a better troll than you are. Muhaha, you are even cheap enough to post as AC instead of using a throwaway account...

  3. Re:Exim's design is bad for security by Fefe · · Score: 0, Flamebait

    It's easiest to use a virtual domain with a two-line shell script glue, but you can also just use spamassassin as default delivery method and let the users override it in their .qmail files.

    Who says Dan isn't planning any more releases? And who cares if you can patch your own release? Why would you care if you can distribute a patched release when you can distribute an unpatched pristine version and a patch (which, incidentally, is what all the Linux distributions do anyway)?

    Also, qmail is the only MTA I know that can virus check email without bogging down the system with temp files. The reason is qmail's advanced queue layout (which Wietse in his inexperience and incompetence preferred to bash for personal reasons and now Postfix needs temp files for virus scanners and whatnot, doubling real life disk I/O in comparison to qmail. Good job, Wietse).

    The downside of qmail is that you need to spend time understanding it. The upside is that you can thorougly understand it in a week or so, while you can barely skim through all the cruft in the Exim manual in that time.

  4. Re:Exim's design is bad for security by Fefe · · Score: 0, Flamebait
    Seems someone doesn't know the difference between a "security model" and a buffer overrun...


    Yeah, a security model is what you implement to make sure buffer overruns don't matter. In qmail, for example, the security model has the smtp daemon run with just enough permissions to write incoming mails in the incoming queue.

    you may wish to read about queue groups and multiple queues


    You really believe this marketing crap, do you? Wohoo, "queue groups", I bet it's almost as great and innovative a feature as thread pools.

    using LDAP already puts the administrator in the awkward position of requiring unsupported 3rd-party patches


    Actually, no. Not at all. I implemented a qmail with all-virtual LDAP users and did not have to touch the qmail source code once. I did not even have to replace or overwrite any binaries.

    qmail is modular enough that you can specify other delivery and the password authentication modules, in my case LDAP speaking onces. That's it. Partial sources are here.

    Get your facts straight next time, FUDster.