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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html