+1, well said Mark.
Its a real potential situation that is on par, IMTO, with what the
DKIM technology was suppose to help with. It was unfortunate it fell
through the cracks during the Threats Analysis RFC 5016 production. If
it was realized back then, I don't think anyone would be debating who
is the blame and what was needed to be done (written into the RFC 4871
specs).
In retrospect, I recall most discussions was around multiple addresses
possible in the single 5322.From header and how to deal with that,
especially in regards to redundant POLICY lookups.
If I recall, the consensus was that only the first address in the
potetial list of from addresses in the single 5322.From header was the
only important author domain for POLICY considerations.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Mark Delany wrote:
Murray wrote:
My objection isn't so much layering within the software,
because I know that gets mushy real quick, but layering among
the protocol specifications. For example, we wouldn't include
in an SMTP specification some text about dealing with fuzzy
TCP implementations, and what people are talking about here
makes just as much sense to me.
The problem is that I don't think we are really just talking about
getting a protocol right from a bits perspective.
If DKIM has any value it's that it ultimately affects the user mail
experience for the better. Consequently, to remain silent on matters
that we know will adversely affect that experience seems
contradictory. Similarly to not offer guidance to implementors on the
sorts of things they can do to maximize the value of DKIM seems
similarly to miss the point.
Furthermore, DKIM specifically came into existence to deal with an
adversarial environment whereas 821/822 and the like have very
specific "just get the bits right" goals.
So guiding verifiers to assume the worst seems consistent with our
intent or at least our genesis.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html