> -----Original Message----- > From: Rolf E. Sonneveld [mailto:[email protected]] > Sent: Monday, September 13, 2010 5:28 PM > To: Murray S. Kucherawy > Cc: MH Michael Hammer (5304); [email protected] > Subject: Re: [dkim-ops] hammering with a soldering iron, was subdomain vs. > cousin domain > > > On 09/13/2010 09:19 PM, Murray S. Kucherawy wrote: > >> -----Original Message----- > >> From: MH Michael Hammer (5304) [mailto:[email protected]] > >> Sent: Monday, September 13, 2010 12:06 PM > >> To: Murray S. Kucherawy; [email protected] > >> Subject: RE: [dkim-ops] hammering with a soldering iron, was subdomain > vs. cousin domain > >> > >> I think your last comment is perhaps the most interesting one. As John > >> Levine frequently reminds us as he invokes King Canute, we cannot tell > >> receivers what to do. I don't know if this association exists, but if > >> receivers find an association between failed signatures and malicious > >> email I can just about guarantee you that they will take advantage of > >> that data point..... Regardless of what the standard says. Bottom line, > >> a failed signature will be treated in accordance with those things that > >> a failed signature is perceived to be associated with. > > Naturally that's true, but I think until there's evidence that a > negative validation should mean something, I'm inclined to believe the > RFC's advice is right. > > +1. Please let's not degrade the status of RFC4871 to 'Experimental'. > The RFC is clear about how to treat failed signatures. We don't have to > accommodate for all possible wrong interpretations of the RFC, do we? > > /rolf
Rolf, There is no intent to degrade the status of RFC4871 to 'Experimental'. I refer you to section 6.3 and the following: "However, if the verifier does opt to reject such messages (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and the verifier runs synchronously with the SMTP session and a signature is missing or does not verify, the MTA SHOULD use a 550/5.7.x reply code." There is clearly activity in the prior agreement space - particularly "trusted 3rd parties" that falls under the above. Mike _______________________________________________ dkim-ops mailing list [email protected] http://mipassoc.org/mailman/listinfo/dkim-ops
