> -----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.
The main motivation (for me, at least) is implementers that need to debug
unexplained failures. Setting up a test address at a problem site can help,
but doesn't always as doing so presumes what happens between (for example) DKIM
validation and mailbox retrieval makes no changes to the message, and that's
not always the case.
> 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",
I would say "at or before the receiver" is more precise.
> 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?
MUAs could also do it, to be sure. I'm not sure I understand the rest of what
you're saying here; why would a receiver with a "dirty" delivery path not want
to identify the problem? Surely they'd start to get pressure from signers that
want to get valid signatures through delivery.
> 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.
That'd be OK with me. For backward compatibility, I'd probably leave "r=" as a
reporting address and add some other key tag for declaring that reporting is
requested.
> 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.
Fair enough.
> 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.
That change would be fine as well. Interesting point about per-receiver rates
though; hadn't thought of that.
> 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).
Interesting idea as well. What do others think?
> It could also be handled via a separate DNS lookup, rather than
> overloading the existing DKIM key record.
I'm trying to piggyback on retrieving the key record. At the time this was
designed, most of the squawking about DKIM's load (especially with ADSP right
behind it) had to do with the DNS load it would create.
> 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)?
That was actually a secondary motivation for constraining "r=" to be a
local-part only. In my own observations, there are keys that pass the TCP
limit and those that don't, but very few are close, which means "r=" wouldn't
usually be the thing that pushes a record over the limit.
> 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?).
Yep, and that's why there's also an "spf-reporting" draft. The issue, though,
is that for a failure of DKIM, a different set of data is useful for debugging
versus an SPF failure. That seems to suggest different extension documents is
an appropriate path.
> 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.
In the larger picture I'd say that's probably the most visible part of this
work, but I don't think it's the most valuable for debugging failures. The
canonicalized forms of the header/body at the receiver is what's most important
in that case.
> 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?
It's not everything I'm after, at least. Perhaps there should be two reporting
modes, one that only involves the "rs=" and one that involves returning the
data needed for debugging?
> (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.)
It's a discussion worth having. Other than wanting to shorten
"_authenticationfailure", I'd like to explore it a little. I'm worried about
backward compatibility with the work as-is though, where "r=" is a DKIM key
record tag. This would require replacing all of that code.
-MSK
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
