> On 14 Dec 2020, at 15:11, Douglas Foster > <dougfoster.emailstanda...@gmail.com> wrote: > > I called that a third-party message, since the RFC5321.MailFrom domain is > different from the RFC5322.From domain.
No, you didn’t. Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) I think ‘first party’ and ’third-party’ are problematic definitions in any case and I’m not sure I understand what your goal is here. Who are you considering ‘party’? laura > I am open to revisions of how the boundaries should be defined, but as I said > in my reply just now to Michael Hammer, we need to define those boundaries in > a way that both sender and receiver understand. This is the full problem > description: > > We have these three types of senders: > - first-party senders > - third-party senders > - spoofers > > We have these four verification states at initial transmission: > - none > - spf only > - dkim only > - spf and dkim > > We have these 9 routing scenarios: > - direct (1) > - indirect (8) > with and without SMTP rewrite > with and without FROM rewrite > with and without content modifications > > Upon receipt, we have these verification states: > - Not verified > - SPF only > - DKIM only > - SPF and DKIM > > For messages that do not verify, the evaluator uses sender policy (none, > quarantine, reject) to categorize the message as either "verifiably spoofed" > or "uncertain". What is the algorithm for doing so? > > DF > > > On Mon, Dec 14, 2020 at 5:05 AM Laura Atkins <la...@wordtothewise.com > <mailto:la...@wordtothewise.com>> wrote: > > >> On 13 Dec 2020, at 21:44, Douglas Foster >> <dougfoster.emailstanda...@gmail.com >> <mailto: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. 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". > > What about messages which do not have SPF verification but do have DKIM > verification? A significant number of email platforms use their own domains > in the 5321.from address but have the customer sign with DKIM. In many cases, > DKIM signing is actually free, whereas making the SPF align is a paid > service. > >> 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 >> <mailto:dcroc...@gmail.com>> wrote: >> On 12/11/2020 9:37 AM, John Levine wrote: >> > In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com >> > <mailto: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 <mailto:dcroc...@gmail.com> >> 408.329.0791 >> >> Volunteer, Silicon Valley Chapter >> American Red Cross >> dave.crock...@redcross.org <mailto:dave.crock...@redcross.org> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org <mailto:dmarc@ietf.org> >> https://www.ietf.org/mailman/listinfo/dmarc >> <https://www.ietf.org/mailman/listinfo/dmarc> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org <mailto:dmarc@ietf.org> >> https://www.ietf.org/mailman/listinfo/dmarc >> <https://www.ietf.org/mailman/listinfo/dmarc> > > -- > Having an Email Crisis? We can help! 800 823-9674 > > Laura Atkins > Word to the Wise > la...@wordtothewise.com <mailto:la...@wordtothewise.com> > (650) 437-0741 > > Email Delivery Blog: https://wordtothewise.com/blog > <https://wordtothewise.com/blog> > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org <mailto:dmarc@ietf.org> > https://www.ietf.org/mailman/listinfo/dmarc > <https://www.ietf.org/mailman/listinfo/dmarc> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
