Mark Sapiro writes:
Rob's reply in this thread was garbled due to <https://gitlab.com/mailman/mailman/issues/616>. The text of the reply is quoted below.
On 7/27/19 12:54 AM, Rob Lister wrote:
One thing that does occur to me is that my exim header fudge will probably cause the Message-ID header to move around from its original position, and if someone is doing hashing or actually validating (gpg signing?) the headers haven't been tampered with, then it might complain, since although the message-id hasn't changed, it might be in a different place in the headers.
I don't think this is a problem. GPG or S/MIME signing with any software I know of only signs the message body (or a MIME part). DKIM message signing isn't going to care about the order of fields because DKIM canonicalizes the order (at least for the unique fields) according to the specification in the signature field, and that will be verified on the way in. Of course adding a Message-ID will likely break DKIM for the outgoing post, but Mailman as normally used breaks DKIM anyway. This can be partly mitigated by using ARC (authenticated received chain), which is supported by Google already, and possibly some of the other usual DMARC suspects (Yahoo!, AOL).
Probably the more correct way to do it is only add a new header if it's missing, and if it's there, leave it alone.
True, and I think this does it:
headers_add = ${if def:h_message-id:{fail}{Message-ID: ... id generator code ...}}
If you like that and test it, I would really appreciate feedback so we can update the documentation.
One thing *I* would like to add to this recipe is logging. I'd be curious to see how frequently it happens outside of spam and junior high school hackers using netcat as their MUA. I don't see how to do this in Exim, though.
Another is using a prefix other than "E" to indicate this isn't standard Exim behavior.
Steve