Comments below for future readers that may come to this via an archive. On Feb 27, 2013, at 5:54 PM, "John R Levine" <[email protected]> wrote:
>> The receiver acted as the DMARC policy told him to. > > Correct. The problem is that the sender was (even though he didn't > realize it) lying about his actual policy. As Franck alluded to, there is no "actual policy" aside from the one published in a DMARC record. >> Exceptions to the rule needs to be carefully understood and remain as >> exceptions. > > Correct. The sender should publish p=none to describe his actual policy. No > exceptions needed, although given that this sort of sender confusion is not > going away, a certain number of exceptions would likely limit the collateral > damage. I suggest staying away from attempting to divine the will of the sender to establish "actual policy" and instead use the published policy in the DMARC record. If you're a receiver and you make exceptions when applying policy, go ahead and use the "override" flags in the XML spec. This is why they're there, by design. If you're a sender and you discover a service that is making use of your domain in From: headers, that's great! This is why the feedback component was invented. If your current p= policy is too aggressive, relax it, thats why there are different policies to pick from. > >> In that case PayPal CAN know and correct the problem so they should and not >> the receiver. > > Paypal didn't do anything wrong. Please, can we not have the "everyone in > the world has to rewrite their mail systems so SPF can handle it" argument > again? John, you keep mentioning this, but I don't see anyone arguing. PayPal is neither right nor wrong, they simply want to make their email compatible with DMARC. HTH, =- Tim _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
