[dmarc-ietf] Re: Discussion Thread for Issue 155

[Alessandro Vesely <[e-mail]>]

On Thu 24/Oct/2024 01:35:17 +0200 Murray S. Kucherawy wrote:
> 
> The charter is explicit (twice, by my count) that addressing the problems with 
> indirect mail flows is in scope for the working group.  What it doesn't make 
> clear (hence "tacit") is the understanding, at least at the time of chartering, 
> that it's not only in scope, it's required.
> 
> DMARCbis appears to address this via the text of Section 7.4, which in essence 
> tells senders to be careful about using "p=reject" if their users might use 
> lists, and tells receivers not to honor "p=reject" without doing a lot of other 
> analysis first and folding that into an acceptance calculus of some kind; 
> absent such analysis, downgrade the handling to match 
> "p=quarantine".  The completion of WGLC with no further discussion suggests 
> that the WG believes that this is satisfactory.  That's fine if so, but I claim 
> it falls short of what I imagine was anticipated, that being a protocol 
> solution, and I'm suggesting we should say something in the document that 
> reconciles or explains this.


What we don't say is the vision we have (assuming we have it).  At the end of 
7.4 we just say:

OLD:
                                                           However, as of
    this writing, use of ARC is nascent, as is industry experience with
    it in connection with DMARC.

I hold that if we had a protocol to manage forwarding recipes so that both ends 
are aware of them, then ARC could be trusted by receivers (on a per-user basis) 
and override DMARC with 100% reliability.

There is also a DKIM2 idea which incorporates diffs for any change that could 
break the signature, so that reversal of MLM transformation can always be 
applied and original signatures verified.

Either of those solves the indirect mail flows problem.  However, neither of 
those can be achieved under your Area Director guidance, if it is going to end 
around the middle of the March 2025.  And I don't think this is satisfactory.

NEW:
                                                           However, as of
    this writing, use of ARC is nascent, as is industry experience with
    it in connection with DMARC.  Pinpointing ARC's trust problem and/or
    introducing methods to reliably reverse MLM transformations can bring
    to an environment where the limitations highlighted in this section
    fade away.  Yet we publish this document with those limitations as a
    first step in that direction.


Best
Ale
--