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.

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

<snippage>

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

"Shared assumptions" are not definitions, they are hopes. Again, not a good
basis for a technical standard.

Michael Hammer
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to