This article is the first in an occasional series on DKIM/ADSP edge cases that may not be generally recognized or understood.

Many people advocate DKIM/ADSP adoption without fully recognizing potential implementation and operational issues. The fact is that the email messaging environment is fraught with opportunities for poor outcomes because of common practices that need to be considered or poorly understood implementations that are not considered. This is especially true at this point with efforts to implement ADSP in conjunction with DKIM. For organizations considering implementing strong authentication assertions such as an ADSP “ALL” or “DISCARDABLE”, one can never be too cautious.

A case in point is the message-id header. One typically expects to find a message-id header in an email message. It is not however a mandatory (MUST) header. RFC822 specifically identifies it as an optional header. RFC2822 and RFC5322 raise the bar further by stating that messages SHOULD have a message-id. A SHOULD however is not a MUST.

In many cases an mail transfer agent (MTA) or relay will add a message-id if one is not already present when the message is received.

So what happens in a case where a homegrown (Perl, Python, etc.) application or commercial application is used to generate email messages but by default it does not generate a message-id? Generally, Some MTA that handles the message adds the missing header. No harm, no foul.

As the email community introduces authentication approaches such as DKIM/ADSP, the risks start to mount. When we look at the standard headers that many DKIM implementations sign in their default mode, we find that message-id is one of those headers. If the signing host/device/application does not check to make sure that a message-id is present prior to signing, the non-present message-id header may still be signed (by inclusion in “h=”). When a helpful MTA subsequently adds the missing message-id header, the signature is broken and subsequent attempts to validate the signature will fail.

It should also be considered that the helpful MTA may be an intermediary which has no direct relationship with either the sender or the receiver.

At least one inbound mail system implementer is currently adding a message-id on arriving email before validating the DKIM signature. Validation fail! It is not clear how many other implementations might behave in a similar manner. The purpose of this article and recommendations is not to describe the issue in terms of right or wrong. It is to document the issue and identify ways that senders, receivers and vendors might mitigate the issue in the context of DKIM/ADSP signing, asserting and validating.

For the sending/signing organization, the following steps can be taken to minimize the risks of this particular case:

1. During initial implementation of an email application, always check to make sure that message-id’s are being created for each message;
2. Implement logic to check for and add missing message-id’s PRIOR TO DKIM SIGNING. In many cases the DKIM signing is performed by a host or device at the border;
3. Check for proper message-id generation any time an email generating application is modified or upgraded.
4. Remember that once a message is handed off, events are beyond the control of the sending organization. Any steps a sender can take to control risks should be considered.

For the receiving/validating organization, always checking/validating what is signed (h=) by the DKIM signature BEFORE making any modifications to the message is one way of reducing the risk of broken signatures and validation failures induced on the receiving side.

For vendors, examining their implementations on both the sending and receiving side and considering mitigating steps in default installations would be a positive step. One approach would be to ensure there is a message-id before including message-id in the “h=” tag regardless of whether this is enabled generally. Another approach might be to give a warning at the time DKIM signing is configured.

This issue came to light as a result of an application that had been in production for years getting broken such that message-id’s were no longer being generated. The DKIM signing process was implemented at the border without any logic to ensure that messages leaving the organization did not have a signed but non-present message-id header.

Some might assert that an organization should never DKIM sign a non-existent message-id header. At this time it is not clear, at least to me, that this is absolutely true. The implications of signing versus not signing under these circumstances certainly merit a healthy discussion before a verdict is reached.

Longer term, it may be that the community should consider modifying the message-id header from a SHOULD to a MUST when a successor to RFC5322 is considered.

I’d like to thank Mark Martinec for helping to bring this issue to light as a consequence of his work on the Spamassassin DKIM plugin support for domain signing practices (ADSP), with overrides.