On 24 Jun 2011, at 03:46, Douglas Otis wrote: > On 6/23/11 2:52 PM, John R. Levine wrote: >>> Acceptance policies and results for DKIM MUST align with >>> what is being displayed in the message. >> I'm pretty sure that we have uniformly agreed not to attempt to do MUA >> design, so, no, it doesn't. We have no idea what is displayed in the >> message. We have no idea if the message will ever be displayed at all. > Ian, > > John is right. Most headers are displayed selecting top-down and DKIM > always selects bottom-up. Headers likely displayed and selected to be > signed need to be check by some protocol layer that ensures they are not > illegally pre-pended. Unfortunately, both SMTP and DKIM will not make > these basic checks. There seems to be a prevailing assumption undefined > spam filters will instead intercede. Who should victims blame when > these checks are not made?
They should blame (a) the spammer, and (b) their local MTA operator. Even though we don't do MUA design, somebody has to. It's helpful if there's a set of people in the world that have considered these issues, and can give advice on them. > How can a secure system be specified? With this particular issue, it seems that an MTA could simply insist that a message comply with RFC5322's requirement that there be exactly one "From:" header. Now, we could say in DKIM that a signature is invalid if there's more than one From: header present in the message. Or we could informally advise MTA or MUA designers that ignoring RFC5322's requirements here is inadvisable, since DKIM has that assumption. For me, as an MTA operator, I'm happy that I have justification for rejecting messages with the wrong number of From: headers. > -Doug > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
