On Sun 30/Jul/2023 17:20:59 +0000 Barry Leiba wrote:
I think Richard’s suggestion would be a fine addition to what’s there now,
but not a replacement. I would really prefer MUST in Richard’s text over
the SHOULD, given the “trusted attestation”.
Agreed. MUST whitelist, otherwise forwarding cannot work.
The trust still sounds "aspirational", of course. It is totally
subjective, as is the concept of /wanted mail/. Although it's trivial to
determine whether a specific forwarding is good —based on the knowledge of
how it came into being— doing it is an activity which has to be carried out.
Best
Ale
On Sat, Jul 29, 2023 at 12:09 PM Richard Clayton <[email protected]
<mailto:[email protected]>> wrote:
[...]
<mailto:[email protected]>>, Alessandro
Vesely <[email protected] <mailto:[email protected]>> writes
>Section 8.6, *Interoperability Considerations*
>OLD
> | It is therefore critical that receiving domains MUST NOT reject
> | incoming messages solely on the basis of a p=reject policy by the
> | sending domain. Receiving domains must use the DMARC policy as
> | part of their disposition decision, along with other knowledge and
> | analysis.
>NEW
> | It is therefore REQUIRED that receiving domains exempt from DMARC
> | disposition messages forwarded by trusted third parties, either
> | aliases or mailing lists, provided that forwarders are
authenticated
> | by a secure method. Receiving domains must seek methods to
> | acknowledge forwarders' quality and grant trust where deserved.
I think that wording is a better approach ... but the issue is not
whether the forwarder is trusted per se, but whether it reports the
origin of the email in a trusted manner and that origin leads one to
believe that the DMARC failure is to be overlooked.
A forwarder may have accumulated all the trust in the world, but if an
authorised user is compromised and sends email From: [email protected]
<mailto:[email protected]>
then PayPal's p=reject should be honoured.
The second part of the paragraph is aspirational and can be omitted
so:
Receiving domains SHOULD exempt from DMARC disposition messages
forwarded from third parties where there is a trusted attestation by the
third party that the email met the requirements for a DMARC pass when it
was received by them.
_______________________________________________
dmarc mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmarc
<https://www.ietf.org/mailman/listinfo/dmarc>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
