Essentially all of what I proposed is possible with the current version of ARC.
But to Ale's comment that "No test, no state to be reported", I have to disagree. Assume that all in-transit changes are innocuous, so the critical issue for evaluation is the original identifiers on the message (Server, MailFrom, and From) to determine if the reputation of that source. Incoming gateways do identity testing, but not identity changing. Internal servers and outgoing gateways do identity changing but not identity testing. I want both to be able to report based on their role. DF On Mon, Dec 12, 2022 at 3:24 AM Alessandro Vesely <[email protected]> wrote: > 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
