These are not MSA or MDAs so its a different set of assumed preconditions. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com
Murray S. Kucherawy wrote: >> -----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
