Yes, the evaluator should assess reputation of MailFrom domains. In a multi-tenant environment, a server owner may be well intentioned, but he may have a client domain that is a bad actor, either intentionally or due to infection. But we don't know that every MailFrom domain will be represented by an ARC Set, so we have trouble knowing if all domains are identifiable. It seems we need to trust servers and domains, or we need to have a level of server trust which eliminates the need to worry about each client domain on the server. I don't see how we can limit our scope to only the domains that appear in a subsequent ARC set.
If a Received header has a "for user@domain" clause, and it is different from the one in the ARC sets or the received SMTP transaction, then we can add that domain to the list of domains requiring trust. But this is an insufficient tool for ensuring that all domains are known. The best proxy for server trust is the server organization, which is known with confidence if the HELO Name can be forward confirmed to the host name. When this is available, reputation can be assessed based on the domain name rather than the IP, solving the problem of obtaining prior knowledge of every IP address used by a serer organization. DF On Tue, Sep 20, 2022 at 6:14 AM Alessandro Vesely <[email protected]> wrote: > The point of ARC if whether the evaluator trusts the domain(s) that > produced > the ARC set(s). Actually, as Doug says, all the domains from the last i= > down > to and including one reporting dkim=pass or dmarc=pass must be trusted. > Otherwise the result is dmarc=fail. > > I'd propose dmarc=redeemed as a way to express that the necessary trust > was > granted by the evaluator. > > How an evaluator decides which domains to trust is its internal policy. > It may > be kept secret, narrated in blog posts, whatever. > > When the ARC seal is valid there is no need to examine Received: chains. > > Reputation based on IP addresses is ill-conditioned, as IP addresses > change > rather often. Domain names can also change, but that is a major event in > the > life of the corresponding organization, and it is expected to be relevant > for > its reputation. > > The bulk of the carbon footprint is due to cryptographic verifications. > The > complexity of parsing A-R records can be neglected. > > > Best > Ale > > > On Tue 20/Sep/2022 03:18:15 +0200 Douglas Foster wrote: > > 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
