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