Subject: [marf] draft-ietf-marf-dkim-reporting feedback

From: Steve Atkins <[email-masked]>
Date: Fri, 30 Sep 2011 12:19:33 -0700

I have a few comments - I've already chatted with Murray directly about some of these, and he encouraged me to share them on-list.

1. Who would want it and their existing alternatives.

This seems to be a feature that will primarily be of interest to bulk emailers. Those senders are interested in many facets of email delivery, and have existing networks of probe addresses at many ISPs which they use to monitor email delivery. Those probe networks can already give them most of the same information that this would provide, without any requirement for support by the receiving ISP.

2. Where in the delivery path does it detect errors, and whether organizations causing errors are likely to deploy this sort of code

It seems to be intended to detect DKIM-invalidating modifications "at the receiver", as it's fairly easy for a sender to identify problems that are near to them. Receivers who have a "non-DKIM-clean" delivery path seem like the least likely receivers to add additional DKIM/ADSP-specific baggage to their delivery path - so I'm not sure that something like this would be likely to be deployed at the receiving ISPs where the feedback would likely need to be generated. Unless it's intended for MUA deployment, maybe?

3. Implementation nits

3a. Inconsistent flags for in-band reporting

There are some nits too. You can ask for a magic cookie in the rejection string using rs= - which is good, as that can be handled well by existing delivery log monitoring tracking. But rs= is not valid unless there's an r= field that's asking for reports to be sent to a specific address. r= is being overloaded as both a boolean ("do some sort of reporting") and as a parameter to one particular sort of reporting (via sending an email). Unless that's there for backwards compatibility I'd be tempted to split the two.

3b. Does this define an email address for reports, or just a local part?

r= "MUST be a dkim-quoted-printable string containing an e-mail address", yet it "MUST be interpreted as a local part only". The examples tell me that it's just a local part, and doesn't have an "@" sign in it, but the spec should probably be clarified.

4. Sampling may be useful, but probably not if it can only be applied identically to all receivers

I don't see ri= as being particularly useful given the way I expect this would be used, as that value is shared across all receivers. I'm either going to want a report about every failure, or I'm going to want summary reports. If Gmail are having very rare DKIM failures on my mail - one in a million, say - I'm going to want to see every one. If Earthlink are breaking everything I send, I'm going to want summary reports. I can't get both, so I'm going to end up leaving it set to "0" and summarizing at my end. If it were in the format of "no more than X reports every Y seconds" it might make more immediate sense than simply reporting every n-th message, maybe. That would also avoid the problems in 8.3 and would allow the sender more control over the issues in 8.5.

5. In-band advertising vs out-of-band vs overloading DKIM

For many use cases this functionality could be handled by in-band advertising (e.g. a "DKIM-Errors-To: [email-masked]" header). 

It could also be handled via a separate DNS lookup, rather than overloading the existing DKIM key record.

Does the increase in size of the DKIM key record cause significant cost (especially in the case where it causes the already large key record to expand so that it's over the size that can be efficiently / reliably handled over UDP)?

6. Would something broader be more useful?

This is very specific to DKIM or ADSP failures. If it is useful for the sender to be notified of one sort of authentication failure, they'll probably be interested in notification of other failures (SPF?).

7. Would something narrower be as useful?

The rs= magic cookie in the rejection string seems like the most useful part of this. At large ISPs almost all rejections are handled during the SMTP session, and DKIM checking is happening at the external MX, not at an internal handoff.

Rather than specifying an out-of-band asynchronous notification via email at all, would this concept be just as useful if it only included the magic cookie in the rejection string?

If so, then rather than adding flags to the DKIM record, could we just ask receivers to put a magic cookie in their rejection string anyway ("[AUTHFAIL=DKIM-bodyhash]").

If the answer to that involves ADSP, can we split this out to have DKIM and ADSP handles separately?

(If I were starting from scratch rather than doing something specific for DKIM, I probably wouldn't add all this to the DKIM key record or the ADSP record at all - I'd use a separate name space to stash the data in, so that if you were to see a DKIM auth failure from me, you'd do a query for "mta3.cloudmark.com.dkim._authenticationfailure.wordtothewise.com" and do what that TXT record asked. Creative use of wildcarding would let me set a general "I'd like to know about it" policy, while setting much more verbose reporting while I was diagnosing delivery to a particular recipient ISP. And I'd also be able to have "*.spf._authenticationfailure.wordtothewise.com", "*.adsp._authenticationfailure.wordtothewise.com" and so on. But that's a whole other discussion.)

Cheers,
  Steve