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-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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