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

[Alessandro Vesely <[e-mail]>]

On 02/04/2024 20:16, Murray S. Kucherawy wrote:
> On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely <[e-mail]> wrote:
> 
>>>>>> By now, most mailing lists arranged to either rewrite From: or not break 
>>>>>> DKIM signatures.  We all hope those hacks are temporary.
>>>>>
>>>>> What do you mean by "temporary", given the time scales that have already 
>>>>> passed since RFC 7489 saw wide deployment?  Do you envision those 
>>>>> techniques ending sometime soon?
>>>>
>>>> Yeah, the time scale is killing us.  Is ten years soon enough?
>>>
>>> You tell me.  You say you're hoping they're temporary, yet they've been 
>>> around a long time and I'm not sure that there's an alternative on the 
>>> table.  I'm asking you to explain.
>>
>> I believe alternatives are possible.  Can't say how long it's going 
>> to take, but I presume when they are available, the nasty hacks 
>> will slowly fade out.>
> So what are you suggesting should go in this document that's in WGLC?


Section 8.6 states the ML problem very well, but it says nothing about the way forward.  Section 5.8, cross referenced with 8.6, talks about "other knowledge and analysis".  Neither that is forward looking, as it seems to suggest some kind of presently available, heuristic content analysis.

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.

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?

In Section 8.3 the draft says:

     550 5.7.1 Email rejected per DMARC policy for example.com

I guess it would be too much to say:

     550-5.7.1 Email rejected per DMARC policy for example.com,
     550-5.7.1 ARC seal by forwarder.example verified but not trusted.
     550 5.7.1 See https://receiver.example/arc-streams-registration/

Wouldn't it?


Best
Ale
-- 

[*] https://mailarchive.ietf.org/arch/msg/dmarc/1aPplXPF1cYpnRzYHgxsTCPPzHg