On 6/23/11 8:24 AM, John Levine wrote: > In article<[email protected]> you write: >> On 6/22/11 11:14 AM, Dave CROCKER wrote: >>> Folks, >>> >>> The bottom line about Doug's note is that the working group extensively >>> considered the basic issue of multiple From: header fields and Doug is >>> raising nothing new about the topic. > Dave is quite right. Doug's purported attack just describes one of > the endless ways that a string of bytes could be not quite a valid > 5322 message, which might display in some mail programs in ways that > some people might consider misleading. If it's a problem at all, it's > not a DKIM problem. Perhaps you can explain why the motivation stated in RFC4686 includes anti-phishing as DKIM's goal? Why of all the possible headers ONLY the From header field MUST be signed? Why RFC5617 describes the From header field as the Author Author address that is positively confirmed simply with a Valid DKIM signature result? Both RFC4686 and RFC5617 overlooked a rather obvious threat clearly demonstrated by Hector Santos on the DKIM mailing list: Pre-pended singleton header fields.
Neither SMTP nor DKIM check for an invalid number of singleton header fields. These few header fields are limited to one because they are commonly displayed. Multiple occurrence of any of these headers is likely deceptive, especially in DKIM's case. DKIM always selects header fields from the bottom-up, but most sorting and displaying functions go top-down selection. Complaints from John, Dave, and Barry and others is likely and understandably out of fatigue. They just want the process to be over. We are now hearing there is a vital protocol layering principle at stake which even precludes DKIM from making these checks! Really? Although DKIM will be securely hashing the headers fields which MUST include the From header, developers are being told they must ignore multiple singleton header fields discovered in the process. It is not their burden! As if securely hashing, fetching any number of public keys, and verifying any number of signatures isn't? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
