[ietf-dkim] Issue 1579: ADSP result set, New issue: ADSP status codes

[Frank Ellermann]

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

See <http://rfc-editor.org/errata_search.php?eid=1461>

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

 Frank