Insert initial headers like Authentication-Results before the MTA’s Received header#126
Insert initial headers like Authentication-Results before the MTA’s Received header#126glts wants to merge 1 commit into
Conversation
Index 0 inserts before the MTA's Received header. Patch by @fanto666.
Insert trace headers at index 0
Insert trace headers at index 0
|
With this change, with old postfix (2.10) and old libmilter (8.14.7), opendmarc milter cannot get AR headers added by opendkim. However after rebuilding opendkim and opendmarc with libmilter 8.18.1, even appy this PR patch, opendmarc can get AR headers. I guess this is related to the change on sendmail 8.17.2.
|
This was incorrect, even with libmilter bundled in sendmail-8.18.1, our CentOS 7 environment, postfix 2.10, sendmail-milter 8.18.1, opendkim including this change, opendmarc milter after opendkim milter cannot get Authentication-Results: header generated by opendkim milter. (The result in my previous comment was caused by my mistake, when I rebuilt opendkim with newer libmilter, I applyed a patch reverting this change. I'm very sorry.) Other environment, with Postfix 3.9.0, and with sendmail 8.18.1 on FreeBSD, opendmarc can get AR header from preceding opendkim. |
RFC 8601 sections 4 and 7.1 require Authentication-Results to be inserted before the MTA's Received header. SpamAssassin and other verifiers also rely on this ordering to determine which AR headers can be trusted. Change all dkimf_insheader() calls from index 1 to index 0 so that Authentication-Results, DKIM-Signature, VBR-Info, and X-OpenDKIM headers are prepended before existing headers rather than inserted after the first one. Patch originally by @glts (PR #126), credit also to @fanto666. Fixes #24
The proposed change moves the generated
Authentication-Results(et al.) header before the MTA’sReceivedheader. This is achieved by calling the milter library’ssmfi_insheaderfunction with index 0 instead of 1, patch provided by @fanto666. This fixes #24.The
Authentication-Resultsheader is specified in RFC 8601. It is a trace header field and therefore expected to come before theReceivedheader. See the explicit requirements on this in sections 4 and 7.1 of RFC 8601, and also the numerous examples in appendix B:Other software such as SpamAssassin also assumes that trusted
Authentication-Resultsheaders come before the trustedReceivedheader.