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
