I'm of the opinion this goes back to Todd Herr's topic on the ARC ML
(Topic: Simplifying the Decision to Trust an ARC Header Set) as to
whether a validator trusts a sealer's results to be "true and correct".
With the method this is currently handled in adding of false DKIM
results, how can a mail operator be expected to trust the assertion of
the ARC set, if bogus information is inserted? I certainly would want
accurate results if I was to start relying on theirs to decide whether
or not to override failed DMARC dispositions.
On 12/11/2022 2:43 PM, 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.
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.
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.
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.
- 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.
Doug
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
