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. 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".
p=none Minimum expected implementation at pct=100: All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From domain) are verifiable using SPF, but may not have a DKIM signature. Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) may or may not have DKIM signatures. Consequently, indirect messages are often not verifiable using DMARC. p=quarantine Minimum expected implementation at pct=100: All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From domain) are verifiable using SPF, but may not have a DKIM signature. Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) are verifiable using DKIM signatures. Consequently, indirect messages may or may not be verifiable, depending whether the forwarded message included a signature. p=reject Minimum expected implementation at pct=100: All first-party direct messages (RFC5321.MailFrom domain matches RFC5322.From domain) are verifiable using SPF and DKIM. Third-party direct messages ( RFC5321.MailFrom domain does not match RFC5322.From domain ) are verifiable using DKIM signatures. Indirect messages which are not modified in transit are verifiable using DKIM signatures. Indirect messages which are modified in transit are outside the scope of DMARC and must be evaluated by other criteria available to the recipient system. Having defined the policies/categories in these terms, the logical next step would be a best practices document which discusses how an evaluator might distinguish between direct messages, indirect unmodified messages, and indirect modified messages. ARC obviously plays a role in making these distinctions easier to determine and less error-prone. Doug Foster On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker <dcroc...@gmail.com> wrote: > On 12/11/2020 9:37 AM, John Levine wrote: > > In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com> you > write: > > aligned is not authorized by the domain owner and may be discarded or > rejected by the recipient. > > Naah. > > > > p=reject: all mail sent from this domain should be aligned in a DMARC > > compliant way. We believe that unaligned mail is from unauthorized > > senders so we ask receivers to reject it, even though that might mean > > some of our authorized senders' mail is rejected too. > > > As soon as this specification text, here, contains language about how > this information is to be used, should be used, or could be used, it > crosses over into creating confusion about expectations of receiver > handling. > > It encourages misguided language such as the receiver 'overriding' > sender policy. The sender has no policies about receiver behavior, > because there is no relationship between them. Using milder language > here doesn't help, because readers typically do not read like legal or > technical scholars. > > DMARC provides information, not direction. > > The spec already contains misguided perspective by talking about > 'policy' records and, even worse, "policy enforcement considerations". > > If the document must contain language about receiver choices in message > disposition, move it to an overtly non-normative discussion section that > legitimately covers a wide range of things that receivers do or don't do > (cast as things they might or might not do.) And make sure none of the > language hints at sender 'policy', overrides, or the like. > > > d/ > > -- > Dave Crocker > dcroc...@gmail.com > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red Cross > dave.crock...@redcross.org > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
