Does "Trusted Attestation" have any envisioned implementation other than an ARC Set? Murray has said that we cannot impose obligations on mailing lists, because he does not perceive them as DMARC participants. But to my mind, "Trusted Attestation" means that the mailing list SHOULD provide an ARC Set and MUST do so if it wants the benefit of this paragraph.
A problem remains because we have not solved the communication problem between mailing list and evaluator. As long as the mailing list is unaware that the evaluator complies with this paragraph, the list will mung. The evaluator could un-mung, of course. But if lists want to eliminate munging completely, they need to request and obtain feedback from evaluators, to know that they are "trusted attestation sources". Once they have that knowledge, they need to do conditional munging. This also becomes an imposed obligation on mailing lists. Do we ignore it? Doug Foster On Mon, Jul 31, 2023 at 3:07 AM Alessandro Vesely <ves...@tana.it> wrote: > 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 <rich...@highwayman.com > > <mailto:rich...@highwayman.com>> wrote: > > > > [...] > > <mailto:55584702-38bb-31a3-e4b7-99efab189...@tana.it>>, Alessandro > > Vesely <ves...@tana.it <mailto:ves...@tana.it>> 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: exam...@paypal.com > > <mailto:exam...@paypal.com> > > 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 > > 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 > > _______________________________________________ > 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
