Fighting SPAM: Using DKIM and DMARC for DroidWiki
DroidWiki.org operates their own E-Mail-Server in order to independantly send project related e-mails and provide E-Mail functionality to their users, e.g. when a new user registers an account to verify their e-mail address or to reset their passwords. A time ago I already setup SPF (Sender Policy Framework) in order to propagate to the outside world which IP addresses are allowed to send e-mails from the droidwiki.org domain. I did that as it was pretty easy to implement and e-mails, sent by DroidWiki, will most likely get a better rating from the big E-Mail providers (GMail, Yahoo, …) if they pass the SPF check.
DMARC and DKIM
Another way of preventing your own domain being used by spammers, who can also fake your domain in plain e-mails, is by using more complex (not sure if “complex” is the right word here, however, you need to setup a bit more in order to use both of them) tools. Two of them are called DMARC (Domain-based Message Authentication, Reporting and Conformance) and DKIM (DomainKeys Identified Mail). Let’s take a short look on both of them.
DMARC is not really a way of authenticating e-mails, it is more or less used to audit what happens with your domain from the point of view of other mail servers. It consists, easily spoken, out of two components: If setup, other e-mail providers will sent you a report of e-mails they received from your domain (which does not mean they need to be sent from one of your mail-servers, e.g. spam) and if they passed either the SPF or DKIM check or both. You can then see which e-mails were sent to this provider without your permission and from who. The second part is a way for you to suggest what an e-mail provider should do if a received e-mail does not pass either SPF or DKIM. You can specify if the e-mail should be passed along (policy none), put into quarantaine (policy quarantine) or if the e-mail should be discarded (policy reject). The whole DMARC configuration is done by a TXT entry in the DNS of the e-mail domain, from which the mail was sent.
DKIM on the other hand, is a way for an e-mail sender to authenticate the mail. This is done by first generating a private/public key pair. The private key is kept private on the server and will be used to sign e-mails that are sent to other e-mail servers. The public key is published as a TXT entry in the DNS of the e-mail domain. Any receiving e-mail server, which supports DKIM, will then lookup the public key of the e-mail domain from the DNS and verify the signature of an incoming e-mail. DKIM itself will just tell you, if an e-mail was authenticated based on the provided public key, or not. What happens based on the result is up to the mail server, which can, e.g., use the suggestion of the published DMARC configuration.
The DroidWiki part
SPF was already used for the DroidWiki mail server for a long time. Recently, a set of commits to the server configuration setup DKIM as well as DMARC. DKIM will, starting from now, sign all outgoing e-mails from the DroidWiki e-mail server (which includes, as of now, the droidwiki.org as well as the go2tech.de e-mail domain). DMARC was setup to audit e-mails sent to other e-mail providers, so I can see what e-mails are sent under both of the e-mail domains. The policy, for now, is none, so that DKIM or SPF do not need to be passed, however, the plan is to go over to the quarantaine policy shortly and also to the reject policy in the near future as well. This should make the e-mails, sent from DroidWiki, even more trusted by other e-mail providers and makes it harder for spammers to use one of the domains to sent spam to innocent people.
Links
The post is written on code and configuration based on the following commit and it’s parents:
https://github.com/droidwiki/operations-puppet/commit/18d0777fbc429f1f9690c048edabfdf5b2e93b4a
The whole configuration of the DroidWiki servers is publicly available on GitHub: