ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank linesfor SIMPLE c14n.

2007-01-25 18:38:53

Bad actors will find signatures surviving as a result of the 'l=n'
parameter, can then add their malware which might be a very innocent
looking URI pointing to some provider's AUP.  This message can then be
sent in bulk anywhere.  The innocent URI may still cause an exploit to
occur, and recipients might have thought they were trusting you.
So who
is hurt?

Of course, the DKIM community will then need to explain to these
end users
about this wonderful feature that allowed them to be completely
confused.

My answer is that the ISP who fails to scan a message, is an idiot
and deserves to go out of business.

Come on, Doug. You're saying that DKIM is this magic thing that
obviates the need for virus scanning. Pull the other one.

Rather than blaming end users or ISP for failing to detect a possible
exploit, especially those that cross domains where a portion of the threat
is not seen (and might even be innocent on its own), the issue is with
DKIM offering a protection scheme where the recipient is _likely_ confused
about who sent what.   The blame MUST be placed on DKIM and no where else.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>