> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 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 protected]" 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
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
