That is a different issue all together. We are talking about a security threat that fell through the cracks during the RFC 5016 production in this group.
It MUST be corrected - pronto, not later, not in another I-D, not in another WG. No - in 4871bis. It is rather tiring to seeing the rationalization on how to try to avoid not directly talking about the security loophole and resolution. Whether its MUST, SHOULD or it should not do anything and pass the buck to a lower layer. That is all nonsense. While in an integrated environment, you have all sorts of ways to resolve this, a DKIM is an independent RFC 5322 Protocol Technology - therefore it inherent all the design requirements to make sure that GIGO (Garbage In, Garbage Out) does not occur. Lets fix the "DOC BUG" and be done with it - thats forward progress. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com J.D. Falk wrote: > On Oct 21, 2010, at 11:13 AM, John R. Levine wrote: > >>> The verifier MAY treat unsigned header fields with extreme >>> skepticism, including marking them as untrusted or even deleting them >>> before display to the end user. >> That's an example of the bad advice that I think we should drop from >> 4871bis. It does nothing to improve robustness or interoperability, just >> offers unsolicited advice to MUA developers. > > As this conversation has continued, I'm increasingly convinced that the only > sane path forwards is to have a separate Informational or BCP document > containing MUA considerations. The only question is whether that'd be > restricted to considerations we've discovered while discussing DKIM (in which > case it might fit in this WG), or open to all the stupid MUA tricks this > community has seen since rfc733 (which should probably be a new WG.) > > Either way, I'd be interested in participating in the effort. > > > _______________________________________________ > 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