Re: [dmarc-ietf] Overall last-call comments on DMARC

[Alessandro Vesely <[e-mail]>]

On Wed 03/Apr/2024 18:49:50 +0200 Murray S. Kucherawy wrote:
> On Wed, Apr 3, 2024 at 4:16 AM Alessandro Vesely <[e-mail]> 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
--