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 PROTECTED] > 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
