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 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
