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