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

[Alessandro Vesely <[e-mail]>]

On Mon 01/Apr/2024 16:35:28 +0200 Murray S. Kucherawy wrote:
> On Mon, Apr 1, 2024 at 4:44 AM Alessandro Vesely <[e-mail]> wrote:
> 
>>> * Mailing lists — Mailing list operators, including ietf.org, have had 
>>> to implement rewriting of From addresses such as [e-mail] 
>>> becomes user=[e-mail] when a p=strict or 
>>> p=quarantine policy is in place. This works to some extent for IETF, but 
>>> there is an enormous number of mailing list operators, each of whom 
>>> would need to implement address rewriting. While address rewriting is 
>>> not the recommended solution, it is widely used because of the 
>>> widespread inappropriate use described above. >>
>> 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?


> 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.


>> ARC provides a protocol whereby a mailing list can certify its behavior to 
>> an end receiver. Unfortunately, we are still missing a protocol whereby 
>> trusting an ARC sealer can be established by a receiver for each mail 
>> stream.  We are halfway across the ford. >
> 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.

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.


Best
Ale
--