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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2012 16:35:37 -0800

I'm going back through this thread to try once more to get WG momentum on doing this work.  If it fails, I'll look into taking it back to an individual submission and/or lowering it to "Experimental" status.  Accordingly, I'm brewing up a new version now.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John R Levine
> Sent: Sunday, October 02, 2011 8:59 AM
> To: ARF mailing list
> Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback
> 
> I presume the motivation for this is that you have a few people who
> want to use it to debug DKIM failures.  That's perfectly reasonable,
> but if people already know each other, they can use private agreements
> with no need to standardize anything.

Actually, I think even private agreements to do this sort of work can benefit from a standardized approach, because then software can be shipped with the support in there, activated by the flip of a switch.  In light of this...

> This strikes me as a poor thing to standardize for a variety of
> reasons. One is that the number of people debugging a protocol is less
> by many orders of magnitude than the number who are just using it, and
> to the users, debugging features are just cruft.  Also, to some extent
> this is an invitation to mailbomb anyone who uses it, and as Steve
> noted, the people who you'd most want to implement this, the ones who
> are smashing signatures on the way in, are the least likely to do so.

...I've added some text to Security Considerations that says if you want to do this, you shouldn't do it automatically; rather, only actually pay attention to "r=" if "d=" matches a domain for which you've agreed to do reporting.  That should solve the mailbomb problem except for domains that want that kind of forensic information anyway.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2012 16:45:30 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Friday, September 30, 2011 12:20 PM
> To: Message Abuse Report Format working group
> Subject: [marf] draft-ietf-marf-dkim-reporting feedback
> 
> 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.

My motivation is actually not bulk senders in particular.  It's implementers that are trying to get their implementations to interoperate, and trying to figure out why they don't.  To be specific, this sort of thing was particularly valuable when DKIM was young and one operator had installed some software but couldn't figure out why signatures were failing.  Where the verifier doesn't have the knowledge or tools to track down the problem, the signer has a way to request the forensic information needed via this mechanism.

> 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?

It's agnostic to the path.  What it's able to give is "This message was changed since delivery.  Here's what we saw on receipt."  And where a DKIM "z=" tag is used, it's possible to show what part of the header changed without having to keep all sent headers around for a while.

> 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.

What's the specific objection to such overloading?

> 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.

Fixed.

> 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.

I've changed it to that syntax.  (You and John concur on this point.)

> 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).

I've changed it to be a tag in the signature, rather than registering a whole new header field.

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

Extra DNS traffic is exactly what I'm trying to avoid here.  John suggested putting it in the signature, which is even better; the previous design always went to the DNS even for messages that don't need it (because signature didn't match the hash), but now the rules for going to DNS are tighter.

> 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?).

The work has been extended to support SPF through the spf-reporting draft and corresponding changes to the authfailure-report draft.

-MSK