On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely <ves...@tana.it> 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? > >>> 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. > Same question. I can't tell if you're just pontificating about a variety of topics, or making concrete suggestions about what the -bis document really needs to say before this WG ships it. If the former, I suggest this be minimized as they're likely only distractions; if the latter, I'd love to see some proposed text. We should standardize some proposals that make ARC work consistently for > forwarders (including MLs) of any size and kind. > Do you have one to suggest? > > What is it that you believe we should be telling industry to do? > > Experiment with new proposals until we find one that works? > Same question. > >>> 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. > Do you have specific text to suggest? > >> 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. > Have you tried this technique? Has anyone? Does it work? -MSK, p11g
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
