On 7/21/2014 10:44 AM, S Moonesamy wrote:
Hi Dave,
At 06:59 21-07-2014, Dave Crocker wrote:
Really???
Yes.
The sentence is factually incorrect, about basic matters of SPF and
DKIM, and these matters are commonly misrepresented and understood.
In other words, the fact that an IETF standards track document is
mischaracterizing important bits of technology is problematic to a
meaningful level.
It is one sentence and it starts with "Recent work" and provides two
Informative references. There were significant issues with those bits
of technologies. RFC 5321 does not say anything about that.
SM,
Sorry, but I'm confused again.
While yes, the references are informative, the sentence that uses them
is fundamentally incorrect, and ways that matter. As for 'issues with
those bits of technologies', I'm not sure what you mean or how it is
relevant here.
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.
The question is whether to retain the current language, replace it, or
drop it.
Given the problems with the existing text, I am not understanding your
basis for suggesting its retention.
I've yet to see any merit-based argument made for retaining the text about
DKIM.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp