ietf-dkim
[Top] [All Lists]

RE: Comment on RE: [ietf-dkim] 1365 yes/no

2007-03-02 13:32:51
OK now I get it. What you are saying is that spammers might attack DKIM by 
attaching nonsense signatures and that it would be useful to have a cheap way 
of determining that this is the case.

I do not agree that this saves you signature verification cycles since your 
attempt to pull the key record will fail first. But saving DNS lookups is 
certainly likely to be a benefit. 

The other advantage might well being allowing more accurate identification of 
likely spambots.


This is a policy issue I would be happy to leave to a phase II but its not a 
major implementation cost. All that is needed is a tag NO-DKIM. Since I don't 
anticipate a need for policy to be more than fifteen pages I won't argue 
strenuously against it.




-----Original Message-----
From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org] 
Sent: Friday, March 02, 2007 1:00 PM
To: Hallam-Baker, Phillip
Cc: ietf-dkim
Subject: Re: Comment on RE: [ietf-dkim] 1365 yes/no


On Mar 2, 2007, at 9:02 AM, Hallam-Baker, Phillip wrote:

I don't see how 'never sends DKIM mail' is of any value 
since there is 
a precedence order here. The key record information takes priority 
over the policy record.

So if I get mail with a valid signature I never bother to check for 
the policy.

I'll wager dollars to doughnuts that when email acceptance is 
based upon a DKIM signature, it will be done in conjunction 
with some type of accreditation.  This saves the expense of 
checking signatures where validity simply does not matter.

For high profile companies that have opted to use web based 
messaging, any DKIM signed email spoofing their domain 
creates queries for some random key, and when that fails, 
then for their policy record.  Hector could be right about 
which will come first, but components of a policy records can 
be republished with accreditation to eliminate unnecessary 
traffic generated by perhaps absorbent levels of fraud.  A 
message that appears to be signed when studied in the raw 
might mislead enough recipients, where this tactic could 
become common.  Not all providers will ensure these messages 
are blocked.

-Doug




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

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