I am beginning to think about how to use ARC Set data in my custom filters. Below is a recap of my current thinking. I am curious whether anyone else intends to use ARC and what improvements you might suggest to this analysis?
ARC Evaluation
ARC Set evaluation involves these issues:
- Sufficiency: The goal of ARC Set evaluation is to determine whether the message should be accepted or rejected when applying the ARC Set message characteristics to the Evaluator’s filtering rules. If critical identifiers or test results are missing, this analysis is not possible and the ARC Set becomes useless.
- Plausibility: Is the data internally consistent with other message headers? Plausibility tests compare the identifiers in the ARC Set with identifiers available in other message headers. If the ARC Set fails to provide sufficient identifiers, then plausibility tests are not possible and the ARC Set may be considered useless.
- Stability: Can we assume that the DNS state has not changed while the message was in transit between the ARC Set creator and the evaluator? Many of the plausibility checks in this document are dependent on the assumption that relevant DNS content has not changed while the message was in motion.
- Reputation: Delivery of the message implies that the ARC Set creator concluded that the message is acceptable. Do the ARC Set tests indicate that the creator provided a reasonable effort to detect and block bad messages, or does it suggest insufficient filtering effort? Have prior ARC Sets from the same source proved to be useful and reliable?
- Applicability: If the ARC Set is Sufficient and Plausible, how does it affect the Evaluator’s filtering decision?
Sufficiency and Plausibility: SPF
- SPF Results should provide enough identifier information to re-run the tests. If the test cannot be repeated, the SPF data is insufficient.
- The SPF Result’s IP Address must be a global IP.
- When the evaluator re-runs the SPF test using the provided identifiers, the test should produce the same result, unless the ARC Set result was TempError or the Evaluator result is TempError. If the evaluator result is TempError, the evaluator can choose whether to accept the ARC Set result or defer the message and retry the test at a later time.
- The SPF parameters should match to a Received Header based on IP Address, and Helo name. Ideallly, the SPF Receiver name should match to the Received entry’s “by hostname” text. In some cases, the SPF Test’s MailFrom address can be matched to a Received header comment of the form (envelope-from <user@domain>). In cases where a message passes through the same server multiple times, the SPF data may match to multiple Received headers. The ambiguity should be resolvable using the order alignment requirement that is discussed later.
Sufficiency and Plausibility: DKIM
- If the ARC Set reports a DKIM result, the message must contain at least one DKIM signature with the same attributes.
- The evaluator can re-run the DKIM verification test, and compare results to the ARC Set result. The ARC Set result is limited to Pass or Fail, but an Evaluator failure result can be further refined into these categories: PermErrors caused by bad syntax or a missing public key, body hash mismatch failures, and header mismatch failures. If the ARC Set result is Pass, the evaluator results must not be Fail with PermError.
Sufficiency and Plausibility: DMARC
- A DMARC result must identity the From domain used for the test.
- If the DMARC result is Pass, the tested domain must have a DMARC policy.
- The DMARC test result should be reproducible using the replicated SPF results and the asserted DKIM results.
- If the ARC Set result is Fail, a DMARC test on the received From address should not be Pass. A discrepancy of this type may indicate DMARC upgrade by asserting a result about a DKIM signature that an attacker knows will be added later in the message flow.
- If the ARC Set does not provide a DMARC Result, but the evaluator is able to compute one, this suggests that the ARC Set creator has weak filtering practices.
Sufficiency and Plausibility: Header Order
- Received headers are presumed to be handled as trace fields, so that the newest headers are at the top of the document. ARC Sets have explicit order indicated by the “i=” term. After ARC data is matched to Received headers, the two ordering sequences should align.
Sufficiency and Plausibility: Summary
An evaluator should be able to evaluate prior message state against his own policy if he has these identifiers, either from the ARC Set or from Received data linked to the ARC Set:
- Source IP
- Helo host name
- Reverse DNS host name (which can be computed from the Source IP)
- RFC5321.MailFrom address
- RFC5322.From address
If the RFC5322.From address is not in the ARC Set, the evaluator may be willing to use the final From address (assuming that it has not been rewritten). If the ARC chain has multiple sets, the evaluator may be willing to infer a missing From address using data from one of the other sets in the chain.
Reputation
If the ARC Set creator has an unacceptable reputation, or if implausible ARC Set data implies an untrusted sender, the message may be rejected based on the ARC Set data itself.
Note: Microsoft applies an ARC Set, complete with results for SPF, DKIM, and DMARC, to every message for which it serves as outgoing gateway. This is a misuse of the ARC specification, and the authentication test results are often wrong (in both directions) or implausible (DKIM Pass results without a DKIM signature, DMARC Pass results without a DMARC policy.) However, the reported identifiers are accurate. As a result, evaluators may find the identifier information to be useful.
Applicability
Assuming that an ARC Set is accepted as sufficient and plausible, and that the ARC Set creator is not distrusted, the following applications are possible:
- An ARC Set identifier with an unacceptable reputation may be used to reject a message.
- An ARC Set test result of Fail may be used to reject a message
- An ARC Set DKIM test result of Pass may be used to override a final DKIM result of Fail, particularly when the DKIM result determines the DMARC result. Accepting the DKIM Pass result can permit a message to be accepted instead of rejected. This is the common solution to the “Mailing List Problem” with DMARC.