Setting up an email stack on a Linux box is a challenge. While it is quite possible to get things running, it requires a tremendous amount of care and overview to harden the system from the security point of view and to maintain it. I spent the last days configuring and re-configuring and re-re-configuring postfix, dovecot, squirrelmail, and the whole MySQL-databases-unix-user-permissions tail. I believe I managed to do this properly (at this point I would like to acknowledge this particularly well-written and complete article). But do I still understand the configuration in half a year? Would I be able to maintain it properly? At the moment, I don’t think so. That’s why I do not like having this mail stack on my Linux box. It frightens me. For very simple cases like mine, there is a more elegant solution: making an external service provider manage the mail sent to the custom domain.

The MX record

Someone sends an email to hans@example.com and e.g. Microsoft retrieves it? How would that work? The key mechanism is mediated through the DNS MX record of your domain: when the sending mail transfer agent tries to send a mail to e.g. hans@example.com, it queries the MX record for example.com, yielding a list of host names. These hosts are assumed to be (and should be) ready to retrieve mails via SMTP. Hence, mail retrieval and management can be outsourced to any service provider by making the MX record for the custom domain point to mail servers of the corresponding service provider (for this purpose, Google e.g. lists its mail servers here).

Google, Microsoft or Zoho?

If Google should manage the mail for the custom domain, this would go through Google Apps, either for business or for education. In the meanwhile, Google Apps for Business costs money, so this is not an option if you want to manage your mail for free. Lifehacker suggests that now Microsoft with its Outlook service is a good option. Via http://domains.live.com you can register and validate your custom domain. After that, you can add up to 500 user accounts. Microsoft, however, does not provide IMAP access for the corresponding mail accounts. This is a killer argument (for me, at least), so I was looking into other solutions. The Lifehacker article mentioned above also recommends Zoho, so I tried the free version, supporting — among others — 5 GB storage for your mails and IMAP.

Zoho it is

After validating my domain with Zoho and adding the MX records for mx.zohomail.com and mx2.zohomail.com (the effect of which you can btw verify via services such as mxtoolbox), I created a new user/mail account. IMAP is not activated by default, but can easily be switched on through the user interface (although this really could be clearer). Right after that, I added the corresponding account to Thunderbird, using

• imap.zoho.com:993 with TLS and
• smtp.zoho.com:465 with TLS.

It works out of the box and, assuming that Zoho has set up their mail infrastructure properly, is more secure, reliable, and maintainable than trying to set up things by oneself.

Update: TLS between MTAs

According to checktls.com, Zoho’s MTA does not support TLS, i.e. incoming mails sent from other MTAs to the SMTP server at mx.zohomail.com are, in principle, readable (and editable) by any device on the route between both MTAs. Microsoft’s hotmail also does not support it. Googlemail, however, does.

What is TLS between two MTAs good for? Encrypted transport between two MTAs itself does not have any implication on the privacy, integrity, and authenticity of a mail. The connections between the sender/recipient and their SMTP/(IMAP/POP) server might or might not be secured. The mail might pass more than two MTAs. Let us assume that the SMTP connection of the sender, the POP/IMAP connection of the recipient and all connections between the MTAs involved are secured via TLS. This reduces the instances that might read the mail or tamper with the mail to the MTAs involved. It reduces risk. In my opinion, this is desirable and that is why I would like to see Microsoft and Zoho support TLS on their side.

In brutal security terms, however, “reduced risk” does not exist. Binary thinking is required. Either the entire transmission process guarantees integrity/authenticity/privacy or it does not. And this does not depend on the connection between to MTAs. That is — presumably — why Zoho and Microsoft decided to save computing resources and not implement TLS. End-to-end mail integrity and authenticity can only be guaranteed via adding a signature to the mail with e.g. PGP. Privacy can only be achieved via end-to-end encryption.