-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Sunday, October 17, 2010 6:23 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Data integrity claims
By DKIM process, I would include anything cognizant of DKIM upto but
not including the MUA. Mike's secret sauce would count here, eg.
Current implementations, especially the two library ones that are referenced
most often in here, haven't the functionality to cause header fields to be
removed, prefixed, reordered, modified, etc. This change would require them to
be overhauled to extend their reach into what the MTA can do. That expansion
of scope of "DKIM process" to me requires a recycle at Proposed Standard.
As others have said, there is nothing between DKIM and the MUA that
prevent DKIM exploitation so who is going to solve that problem if not
us?
There's nothing between an MTA and an MUA that prevents this attack in the
non-DKIM case at all. Whose place is it to fix that?
I can't get my head around how that case is irrelevant here. This is not a new
problem, but somehow we're being called upon to deal with it.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html