Re: [ietf-smtp] RFC2821bis discussion of DKIM and SPF (was Re: Error in RFC 5321 concerning SPF and DKIM)

[Ned Freed <[e-mail]>]

> Hi Ned,
> At 14:16 21-07-2014, Ned Freed wrote:
> >I agree with Dave about this. This text is in the context of return
> >paths. DKIM
> >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
> >there.
> >
> >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
> >connection between
> >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
> http://tools.ietf.org/html/draft-ietf-yam-5321bis-smtp-pre-evaluation-05
> 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.

				Ned