[dmarc-ietf] Re: I-D Action: draft-ietf-dmarc-arc-to-historic-00.txt

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

I've looked back over the last month or so of this thread, and I can't
understand what assertion is being made about how Trent's draft is
deficient.

Perhaps Alessandro or Tero could propose text to add or update to satisfy
what they think is missing or incorrect?

-MSK

On Thu, Jun 4, 2026 at 9:46 AM Alessandro Vesely <[e-mail]> wrote:

> On Tue 02/Jun/2026 15:27:28 +0200 Tero Kivinen wrote:
> > Alessandro Vesely writes:
> >>> Actually ARC provides the authentication information that can be used
> >>> to create authorization in the final recipients email filters.
> >>
> >> The authorization data that can be derived from authentication cannot
> >> cover indirect mail flows.
> >
> > I think I disagree on that. I myself do trust iki.fi because I know
> > the other adminstrators of that service. I know iki.fi will be doing
> > its best to correctly generate ARC-Authentication-Results headers, and
> > I know I can trust them as much as I can trust my local mail service
> > providers Authentication-Results. This trust only applies directly to
> > me, and that authentication information from iki.fi will be derived to
> > authorization information by me when I say that trust those headers.
>
>
> This boils down to the definitions of authentication and authorization.
> Authentication can confirm that the message passed through iki.fi.
> Authorization (and any trust decisions derived from it) are then applied
> according to policies that existed beforehand.  In other words, successful
> authentication does not establish authorization; it merely provides the
> identity information needed to evaluate it.
>
>
> > [...]
> >
> >> In addition, this is only one side of the authorization
> >> relationship: ietf.org has no way to know which recipients are willing
> >> to accept list-modified messages despite a resulting DMARC failure, and
> >> therefore must still munge From: header fields for some domains.
> >
> > Ietf.org does not have to do that, and I think it is bad idea that it
> > does. This mungling was caused because people started complaining about
> > DMARC, and the correct solution should have been to implement ARC in
> > ietf.org mailing lists and users who subscribe the ietf.org mailing
> > list should just configure to trust ARC-Authentication-Results of the
> > ietf.org for ietf mailing lists.
>
>
> It's that "should just configure".  Until the list has some way to know
> whether
> a recipient has configured trust for the list's ARC assertions, it cannot
> rely
> on that trust being present and therefore cannot generally avoid From:
> munging.
>   Without a mechanism to communicate or confirm the recipient's
> authorization
> policy, the mailing-list problem remains unsolved.
>
>
> This is independent of the authentication technology used.  Whether the
> signal
> comes from SPF, DKIM, ARC, a hypothetical DKIM2, PGP, or S/MIME,
> authentication
> alone provides no information about which authenticated identities the
> recipient is willing to authorize.
>
>
> > Or ietf.org should reject all subscription requests where there is
> > dmarc p=reject...
>
>
> This was considered too.
>
>
> > Ietf decided to do bit more user friendly thing and decided that
> > mangling headers is causing least problems for people...
>
>
> It is the simplest non-cooperative option, numbered 1.3 in
> https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail
>
> (Note that /Authorization approaches/ on that page somewhat blurs the
> distinction, w.r.t. the two-sided nature of authorization we are
> discussing.)
>
>
> Best
> Ale
> --
>
>
>
>