> 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 > 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 problem are the ones who are using p=reject in a way that it was not intended to be used. Many who support that use say that it's necessary to use it that way; I and others disagree with that, and we can have and are having that discussion. But that *is* the genesis of the problem. It's not fundamentally a mailing list problem and it's not really an evaluator problem (but I'm willing to look at it partially that way, because evaluators do have a choice, within DMARC, about how to use the information that DMARC provides). > 3) The problem can be solved by senders not asserting reject, by lists > rewriting From, or by evaluators > using more than DMARC Fail alone. Our document should address all three. > The only one that is > guaranteed to provide delivery under all sender-evaluator combinations will > be From rewrite. I don't think DMARCbis should be addressing what mailing lists can do to work around it, and I disagree with your last sentence there: rewriting the "From" header field has many problems and fails in a number of ways, making it *not* guaranteed to provide delivery. It's also violating the sense of what "From" and "Sender" fields are meant to convey. As many of us have said, it's an ugly hack and is not something that should be in a Standards Track specification. Barry _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
