Solving our authenticated SMTP problem by rethinking it

March 16, 2015

Part of our mail system is a mail submission machine. Perhaps unlike many places, this machine has never done authenticated SMTP and as a result has never accepted connections from the outside world; to use it, you have to be 'inside' our network, either directly or by using our VPN (and at that point it just accepts your email). Recently this has been more and more a pain point for our users as it becomes more and more common for devices to move between inside and outside (for example, smartphones).

Unfortunately, one reason we haven't supported authenticated SMTP before now is that it's non-trivial to add to our mail submission machine. There are two tricky aspects. The first is that as far we can see, any easy method to add authentication support to our Exim configuration requires that our mail submission machine be rebuilt to carry our full /etc/passwd (and /etc/shadow). The second is that the mail submission machine still has to support unauthenticated SMTP from internal machines; among other things, all of our servers use it as their smarthost. This requires a somewhat messy and complex Exim configuration, and being absolutely sure that we're reliably telling apart internal machines from external machines and not accidentally allowing external machines to use us without SMTP authentication (because that would make one of our most crucial mail machines into an open relay and get it blacklisted).

(Right now the mail submission machine has a strong defense in that our external firewall simply doesn't allow outside people to connect to it. It has its own access guard just in case, but its accuracy is less important. In the new world we'd have to open up access on the firewall and then count on its Exim configuration to do all the work.)

Exim can use a local Dovecot instance for authentication, but that doesn't help the mail submission machine directly; to run a local Dovecot that did useful authentication, we'd still need a full local /etc/passwd et al. But then we had a brainwave: we already have a Dovecot-based IMAP server.

Rather than try to modify the mail submission machine's Exim configuration to add authenticated SMTP for some connections, we can turn the problem around and do it on the IMAP server instead. The IMAP server already has Dovecot and our full /etc/passwd; all it needs is to have Exim added with a configuration that only does authenticated SMTP. Sure, we wind up with two mail submission machines, but this way we don't have to mix the two somewhat different mail submission roles and we get a much simpler change to our existing machines. People also get a somewhat simpler IMAP client configuration (and one that's probably more normal), since now their (outgoing) mail server will be the same as their IMAP server.

(The actual Exim configuration on our IMAP server can be just a slight variation on the existing mail submission Exim configuration. Insisting on SMTP authentication all the time is an easy change.)

As a side benefit, testing and migration is going to be pretty easy. Nothing is trying to talk SMTP to the IMAP server today, so we can transparently add Exim there then have people try out using it as their (outgoing) mail server. If something goes wrong, the regular mail submission machine is completely unaltered and people can just switch back.

Comments on this page:

By dozzie at 2015-03-17 05:49:47:

Note that there are ways of authenticating against (effectively) IMAP server in SMTP session. You may want to look at howto for Postfix (, especially the section about saslauthd. Exim can authenticate against saslauthd as well, of course.

Using IMAP authentication would make your IMAP and SMTP servers not tied to one another that tightly, which is rather good.

Personally I would migrate accounts to LDAP long ago, but as I remember, you don't like having additional service for this and rather stick to /etc/passwd accounts.

By john at 2015-03-18 20:58:49:

You really over-thought this. Don't you realize this is how most people have things set up? The outgoing mail server we use for our various linux boxes and copiers and other appliances is just not the same one that is used by clients for email.

I really enjoy your blog, but you often take problems others have solved with very little effort and make them very complicated.

The trend at the moment is for university schools and colleges and other similar academic units to not run services central IT can run. This is why you probably don't need to be in the email business at all. You should focus on providing unique services to researchers and not expend so much effort on providing commodity services like email which can be done faster/better/cheaper at greater scale.

Our central IT runs Exchange, and while the Microsoft-ness bothered me for a while, I can run IMAP against it, and just not think about email anymore.

By cks at 2015-03-18 22:05:54:

You're right, and that's a main point of my entry: this is an obvious solution to the overall problem but in order to see that we had to spin the problem around to see things from another angle. We started thinking that the problem was 'how do we add authenticated SMTP to our existing mail submission gateway' and that made everything complicated. We only had the problem become simple when we rethought it and saw that we could have two mail submission gateways, because the real problem and goal was simply to have an authenticated SMTP service.

(This is a general pattern in system administration because you are often mutating existing setups rather than designing entirely new setups from complete scratch in a historical void.)

There are a whole host of reasons for why we continue to run our own mail service. For the most part these boil down to 'we provide features that the central service does not and that (some) users are (very) attached to'. One example is simply large mail storage; our limits are many times larger than the central service (and are trivially expandable by professors if they want to, since everything except their inbox lives in their home directory and they can buy more space for that if they ever run out).

Written on 16 March 2015.
« Our difficulties with OmniOS upgrades
The real speed advantage static rendering has over dynamic rendering »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Mar 16 23:41:40 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.