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

[Alessandro Vesely <[e-mail]>]

On Tue 02/Apr/2024 15:35:05 +0200 Murray S. Kucherawy wrote:
> On Tue, Apr 2, 2024 at 3: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.


>>> If "most" mailing lists have arranged rewrites or non-mutation, and this 
>>> appears to be working, are there specific techniques we should 
>>> standardize here?
>>
>> I believe it's possible to leverage ARC so as to overcome those mailing 
>> lists hacks, for an expanding set of domains.  It is not difficult to 
>> modify ML software in order to rewrite and/or mutate on a per-user basis. 
>> One can obtain the same effect with existing software if it provides for 
>> twin lists or similar means to split users into two categories. >
> This isn't consistent with your previous comment, which claimed that "most" 
> lists are already doing this.  Your language here is more like a proposal. 
> I'm having a hard time following.


Oh, perhaps you asked if we should standardize the nasty hack?  IMHO, we 
shouldn't.  We didn't standardize COI either.

We should standardize some proposals that make ARC work consistently for 
forwarders (including MLs) of any size and kind.


> What is it that you believe we should be telling industry to do?


Experiment with new proposals until we find one that works?


>>> Are you suggesting we need some standard way to calculate and/or share a 
>>> sealer's reputation for any of this to work?
>>
>> Sealer's reputation is the same as domain reputation.  Good to have it, 
>> whenever it comes.
>
> I interpreted your earlier remark to be a claim that this stuff won't work 
> absent such data.


A reliable reputation database will certainly make everything email work 
better.  However, ARC usage with local trust contracts, granted on a case by 
case basis could work even without it, methinks.


>> For ARC, I'd rather consider per-forwarder contracts.  Forwarding (of 
>> which MLs are a case) doesn't happen out of the blue.  It has to be set 
>> up. Involving the target receiver in the setup may make it trust the 
>> sender's seals, when they belong to the stream thus set up and 
>> identified.
>
> So, a "contract" between each mailing list and each subscriber?  What would 
> that mean?


A contract would mean the same as COI, but involving (also) the subscriber's 
MBP.  Is it really you?  You sure you want to subscribe to this?  Then I'll 
trust the ML when it ARC-seals messages with this List-Id: destined to you, for 
example.


Best
Ale
--