Early on, in the late 90s, we already realized that eMail is critical to many customers, much more critical than their website. eMail shall be delivered reliably and without noticeable delays, outages are very problematic. At the same time privacy shall be retained and as much Spam as possible rejected, without impact on legit mail. This is, of course, even more true today where eMail became a critical communications channel. We took the challenge early on and kept constantly improving our mail system so that we have a high performance, high availability mail system today to offer.
High Availability Mail Cluster
These days, we operate a big, high availability and very performant mail cluster consisting of a two-digit number of machines. Barely any mail inside our mail cluster is in flight for more than a second. The redundant systems for inbound mail can deliver into the taret mailboxes, there is no master-slave setup where just the master can deliver mail and the slave just temporary stores them if the master is not available – we have multiple masters, so to say.
The interfaces towards our customers – POP3, IMAP and the SMTP-hosts for mails sent by our customers – are on high availability clusters, an outage of a node doesn’t impact the services. For outgoing mail we work with multiple instances, mass mail is automatically routed over separate instances to not hold up regular mail.
To access mail we provide the standard POP3 and IMAP methods as well as a webmail interface so that you can read your email from any device with just a web browser. All protocols can be used with encryption (SSL/TLS), we recommend doing so. Mail accounts, associated mail addresses, auto responders, forwards, user defined mail filters and much more can easily be set up through our control center.
Besides there user visible interfaces all backend systems including storage, directory services and network infrastructure is highly redundant as well.
SPAM
These days, the amount of unsolicted eMail, usually referred to as spam, is so high that a meaningful use of eMail without countermeasures is impractical.
Thus, we are running a very sophisticated spam detection and prevention system. A plethora of techniques is being used, combined, from distributed blacklists to behavioral analysis of the connecting hosts trying to deliver eMail, to distinguish valid mail servers from spambots.
All these measures have one thing in common: we never just drop an eMail (with the exception of the user defined mail filters applied for individual mail boxes only). When our system thinks a particular message is spam, it denies its acceptance, so that the connecting mailserver must inform the sender. We do signal a meaningful error message back for transparency.
This system, constantly fine tuned by our staff, is very effective. Some customers use our mail cluster in front of their own mail systems just for the spam fighting part – while that is most efficient when our system has full control, it is still blocking most spam for them in this kind of setup.
eMail made in…
All our mail systems are physically in Germany and operate under german law.
Encryption
A couple of big mail providers recently announced to introduce encryption. After wading through all the marketing smoke it becomes clear what they actually do: finally enabling SSL/TLS. We’ve done so for 15 years by now, and we’re being honest enough to tell our customers that this isn’t really a solution. An encrypted session between 2 mailservers is only being used when both are SSL/TLS capable and announce the fact, otherwise the mail is transmitted in clear. Mail servers usually don’t verify certificates, which means that there is not authentication at all, the otehr host isn’t necessarily who he pretends to be. Moreover, mail is still stored on the mail servers unencrypted, potentially internaly delivered unencrypted as well. SSL/TLS for mail does not help against government supported spying, nor does it help against hijacked mail servers. Nontheless there is an improvement, just sniffing the mailtraffic is not enough any more. However, there is only one solution for content with high secrecy requirements, end-to-end encryption, without a third party involved – and that includes us.
Extended Authorization
The biggest problem in email is the lack of authorization. Anyone can send mail using any sender address, without the recipient having a safe way to determine whether the sender is who he pretends to be. When the SMTP protocol was developed, everybody on the internet personally knew everyone else on the internet – it was tiny. Its omnipresence today was not remotely on the radar. The giant installed base and the need to be backwards compatible prevented these problems from getting fixed so far, all proposals so far were not workable. But there is one now, called DMARC, which combines and extends the slightly older SPF and DKIM methods and is backed by a large coalition of mail providers, including many of the very big players.
By using this technique you can lower the risk of your sent mail being classified as SPAM at the receiver, as well as making abuse of your domain as sender by third parties considerably harder.
SPF: Sender Policy Framework
SPF has been initially proposed shortly after the millennium, originally called Sender Permitted From. Basically, the list of hosts allowed to send email for a domain is published in DNS. If a mail server receives mail for a domain from a host that is listed as permitted host for it, it can be reasonably sure that the mail is legit. The other way around, however, doesn’t work out at all, SPF is incompatible even with a simple and very common email forwarding setup. That makes SPF completely unusable on its own. It is, however, useful as one input to DMARC, which is the reason why we implement SPF. Due to its design issues we never reject incoming mail based on SPF alone.
DKIM: DomainKeys Identified Mail
DKIM uses a completely different approach. A key pair is generated, the private key is kept on the mail systems handling outgoing mail for the domain in question, and the public key is published in DNS. Outgoing mail gets signed on the mail system, using the private key. The entire mail content and selected parts of the mail header (those relevant to how the mail is displayed to the end user) are covered by this signature, which is added to the mail header. The receiving mail system can now verify this signature using the public key it fetches from DNS. This way it can verify that the mail has not been altered in transit and that the signer had access to the private key – which means he is who he claims it is, or the private key has been compromised, in which case all bets are off since the sending mail host is likely compromised.
DKIM by itself is already a very good fit for many use cases, but still has 2 relevant problems. A mail with a DKIM signature itself tells the receiving system where to fetch the public key from, there doesn’t have to be any relation to the sending address. And some mailing lists modify mail content while redistributing the mail to its subsribers, often adding questionable disclaimers or unsubscribe information.
It is a lot of work and a real challenge to implement DKIM in bigger mail systems, which is why DKIM is currently foremost found at providers specializing in mail services – like us.
DMARC: Domain-based Message Authentication, Reporting and Conformance
DMARC combines SPF and DKIM – according to DMARC, a mail is legit if it passes at least one of SPF and DKIM. DMARC adds a so-called alignment, it will only consider DKIM signatures from the sender’s domain per the from-header (that’s the one displayed by mail clients as sender). SPF is only considered when the so called envelope sender, which is usually not displayed to end users, and the from-header lay within the same domain. With this technique authorization is achieved, if DMARC passes, one can consider the mail authentic.
DMARC-enabled domains publish a policy telling receiving systems how to treat mail that doesn’t pass the DMARC tests. The options are neutral, which tells the receiver to not take any special action, quarantine, which pretty much means that the message is suspect, and reject, which asks the receiver to plain reject these. DMARC-enabled mail systems frequently send each other reports with statistical data (only data already known to both parties plus the results of the SPF, DKIM and DMARC tests) so that one can monitor how effective theses measures are.
All in all, DMARC works wonderfully. Unfortunately there are problems with those mailing lists that modify mail content – the SPF test is almost guaranteed to fail, since the envelope sender is usually the one of the entity running the mailing list, while the from-header carries the original sender’s address, leading to a possible SPF result not being considered due to a lack of alignment. If the mail content has been modified, the DKIM signature won’t match any more either. Mailing lists and especially mailing list software will have to adopt here, this is already going on. While this is a real problem, it is not relevant in many scenarios. Senders who don’t use any mailing lists (which is true for most mail users today) can use a reject policy to make abusing their domain as sender by malicious third parties considerably harder, since the increasing number of DMARC-capable mail systems will plain reject these forged messages. Especially senders with a high forgery potential such as payment providers tend to use a reject policy, so that our mail systems won’t even accept these scam attempts. To get around the mailing list problem our mail systems attempt to detect mails coming via mailing lists and don’t apply reject policies in that case.
DMARC can be enabled and configured using our Control Center. We kept the interfaces as simple as possible, keeping the complexity under the hood. The DMARC-reports we send regarding your domains as well as the ones we receive regarding your domains are being made available to you.
Authentication-Results
Our mail systems record the results of SPF, DKIM, DMARC and select other methods by adding a standards-comformant Authentication-Results header to the message.
