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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 2 Mar 2007 12:22:59 -0800

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:[email-masked]] 
> 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