From: Jeremy Harris Date: Mon, 25 Jun 2018 11:08:37 +0000 (+0100) Subject: ARC: Fix verification to do AS checks in reverse order X-Git-Tag: exim-4.92-RC1~160 X-Git-Url: https://vcs.fsf.org/?a=commitdiff_plain;h=5054c4fdb5c5949872020d75beb5722eabe3d1d3;p=exim.git ARC: Fix verification to do AS checks in reverse order Broken from the original introduction (617d39327e) --- diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog index db8804904..13d8d8236 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 15df15267..aa93e07bf 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 466c13990..64362e751 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; }