At 14:16 21-07-2014, Ned Freed wrote:
>I agree with Dave about this. This text is in the context of return
>signs message content; it has no way to cover return paths or any
>other part of
>the envelope, which is what RFC 5321 describes. Anyone reading this is likely
>to be confused and start looking for DKIM capabilities that aren't actually
>The situation surrounding SPF is different. The text mischaracterizes what SPF
>does, but at least SPF has something to do with return paths. Some wordsmthing
>would be nice, but at least someone who goes looking for the
>SPF and return paths will be able to find something.
I am not disagreeing with Dave or you.
A look at the history of that text shows that Hector Santos flagged
the issue as a small nit. Tony Hansen probably didn't think that it
was a significant issue. I agreed with Frank Ellermann that DKIM
doesn't look at return paths. After taking all that into
consideration I would not say that there wasn't consensus about that text.
The issues identified in RFC 5321 are documented at
Barry and Stephen were the DKIM WG Chairs. They did not flag that
sentence as an issue. John Klensin, Alexey, Dave and Pete were aware
of the pre-evaluation. As John Levine mentioned, we should have
caught this stuff.
All this shows is that people weren't paying sufficient attention. Far more
egregious errors that have made it past far more rigorous reviews.
I took a look at the Errata process. I don't know how to fit such a
change in there. :-(
Well, since it now appears that Aquinas-level scholastics are required to
understand and negotiate the errata process, I neither agree nor disagree.
What I would suggest, however, is more focus on results, less on process. To
this end, I will again point out that I've yet to hear a justification for why
we should be talking about issues solely related to message content in RFC
5321. Especially when this separation - rightly, IMO - has been used in the
past to keep issues with RFC 5322 and MIME from creeping in.
ietf-smtp mailing list