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

[Frank Ellermann]

John Levine wrote:

> I also see that nobody has confirmed it.

After three days that would be rush.  A missing comma in
RFC 2045 reported by a co-author 44 months ago is still
not "confirmed".

> If the DKIM authors agree it's a mistake, then we should
> change it.  Otherwise, consistency wins.

As noted in the erratum this is consistent with the rest
of this section in RFC 4871, with the FWS rationale in 
RFC 4871 chapter 2.3, and with MUSTard in 2822 + 2822upd.

There is no such thing as "x" *FWS "y", this would allow:

x<CRLF>
<SP><CRLF>
<SP><CRLF>
<SP><CRLF>
<SP>y

But that also matches "x" obs-FWS "y", and so there can't
be a valid reason to talk about *FWS in conjunction with
RFC 4871 chapter 2.3.  

A similar RFC 2822 FWS erratum reported 30 months ago is
also not yet "confirmed", it was simply fixed in 2822upd.

>> 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".
 
> Um, I think this might be a good time to review what DKIM
> is and isn't.  It's intended to protect messages in transit,
> not in archives.  Umpteen years later, with or without
> Resent headers, the signing key is unlikely still to be
> in the DNS, so any process that depends on verifying DKIM
> on old messages won't work.  ADSP doesn't change that.

If the ADSP draft somewhere states that adding Resent-* in
some legit or malicious ways is intended to bypass all ADSP
processing I missed it:  I only looked for strings beginning
with "resent-".  

Next radical attempt, I now read the security considerations
from scratch, nothing.  Following the pointer to RFC 4686 =>
nothing about "discardable" attacks on legit Resent- mails.

 Frank