Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

So we disable SPF when the sender tells us to do so., but leave it enabled by defaultThat makes a lot of sense to me. When the domain passes SPF on a shared server farm, but provides no DKIM signatures, I currently have no choice other than to consider the message to be authenticated. The

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

The data we presented June 20th (archive ) also suggests that it is premature to drop SPF from DMARC. However I differ in believing that we should accept the spoofing risk demonstrated recently via SPF, and that we

Re: [dmarc-ietf] Another p=reject text proposal

It's actually not even enough to check when you subscribe, though that will help keep the user from being surprised later. But you also have to check every time a message is posted to the list, because anyone's domain could have changed to p=reject recently. And anyway, yes, the IETF considered

Re: [dmarc-ietf] Another p=reject text proposal

Barry Leiba writes: > > 2) As others have observed, the mailing list problem is > > exclusively an evaluator error. An evaluator's job is to allow > > safe and wanted messages while blocking unsafe or unwanted > > messages. > > I disagree. As I and others have observed, those creating the

Re: [dmarc-ietf] Another p=reject text proposal

> To Murray's observation about fairness, my thoughts: I don't see any use of the word "fair" in the message from Murray that you quote. > 1) Life is not fair. This is impolitely dismissive. Please don't do that. > 2) As others have observed, the mailing list problem is exclusively an >

Re: [dmarc-ietf] Another p=reject text proposal

To Murray's observation about fairness, my thoughts: 1) Life is not fair. 2) As others have observed, the mailing list problem is exclusively an evaluator error. An evaluator's job is to allow safe and wanted messages while blocking unsafe or unwanted messages. 3) The problem can be solved by