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

[Alessandro Vesely <[e-mail]>]

On Thu 04/Apr/2024 18:13:37 +0200 Murray S. Kucherawy wrote:
> On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely <[e-mail]> wrote:
> 
>>> 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? >
> I'm a Gmail user.  What's a "home directory"?


The place where they store your account information, including messages.


>>>> 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. >
> Then why are we tossing about all these ideas during WGLC, muddying the 
> waters?


Muddying is unintentional.  It is an attempt at marking the way forward.


>> 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: >>
>> [...]
>
> So if I can summarize, I believe you're saying:
>
> Here's a Proposed Standard.  In some common deployment scenarios, we know 
> that it has some undesirable side effects.  There isn't any concrete way to 
> fix that as part of the PS.  You could do some X, which is this new-ish 
> experimental thing, or you could do some Y, or maybe both, and Z might 
> help, "whatever", but only one of those is well-defined, and none of them 
> are part of this PS nor are they published yet, and there's a non-zero 
> chance that we'll run out of energy and not actually do so.
>
> Is that what you want to send to the IESG?


The current text only mentions Y and Z, in about the same tone (other knowledge 
and analysis).  Mentioning a work-in-progress X marks the way forward.  If the 
WG agrees ARC is the way forward, that is.


Best
Ale
--