The whole point of RFC 7960 is that a DMARC FAIL is an ambiguous result. I suggest that either our document or its successor needs to address the problem of false FAIL results, or we have not addressed the concerns raised by RFC 7960. Since I don't think there is any appetite to write a second BCP document, I am hoping to see it addressed in our current document. ARC has been identified as at least one part of the solution to the RFC 7960 problem, so we should be able to state the structure necessary to create an ARC-derived override for DMARC FAIL.
The value judgement is assumed: We assume that the evaluator wants to apply the override if the message is truly from a desired source, as indicated by the RFC5321.MailFrom or the RFC5322.From addresses. An evaluator could perform ARC evaluation on every message, but the processing burden is expensive, so I assume that a preferred-source status is necessary before the effort begins. With or without initial filtering, the technical problem is to define a rule set which imputes trust for qualifying messages without imputing trust to non-qualifying messages, and this is the heart of my question. An ARC set can demonstrate that a message had an initial state of DMARC PASS, and it tells us the domain that applied that judgement, but it does not tell us which domain or server modified the message, and it does not tell us that the message was only modified once. Consequently, we cannot escape the need to evaluate trust for every server after the one that created the ARC set which documents DMARC PASS. This requires evaluating the Received chain forward, but first we need to find a starting point for that process. The domain name in the ARC A/R does not tell us a server name or IP address, but the Received-SPF element may provide us with an IP address. The Received-SPF address will be the server which submitted the message to the ARC-applying organization. By finding that Received header, the forward walk can begin so that all subsequent servers can receive reputation assessment. Some of those Received servers will be internal systems with private IP and non-verifiable host names, so the reputation assessment process needs to allow for those problems as well. My worry is that this algorithm is complex to develop, resource intensive to apply, vulnerable to inconsistencies in the formatting of both Received headers and ARC A/R records, and may need a sophisticated repository of server reputation data. These difficulties may be inconsequential to a few of the biggest players, but what about everyone else? Doug As t my points: On Mon, Sep 19, 2022 at 2:48 PM Ken O'Driscoll <[email protected]> wrote: > Do you trust the ARC signer is the only appropriate policy test. > Everything else, including your "wanted and valued sender" test is a value > judgement for a message filter, not an ARC evaluation. If you trust the ARC > signer of a message, then you trust their assertion as to the > authentication status of the message at the point they signed it. > > Ken. > > On Mon 19 Sep 2022, 18:31 Douglas Foster, < > [email protected]> wrote: > >> I am trying to specify the generic form of a local policy rule to trust >> ARC to override DMARC FAIL. >> This is my current draft: >> >> - The message's RFC532.From address indicates a wanted and valued sender. >> >> - The message produces DMARC FAIL. >> >> - The ARC chain is intact >> >> - An ARC-A/R entry exists and indicates DMARC PASS, aligned SPF PASS, or >> aligned DKIM PASS. If more than one such ARC set is found, the highest >> sequence number is used. >> >> - The IP address used for SPF is extractable from the comment field of >> that same ARC A/R record. >> >> - A Received header can be found with the same Source IP address, and >> >> - The rest of the Received chain is scanned forward, and all included >> servers are trusted to create only accurate message headers and to make >> only non-malicious changes to the message. Given the unpredictability >> >> Can anyone simplify this formula? >> >> Doug Foster >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
