[ietf-dkim] Issue 1579: ADSP result set, New issue: ADSP status codes
nobody at xyzzy.claranet.de
Sun Jul 6 11:22:00 PDT 2008
John Levine wrote:
> I agree that in retrospect, DKIM should have used WSP
> rather than FWS in the DNS records. But it says FWS,
> existing code really does FWS, and it makes sense to
> me for ADSP to be consistent.
Yes, that was what I meant when I wrote:
| apparently folks want FWS in DNS because DKIM also has
| it, and while it makes no sense it could be worse to
| get a different story in ADSP.
| But *FWS is flat out wrong (reported as DKIM erratum).
[reject vs. discard]
> Mission creep.
Well, I'd know how to kill the draft post-approval with
what you consider as "mission creep". Resent-* is going
to stay, and ADSP "discardable" is a frontal assault on
Resent-* cases managing to spoil the From-signature(s).
At the very minimum you need to have the reason why any
Resent-* scenario destroying signatures is "broken by
design" on public record. Maybe put it in the security
considerations. I won't let 2822upd say A and ADSP say
not A. See RFC 5016 chapter 4.3, we saw this coming...
> DKIM and ADSP don't say anything about SMTP sessions.
Similarly SPF does not tell receivers that they should
reject FAIL, it only tells them to check SPF at a place
where that is the only plausible decision, and how to
do it if they decide to reject FAIL.
The complete concept of "discard" is utter dubious for a
non-zero chance of "false positives". For mailing list
problems it's solved by definition, so this is no "false
positive" - it is only a harsh self-restriction on the
side of the author domain, they are not forced to state
"dkim=discardable" if they don't like the consequences.
But for Resent-* the author domain has no authority over
resenders. Everybody is entitled to resend mail, years
after it arrived. ADSP claiming that such legit Resent-*
scenarios are "discardable" is a process failure. This
means "DO NOT PUBLISH", not "mission creep".
More information about the ietf-dkim