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
