Mail Routing 3: Doing DKIM Perfectly

DKIM is the technology that signs a message and some of its headers at a mail server en route; mostly this is done by the originator of the email. One problem remains that slows down its introduction as a hard filter, and that is email handling that edits the message and then forwards it, as is common for email lists. This article nails the integration of DKIM with forwarding.

In the setup of identities for ARPA2, we intend to given group members a local name consisting of the group name, a plus symbol and a nick that the member has picked to unique identify themselves in the group. This group+nick notation is not just helpful for their privacy, but it also helps to select an outgoing name that is local — even when the group member has an email address that is external to the group's domain.

The Last Nail in the Coffin

This may seem perfect, because we are now in a position to supply our own DKIM signature, but there remains one concern, and that is for publicly accessible groups. Sending to those would be permitted to non-members, and we need to find a DKIM-compliant way to address those senders as well.

As it turns out, this can easily be remedied. Yes, we could create a temporary name under the domain, but no we don't have to. We will simply keep the sender's address unprotected in the From: header instead of linking it to the group's domain. And even though we would evaluate the targeted group address for some special syntax forms, we would not alter the To: and Cc: in transit, nor the Reply-To: address, if any. This differs from the treatment of a remote user who is registered as a group member, because in that case we can pull the sender address into our own domain to the known identity for it. In both of these cases, the DKIM signature is valid; we just pass it along for unregistered senders while we modify it into a local alias for known group members or role occupants. A backlog of registrations and unregistrations by remote users to a group or role is kept, in support of abuse handling as well as living up to legal obligations to prove group subscription by externals.

This clearly demonstrates what DKIM is all about; it is about checking any verifiable headers. The link to the From: header is particularly strong, which is why it is important to "style" this header for good reception.

Benefits from Authentication Results

Upon entry, a modern MTA assesses the incoming email for authentication mechanisms:

• Does it pass SPF, meaning did the email arrive from an MTA for the claimed sender domain?

• Does it pass DKIM, meaning did a signature validate the message and its most important headers?

• Does it pass DMARC, meaning that either SPF or DKIM passes and did the validated sender domain match the email's From: header?

• Did the user login SASL under a TLS cloak, as is common when they are local users addressing the Mail Submission interface on port 587?

• Did the sender sign the email with X.509 or OpenPGP, with an address that we could validate in their Global Directory?

Each of these helps to trust the sender's identity. And this can be really helpful.

Imagine signing up to an email list without the common pattern of a reply mail with a link to click. Given that your email address is validated upon entry, this would no longer be required (not all methods are equally suitable though; SPF is meaningless can arrive from a shared host, while DKIM normally uses domain-specific keys and is therefore quite reliable).

This pattern is just the beginning. How about submitting articles to your cooking blog by mailing your newly discovered recipe to the blog's service address +blog+TheExplodingStove@example.com and have the mail system sort out the insertion into the larger structure?

DKIM-Signature: XXXX
Subject: Broccoli on a Bed of Tomatoes

Trim broccoli and steam for 10 minutes.  Slice meaty tomatoes and bake
in butter for 5 minutes.  On each dish, layer tomatoes with hot steaming
broccoli, cover with Camembert slices and keep under a lid for 5-10 min,
or until the Camebert is molten.

And more techno-savvy, how would you like to edit your data in LDAP? You could ask the +ldap@example.com service for your objects, edit them and send a reply. Or you could just submit an LDIF if that's your style. This is an incredibly easy interface to an otherwise difficult-to-use service.

objectClass: inetOrgPerson
uid: rick
cn: Rick van Rein
mail: rick@example.org
description: A bit chatty, but not a complete idiot

Passing on the Pleasures of Authentication

Time to return to Earth.

We indicated that we want most of the outgoing traffic to point back to the domain managed under the IdentityHub that we are designing here, with the InternetWide Architecture. Being crypto-savveys, we love nothing more than to apply DKIM and SPF and all the other pleasures of life on all our external conduct.

But wait. What if we are passing on traffic that was not so well-protected? Then we might land with an external statement that is stronger than the incoming statement. This is certainly not a good idea.

So, when we pass traffic through our domains, we will take a look at the quality of the incoming data, and supply the output with similar quality.

• Local users who authenticated with SASL over TLS are pretty reliable. There is no problem to mount a cryptographic firewall on their behalf, so we will happily apply SPF and DKIM for those users.

• Users from anywhere, who present OpenPGP-signed content can also be trusted with that content. Their origin is a different matter, as that is not usually included in the signatures. Looking them up in the LDAP Global Directory, validating their user name and assuring that the LDAP service is protected with TLS, DANE and DNSSEC further pins down the security. Similarly for X.509 certificate holders.

• Remote users who validate under DKIM, and who have included a decent supply of headers in the signature-protected scope, are can also be trusted to have come from the claimed original domain, and can be accepted when this matches their sender address.

• DMARC wants to pin down the address in the From: header to one that resides under a domain that was validated under DKIM or SPF. It is good to reproduce the same status on output as we found on input, and that should be easy to do.

• Remote users who validate under SPF, are not nearly making as strong a claim. SPF is mostly about exclusion of other senders and is not as strong in pinpointing that nobody has been tampering with the sender's identity. Meaning, based on SPF alone we shall not sign with DKIM when passing on the email, but we will once again arrange SPF. If SPF is not valid on input, we can usually generate a sender address that fails SPF testing, though that would at best qualify to suppress the relaying of spam.

In these days in which email authentication is coming up, we may easily make the mistake of relaying messages while stepping up their observed authenticity. That might lead to situations that would grant rights such as the ones from the previous section without actually being allowed to have those rights.

For SPF, a step-up in perceived quality is not a big concern, but doing DKIM perfectly may involve holding back on it... in der Beschränking zeigt sich der Meister!

Update 2017-08-30: Reply-To munging

We have considered to place remote and unregistered sender addresses into a Reply-To: field but, with a gut feeling that this had been a topic to people in the past, we asked around, only to be pointed to convincing arguments about the right approach to do this.

Changes to email bodies are not the post man's prerogative, and the headers should be kept as pristine as possible, too. The privacy concerns for group members are an overruling concern to us, so we shall munge those headers, but for unknown external senders we shall not modify the headers in any way; externals are supposed to know only the group address anyway. We may opt for rejecting group-addressed emails that reveal more than just the sender's address, but that is still an open issue.

As for modifying email with legal banners and [indicators] in the Subject:, this practice seems to cause more pain through breaking DKIM than relief through the ability to sort and mark emails. Much better facilities exist, which even provide better semantics than just placing texts in places that welcome arbitrary text but fail to convey any meaning for it:

• The List-ID: header is deliberately designed to convey a unique identity for a list (or role, or group).
• The Keywords header is designed to hold a comma-separated list of words or phrases describing the text.
• The Comments header is designed to hold any additional comments on the text of the body of the message and this is much more telling than plunging legal text in a footer (after having read the body) or before it (which everybody understands to discourage reading the body at all). If anywhere, the Comments section is the place for legal disclaimers. It cannot be used to force legal conduct on a recipient, which is also the limitation ofttext in the footer, unless a prior contract between the sender and recipient forced the latter to comply. When you set these, you should consider including it in the DKIM-Signature: signed-header list.
• Disclaimers stating that only the intended recipient may read an email are seriously misguided. Whenever this is a concern, use OpenPGP or X.509 encryption. Where this is a company-wide policy, stop sending disclaimers and apply encryption. And yes, we aim to make this easily doable with our IdentityHub design, through the use of a Global Directory. This enables recipipents to publish key material for encryption, and recipipents to automatically make use of it.