+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