Can I in the strongest possible terms recommend that you not run Exim, and instead migrate posthaste to Postfix or qmail?
Exim is lumped in with Postfix and qmail as one of the "next-gen" MTAs written in response to the 1990s Sendmail security debacle. But it's really not; Exim is a last-gen design very closely reminiscent of SMail, which is basically Sendmail but with far less security attention.
It has been a constant annoyance going on 15 years for me now to see people recommending Exim as a secure alternative to Sendmail. It may be many good things, but high-assurance software is not one of them. In 2010, who has time to worry about whether their mail server is handing their internal network over to attackers?
Not for nothing, but, a silent patch to a remote code execution flaw (from 2008!) is a major breach. You want an example of the kinds of things that turn vulnerability researchers into raving assholes: there's a good one right there.
I'm curious why you would recommend qmail these days. The last official version was released in 1998, and it seemed like it was stuck in some weird licence limbo until 2007, making forks unable to be distributed with linux distributions.
I trust qmail more than I trust Postfix. I may be biased; I found a vulnerability in Postfix early on. qmail has one of the best security track records of any piece of Internet software ever written; so far as I know, the only bona fide major vulnerability ever found in qmail required a nonstandard 64 bit deployment, and an attacker writing gigabytes of data to the server.
I think you kind of have to admire a piece of software that is still useful without changes more than a decade after it was released. You're entitled to think differently.
The license stuff is totally irrelevant to me. Bernstein didn't want his code forked ("incompatibility is a bug"). Hordes of Linux people, most of whom had never published a line of C in their lives, swarmed him and the Internet with complaints about how qmail wasn't open source or (worse, and more misleadingly) was "proprietary".
It's public domain now.
Postfix is a perfectly acceptable alternative to qmail.
Didn't qmail's license require you to install it in /service/qmail or something similarly nonstandard? I admit that it might be better if things did work that way, but they don't and having one program work differently is just annoying.
Of course, this is not a problem now that it's unambiguously public domain.
qmail may have had weird license quirks and may not be as featureful as modern MTAs, but the code is very nicely designed. qmail did not achieve "commerical success", but that was due to the learning curve rather than its approach to not having remote root holes.
I used it for many years until I got lazy and switched to exim and then postfix. I guess I am glad that I switched to postfix, but not so glad that I switched away from qmail.
(Ironically, I still use sendmail on my OpenBSD boxes. It sure seems funny to be relieved that I'm running sendmail today!)
qmail may be old, but the author (DJB) wrote some _solid_ code. I believe there hasn't been a vulnerability in qmail in the last 10 years (someone can correct me if I'm wrong).
qmail itself is secure, but qmail without 3rd party patches is pretty much useless. This starts with qmail's delayed bounce behavior and continues with fact that patches are required for the integration of DNS-based blacklists or spam filters.
Once you start to integrate all the patches required to make qmail usable the security track record looks somewhat worse than the one bug found in qmail so far.
One, I use DJB's qmail distro and it works fine for me. Yeah, I need a patch to get STARTTLS or (god help me) a DNS RBL. But it's not "pretty much useless" by itself; that's hyperbole.
Second, the semi-official collection of patches you're referring to is called "netqmail". What are the netqmail vulnerabilities to which you refer when you say "the security track record looks..."?
In December, 2008, the Exim team accepted a bug fix for "memory corruption in string_format code", noting "string_format() will happily overwrite beyond allocated memory"; the CVS commit message was "Buffer overrun fix. fixes: bug #787".
Apparently, nobody thought this was worth alarming end-users over.
Exim is lumped in with Postfix and qmail as one of the "next-gen" MTAs written in response to the 1990s Sendmail security debacle. But it's really not; Exim is a last-gen design very closely reminiscent of SMail, which is basically Sendmail but with far less security attention.
It has been a constant annoyance going on 15 years for me now to see people recommending Exim as a secure alternative to Sendmail. It may be many good things, but high-assurance software is not one of them. In 2010, who has time to worry about whether their mail server is handing their internal network over to attackers?
Not for nothing, but, a silent patch to a remote code execution flaw (from 2008!) is a major breach. You want an example of the kinds of things that turn vulnerability researchers into raving assholes: there's a good one right there.