Add ARC signing caveats
authorPhil Pennock <pdp@exim.org>
Mon, 26 Mar 2018 16:24:48 +0000 (12:24 -0400)
committerPhil Pennock <pdp@exim.org>
Mon, 26 Mar 2018 16:24:48 +0000 (12:24 -0400)
doc/doc-txt/experimental-spec.txt

index 1a0ece574072eef7d9fa0cedd5c0cda105656e5d..4be142e6675e9fb3100f111f4c9bfa85e56bd57f 100644 (file)
@@ -806,6 +806,20 @@ 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.
 
 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.
 
+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.
+ * 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.
+
 
 
 --------------------------------------------------------------
 
 
 --------------------------------------------------------------