Steve, I find your arguments largely unconvincing.
> Firstly, one expressed use case for l= is "l=0" - in other words, don't > sign any of the body. In that case I can put any body content in there > I like, and it'll still be validly signed. > There are specific applications for such a case, and most of them are, in my experience, programmatic, where there is no body, or where the body is merely a comment (I've seen both forms commonly used). > Another use case is to use l= to sign a text part of an email, but not > to sign an attachment. In that case I can obviously replace the > attachment > with my own content, but depending on the details of the email structure > I may well be able to replace the text section as rendered to the user > as well. > This depends entirely on MIME multipart/alternative. Any reasonable implementation would drop a message that was signed that offered an alternate part beyond the l= length. > Another use case is to set l= to the entire length of the email as sent. > This case is a little less nonsensical than the others (though the > supposed > benefit it offers is not clear). I can still append raw content. > Depending on > the structure of the email I may well be able to have that appended > content > displayed in place of the original content. This is harder to exploit > such that > you can entirely replace the original content than the other cases, > but given > multipart mime and html there's no way I'd say it's impossible. > And another thing to point out is that even absent the signature, why would a message not be treated as suspicious if it had to parts of the same type (again, speaking of multipart/alternative)? My own (painful) experience is that this is the default for one of the most widely used UAs. > (And, if we're talking phishing attacks, which is one of the supposed > risks, > then I can put a very effective phishing attack in just the footer of > a message > anyway - the place people expect to find "Contact Us" or "Log in to your > account" or "Secure your access" links). > The whole point of l= was to say that beyond it you should treat the content as suspicious. Eliot _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
