[exim-cvs] ARC: Fix verification to do AS checks in reverse …

Gitweb: https://git.exim.org/exim.git/commitdiff/5054c4fdb5c5949872020d75beb5722eabe3d1d3

Commit:     5054c4fdb5c5949872020d75beb5722eabe3d1d3
Parent:     c645dd29e7f9fcb7e3d2fd9f20aa47084ba0221e
Author:     Jeremy Harris <jgh146exb@???>
AuthorDate: Mon Jun 25 12:08:37 2018 +0100
Committer:  Jeremy Harris <jgh146exb@???>
CommitDate: Mon Jun 25 12:36:01 2018 +0100

    ARC: Fix verification to do AS checks in reverse order

    Broken from the original introduction (617d39327e)
---
 doc/doc-txt/ChangeLog             | 2 ++
 doc/doc-txt/experimental-spec.txt | 8 +++++++-
 src/src/arc.c                     | 9 +++------
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog
index db88049..13d8d82 100644
--- a/doc/doc-txt/ChangeLog
+++ b/doc/doc-txt/ChangeLog
@@ -73,6 +73,8 @@ JH/15 Rework TLS client-side context management.  Stop using a global, and
       connections to service-daemons (eg. malware scanning) while a client smtp
       connection is using TLS; with cutthrough connections this is quite likely.

+JH/16 Fix ARC verification to do AS checks in reverse order.
+

Exim version 4.91
-----------------
diff --git a/doc/doc-txt/experimental-spec.txt b/doc/doc-txt/experimental-spec.txt
index 15df152..aa93e07 100644
--- a/doc/doc-txt/experimental-spec.txt
+++ b/doc/doc-txt/experimental-spec.txt
@@ -819,7 +819,7 @@ An option on the smtp transport, which constructs and prepends to the message
an ARC set of headers. The textually-first Authentication-Results: header
is used as a basis (you must have added one on entry to the ADMD).
Expanded as a whole; if unset, empty or forced-failure then no signing is done.
-If it is set, all three elements must be non-empty.
+If it is set, all of the first three elements must be non-empty.

 The fourth element is optional, and if present consists of a comma-separated list
 of options.  The options implemented are
@@ -838,12 +838,18 @@ Caveats:
  * There must be an Authentication-Results header, presumably added by an ACL
    while receiving the message, for the same ADMD, for arc_sign to succeed.
    This requires careful coordination between inbound and outbound logic.
+
+   Only one A-R header is taken account of.  This is a limitation versus
+   the ARC spec (which says that all A-R headers from within the ADMD must
+   be used).
+
  * If passing a message to another system, such as a mailing-list manager
    (MLM), between receipt and sending, be wary of manipulations to headers made
    by the MLM.
    + For instance, Mailman with REMOVE_DKIM_HEADERS==3 might improve
      deliverability in a pre-ARC world, but that option also renames the
      Authentication-Results header, which breaks signing.
+
  * Even if you use multiple DKIM keys for different domains, the ARC concept
    should try to stick to one ADMD, so pick a primary domain and use that for
    AR headers and outbound signing.
diff --git a/src/src/arc.c b/src/src/arc.c
index 466c139..64362e7 100644
--- a/src/src/arc.c
+++ b/src/src/arc.c
@@ -984,16 +984,13 @@ return NULL;
 static const uschar *
 arc_verify_seals(arc_ctx * ctx)
 {
-arc_set * as = ctx->arcset_chain;
+arc_set * as = ctx->arcset_chain_last;

if (!as)
return US"none";

-while (as)
- {
- if (arc_seal_verify(ctx, as)) return US"fail";
- as = as->next;
- }
+for ( ; as; as = as->prev) if (arc_seal_verify(ctx, as)) return US"fail";
+
DEBUG(D_acl) debug_printf("ARC: AS vfy overall pass\n");
return NULL;
}