by J.D. Falk
Director of Product Strategy, Receiver Services
Last week we talked about what’s in ARF, the standard Abuse Reporting Format now published as RFC 5965. Now let’s talk about a proposed extension to ARF, intended for reporting DKIM verification failures.
As we described in an earlier series, DKIM only tells you two things:
1. Does the message have a valid signature? (yes or no)
2. Which identifier signed the message? (the d= domain)
When you get a “no” to question #1, it can be very difficult to figure out why (besides obvious things like “oops, forgot to turn it on.”) There are all sorts of ways that an intermediate system can inadvertently invalidate a signature, all of which involve something that can sometimes be hard to control: changing the message.
These changes can be very subtle: adding or removing whitespace, changing encoding, capitalizing headers or MIME data, and on and on. All things that, for the most part, nobody would notice until adding DKIM, S/MIME, PGP, or other cryptography which attempts to confirm that nothing, however small, has been changed.
Reports vary widely of how often these kinds of changes happen, and in which environments they’re most likely to occur. What makes it all a lot harder is that it’s so hard to know that there even is a problem. That’s where the DKIM reporting extension to ARF comes in.
draft-ietf-marf-dkim-reporting was devised by Murray Kucherawy, who works for Cloudmark. Murray is the primary author of OpenDKIM, the most commonly used DKIM library. He also worked on the Sendmail DKIM library when he was employed there, so he knows his stuff. It’s a safe bet that no one has been involved in more DKIM debuggery than Murray.
His draft creates a new ARF feedback type, simply “dkim”. It also introduces some new metadata fields, containing DKIM-related information:
• DKIM-Failure: is the type of failure, and could include:
• adsp when the signing practices don’t match
• bodyhash when the hash of the body of the message doesn’t match
• granularity when the s= key was not authorized for use
• revoked when the s= key has been revoked
• signature when the signature on the message doesn’t verify against the public key
• DKIM-Identity: the i= value
• DKIM-Selector: the s= value
So, for example, you might see a ARF DKIM report with the following metadata in the message/feedback-report MIME part:
User-Agent: Fflanda/4.20 (tofu fflanda pot pie)
Original-Mail-From: [email protected]
Arrival-Date: Fri, 9 Aug 2010 14:25:39 -0500
In this case, the body hash of the message could not be verified using the selector ‘rhallen’ at the domain ‘example.net’. The source IP, timestamp, and original MAIL FROM can be used to track down the original message in the outbound MTA logs.
The draft also extends the DKIM key and ADSP records published in DNS, by adding:
• r= is the address the domain owner wants reports sent to. It’s just the local part, and is combined with d= from the DKIM signature to form the full address. For example, if a message is signed by returnpath.net and the key record says r=abuse, then the report would be sent to [email protected]
• rf= defines the reporting format, which will pretty much always be ARF.
• ri= is the report interval, or how often the domain owner wants to receive reports of the same failure. It ties closely with the Incidents: field in ARF.
• ro= identifies which types of reports the domain owner wants. Options are:
• s signature or key syntax errors
• v signature verification failures or body hash mismatches
• x expired signatures
• s message is signed, but ADSP result is suspicious
• u message is unsigned, and ADSP result is suspicious
Those records aren’t required, however; I expect that over the next few years, it’ll be more common to see one-on-one reporting relationships set up between a sender (signer) and receiver (verifier), brokered through third parties like Return Path who can offer more advanced reporting tools. Participants can use the same ARF reports (or aggregate forms) without requiring a new DNS record.
At the moment, as the name implies, draft-ietf-marf-dkim-reporting is very much still a draft. The IETF MARF Working Group is discussing and refining it, while a few early implementers have begun testing it amongst ourselves. The group’s stated goal is to complete the draft by March, though I suspect it’ll take longer to establish sufficient interoperability experience.
Return Path makes use of this same data (and more) in our beta Domain Assurance product, working with Yahoo!, Comcast, Cloudmark, Tucows, and others. There’s more information in the announcement here.