On Sun, Dec 13, 2020 at 5:41 PM Dotzero <dotz...@gmail.com> wrote: > > > On Sun, Dec 13, 2020 at 4:45 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Based on this discussion, it seems evident that p=reject should include >> language about in-transit modifications which are outside the control of >> the source domain, and consequently outside the ability of DMARC to guide >> recipients. >> > > And the buzzer goes off. Sources and modifications outside the control of > the domain in the RFC 5322 From is exactly what DMARC is addressing. That > is exactly the guidance that is being provided by a domain publishing a > DMARC record. >
Do you mean that DMARC p=reject intends to block mailing lists that do content alterations, so there is not a mailing list problem at all? > > >> Extending from that, I thought it would be helpful to specify some shared >> assumptions between sender and evaluator to make the interpretation of the >> settings less subjective. I call this the "Minimum expected >> implementation at pct=100". >> > > "Shared assumptions" is a poor assumption in writing a technical standard > for interoperability. > Then change the language to SHOULD and make it a requirement. Here is the point: Sender policy is intended to help the evaluator divide incoming messages into three groups: - verifiably sent by the From domain - uncertain - verifiably NOT sent by the From domain (spoofed) The evaluator has two results to work from: Verified or Not Verified. Sender policy provides guidance for splitting the unverified messages between "uncertain" and "spoofed" by providing information about which messages SHOULD be verifiable. This is inherently a communication protocol and it has not been well defined, which is why the question has been raised, "What does p=quarantine actually mean?" It is a derivative of the earlier Chair question, "what does it mean to implement DMARC?" One could argue that anything other than "p=reject pct=100" is a non-policy which provides no useful guidance, equivalent to the SPF token ?ALL. But then we have the mailing list problem, so even at "p=reject pct=100" we have a problem with false positives (messages actually sent by the source domain but not verifiable because of in-transit changes.) So maybe DMARC has no ability to distinguish between spoofed and unverifiable messages. What seems useful is to define the capabilties and the limitations of DMARC, then define a signalling protocol so that the sender correctly signals which messages are DMARC-protected and the evaluator understands that signal in a manner which can be applied to an incoming message. I do not see that we have such a protocol at present. Rather, the evaluator is left with a lot of guesswork,and that means that the source domain owner is left with a lot of guesswork about how the recipients will make their guesses. DF
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
