On Apr 27, 2010, at 1:34 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Jeff Macdonald [mailto:[email protected]] >> Sent: Tuesday, April 27, 2010 10:05 AM >> To: McDowell, Brett >> Cc: Murray S. Kucherawy; [email protected] >> Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists >> should strip DKIM signatures >> >>> That's interesting. Let's make this concrete... I'll use myself as >> an example. >>> >>> X = me/PayPal.com >>> Y = this list/[email protected] >>> Z = Google's Gmail service [1] >>> >>> It is my assumption that someone subscribed to this list has a >> gmail.com account (or a Yahoo.com account [2]). Therefore, my use case >> is simple. I would hope that those of you reading this from your Gmail >> or Yahoo! accounts actually receive this message. If Z breaks the >> signature, you won't see this. >> >> how about Y breaking the signature? I see your message only because I >> told gmail's filtering system to not put messages into the spam folder >> for this list. Otherwise it would of gone into the spam folder. >> Looking at the source of the message, I only see the list's DKIM >> signature. > > Y breaking the signature isn't relevant (in this hypothesis). Y also says > when it got the message from X, X's signature was intact. That Y messed up > the signature, making Z unable to verify it directly, is not important; Z > trusts Y, so Z trusts Y's Authentication-Results: that says X's signature was > fine when it got to Y. > >> Should the policy statements be ignored at that point? > > In this hypothesis, they could be. Or, they could be applied. If X's ADSP > says "all" or "discardable", and Z trusts Y, and Y claims X's message had a > valid signature, ADSP is satisfied. >
That's how I see it. The key is that Y *validates* the DKIM signature and processes the sender's ADSP when it receives the message before taking it's next action. If Y didn't actually validate with comparable rigor as Z, then Z would have no basis to trust mail from Y. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
