Sorry about the confusion caused by my typing failures. What I meant: First party - From address aligns with SMTP address. Can be validated with SPF or DKIM. Third party - From address and SMTP address are in different domains. Can be validated with DKIM only. I am open to suggestions for better nomenclature.
But what I am trying to figure out is under what circumstances a DMARC policy can be considered actionable. Do I conclude that "p=quarantine" means "domain is still collecting data, so results are unpredictable"? Or do I conclude that it means "Domain is fully deployed and failure to validate is a highly suspicious event?" Take the case of a SMTP-aligned message which does not have a DKIM signature. If it is received directly, it is DMARC compliant. If it is received indirectly, it is a presumed spoof. It cannot be both valid and spoofed. Whether the message gets forwarded is not under the sender's control. If I receive it directly it is presumed valid, but does it signal that the domain is still struggling to implement DMARC, so their policy should be ignored on future messages? Or if I receive it indirectly, should I try to reverse engineer whether it was SPF-aligned before it was forwarded? Since all messages need to be DKIM-signed to survive a possible forward, should SPF even be part of the DMARC criteria? I am simply wondering if a DMARC policy has enough reliable information to be of any value, at least for any setting other than p=reject pct=100. This is intertwined with the ambiguity about what the sender means for any policy other than p=reject pct=100. My opening post was an attempt to define milestones that should be associated with specific settings. But maybe the only certainty is that the domain is collecting data and consequently spoof-prevention must be based on evidence other than the DMARC policy. DF On Mon, Dec 14, 2020 at 10:36 AM Laura Atkins <la...@wordtothewise.com> wrote: > > > 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> > wrote: > >> >> >> On 13 Dec 2020, at 21:44, 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. 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> 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 >> >> >> -- >> 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 >> > _______________________________________________ > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
