> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of John R. Levine > Sent: Tuesday, October 19, 2010 2:47 PM > To: DKIM List > Subject: [ietf-dkim] double header reality check > > > So it establishes a false sense of resolving a security issue. > > Hmmn. I could reiterate for a fourth time why the double header thing > is only a security issue in the context of DKIM, but there's clearly > something else going on that prevents people from getting it.
Obviously you believe your view is unassailable, but please stop asserting that people who don't see it your way are automatically thick. > Here's a question: in the absence of DKIM, does anyone think that > doubled headers present a security problem? I have also repeatedly said "yes" to this question. > If so, what is the > problem, and how has it been addressed in the past? Any filter or agent that makes any kind of filtering, routing or sorting decision based on any header field which in turn presumes there's only one such field without actually checking is a potential security concern. That extends not only to routing and filtering of messages, but also to their rendering. Examples: - procmail, which by default acts on the first match it finds without first confirming RFC5322 validity, so if I know or can figure out your rule sets I can do something that will get bad mail into a good folder or other internal mail stream, and then an MUA could render the From: or whatever field that wasn't the one subjected to filtering (as your own experiment showed) - SpamAssassin, which can reformat possible spam by wrapping it in MIME content using new header fields extracted from the original message, but only takes one (the last) of each of the ones listed in its man page when doing so, meaning a filtering action can be taken that results in false data being rendered in the report; then the user sees that something he/she wanted was tagged as spam and complains (there may be worse exploits, that's just the most obvious one after my code review) - Mailman authenticates postings and subscription requests based on the first instance of From or Sender it finds, but relays both so a downstream filter or MUA would see both and thus potentially make a wrong handling (rendering/filtering/routing) decision - majordomo, same as Mailman There were several instances I found as well in other lesser-known filtering tools, but these ones will hopefully provide some context. And since those problems are there in the code for each I just downloaded and reviewed, I would say they have not yet been addressed. Since the issue is an attempt to fool users, those seem to me to be in the same family as the other thing we're talking about. And none of them have anything at all to do with DKIM. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
