On Wed 03/Apr/2024 18:49:50 +0200 Murray S. Kucherawy wrote:
On Wed, Apr 3, 2024 at 4:16 AM Alessandro Vesely <ves...@tana.it> wrote:
Some sort of contract or agreement between sender and receiver seems to me
to be unavoidable if we want to leverage ARC without having a global domain
reputation system. We don't have a precise method to do that. We need to
experiment and standardize something to that extent, which I hope this WG
can do after publishing -bis.
I know what "contract" means abstractly, but what does this actually look
like to someone that's looking for specific guidance? The text you have
here, by itself, is vague and I don't think many operators will know what
to do with it.
A file in each user's home directory listing allowed pairs of ARC's d= domain
and the list-id identifier of a List-Id: field? Whatever. What do Google use
to determine if an ARC seal is trusted?
We don't have much concrete experience on how to set up a contract, though.
Meanwhile, we can mention ARC, in Section 5.8 (minimal text proposed in
another thread[*]). How much can we expand that? For example, can we
whisper something about the need to trust specific sealers for specific
streams?
If you really need ARC to make all of this work and interoperate with
lists, then I think we need to start talking about how we want to move ARC
out of "Experimental" first so it can become a normative reference.
Back to timing here. DMARCbis I-Ds seem to be mature enough to go out, even if
there are not yet a practical solutions to the ML problem. Further delaying
them until we find one is inadvisable.
Yes, we need ARC, but we also need a method to convey agreements based on it.
We couldn't spell out a solution even if ARC were standard track already.
We can just hint at it. Parts of the Doug's text sound good for that. Here's
a variation on it, mixed with the 2nd paragraph of Section 5.8:
Mail Receivers MAY choose to accept email that fails the DMARC mechanism
check even if the published Domain Owner Assessment Policy is "reject".
Some legitimate messages are forwarded on behalf of an individual account,
based on an established relationship between the sender and the account
owner, but without domain owner involvement, These messages are legitimate
in the sense that the RFC5322.From address represents the true author, but
the messages do not produce DMARC "pass" on the last hop because the DKIM
signature was broken (mailing list) or because authentication at the
previous hop was based solely on SPF (non-mutant forwarding). In either
case, such messages can be characterized as belonging to a very specific
mail stream.
An emerging protocol to help handling these cases is [ARC]. Besides
providing an assertion of responsibility equivalent to DKIM, it also
demonstrates the 'chain-of-custody' of a message by certifying what the
Authentication-Results were when the message entered the forwarding
organization(s). How to establish the recognition of the relationship
between a given mail streams and the domain responsible for feeding it is
outside the scope of this document. However, because of the considerations
discussed in [RFC7960] and in Section 8.6 of this document, it is important
that Mail Receivers not reject messages solely because of a published
policy of "reject", but that they apply other knowledge to avoid situations
such as rejection of legitimate messages.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
