Reporting DKIM Failures with ARF

Posted by J.D. Falk on

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-Canonicalized-Body:
DKIM-Canonicalized-Headers:
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:

  Version: 1
  User-Agent: Fflanda/4.20 (tofu fflanda pot pie)
  Feedback-Type: dkim
  Original-Mail-From: oink@example.net
  Arrival-Date: Fri, 9 Aug 2010 14:25:39 -0500
  Source-IP: 69.192.218.135
  DKIM-Failure: bodyhash
  DKIM-Domain: example.net
  DKIM-Selector: rhallen
  Incidents: 23

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 abuse@returnpath.net.
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:
  • all
  • 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.


Popular this Month

 3 Trends Impacting Email: Persistent Fraud, Part 2

3 Trends Impacting Email: Persistent Fraud, Part 2

In part one of this three-part series, I examined the evolving landscape of...

Read More

 The Top 16 Topics of 2016

The Top 16 Topics of 2016

2017 is finally here! But before we focus on the year ahead, we wanted to...

Read More

 Think Fighting Email Fraud is Someone Else’s Job? Here’s the Real Cost of Doing Nothing.

Think Fighting Email Fraud is Someone Else’s Job? Here’s the Real Cost of Doing Nothing.

Cyberattacks against your brand can be very damaging and costly to both your...

Read More

Author Image

About J.D. Falk

Author Archive

Stay up to date

Enter your name and email address below to subscribe to our mailing list.

Your browser is out of date.
For a better Return Path experience, click a link below to get the latest version.