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

[Tero Kivinen <[e-mail]>]

Alessandro Vesely writes:
> In that sense, ARC may have attempted to address an authorization
> problem using only authentication primitives.

Acually ARC provides the authentication information that can be used
to create authorization in the final recipients email filters.

Lets say ietf liss would add ARC header before the mailing list email
is modified. Your message had DKIM signature, but it of course got
broken by the mailing list. The mail2.ietf.org already checked that as
it added header saying:

Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1152-bit key)
	header.d=tana.it

If it would have added also ARC header saying:

ARC-Authentication-Results: i=1; mail2.ietf.org; dkim=pass ...

then when the email ends at my final filters, I could have configured
that to say that for "List-Id: <*.ietf.org>", I do trust ARC
Authentication results from *.ietf.org, and those results should
be considered while decideding whether to filter the email or pass it
to my mailbox.

Currently I do this by rule that says

* ^List-Id:.*(\.ietf\.org)
* ^Precedence:.*(list|bulk)
$DEFAULT

meaning all IETF lists bypasses my other filters, but having extra
check that would also check the ARC header generated by ietf.org would
make it better (and this test should really check that List-Id is
covered by the DKIM signature generated by ietf.org, but there has not
yet been problems with it, so I haven't done that yet).

> If forwarding semantics actually require explicit authorization
> relationships between participants or mail streams, then that would
> also explain why ARC struggled to produce stable evaluation
> semantics across independent operators.

I think ARC heeader generation is very useful and provides information
to the final recipients filters that really can help them.

On the other hand the actual chain part of the ARC is completely
broken, and the processing rules in section 5.2 of RFC 8617 ARC
Protocol is not useful.

So perhaps we should just make new standard track document for ARC
that only covers the actual header format and generation of, and then
say that it is generated to provide information for the final end user
mailbox filtering system.
-- 
[e-mail]