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

["Murray S. Kucherawy" <[e-mail]>]

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?


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