On Sun 11/Dec/2022 21:43:51 +0100 Douglas Foster wrote:
ARC can prevent a message from being blocked by DMARC policy, but its
usefulness is limited because the mailing list receives no feedback and
munging is never suspended.
There seems to be consensus to specify an unspecified type in aggregate
reports that can be used to report ARC, BIMI, or whatever. This saves the
WG the task to specify how to report ARC. However, it raises the question
of how to determine report recipients.
Current aggregate reports provide for a *reported domain*. ARC provides
for reporting one or more domains' identifiers, signed by a (different) domain.
Outlook.com has a curious implementation of ARC. Their servers apply an
ARC signature to every message, asserting SPF PASS, DKIM PASS, and DMARC
PASS, without regard to whether the message even has a DKIM signature. It
appears to me that they are trying to document and sign the original
identifiers for a message, which actually seems like a desirable thing to
do. Since ARC only captures identifier information as an ancillary
component of a test result, they must assert bogus test results to
accomplish this result.
s/curious/buggy/
ARC should provide a way for any server to document the current state of
identifiers, whether a test is performed or not. Better yet, a server
which knows that it is making identity changes should be able to document
before and after values in a single ARC set.
No test, no state to be reported.
A seal can be applied irrespective of changes. The AAR contents should be
the results obtained on message reception, methinks.
With this change, we have a way to integrate ARC and DMARC with feedback,
in a way that begins solving the mailing list problem.
- The mailing list publishes a DMARC policy and signs outgoing messages
with its domain.
- When an author domain's DMARC policy is a problem, the MLM munges the
FROM address to its domain. This also causes the list domain to receive
aggregate reports on the munged messages.
- If the receiving system trusts the ARC data, it can reliably restore the
From address to its unmunged value, using data from the ARC Set. Then
the unmunged message is delivered to the recipient user. The disposition
data of the aggregate report is used to communicate to the mailing list
that the ARC data was trusted and the From address was unmunged.
Restoring From: presents the same problem that Barry raised in the other
list about removing DKIM signatures. That is, one must beware to act after
any possible transparent forwarding has fired. To cover MUAs doing
transparent forwarding, From: restoring must in turn be reversible.
The other problem is that every list saves the original From: in a
different way, so restoring it is not straightforward.
- If the receiving system does not trust the ARC data, current behavior is
unchanged. The munged message passes DMARC based on the munged address,
and the message is not obstructed by DMARC FAIL.
Trust should be granted by the message recipient, not the receiving system.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
