Robert:
Thank you very much for the analysis and the configuration.
Robert Lister writes:
As (bad) luck would have it, the very first real message bounced: :-(
This is *very* bad luck. I don't think I've seen messages without Message-ID in decades!
Mail client: X-Mailer: Microsoft Outlook 16.0
So it seems in certain circumstances, Outlook doesn't put a Message-ID: header in its messages.
Outlook is not my favorite MUA (and I don't mean that I don't like using it). Nevertheless, RFC 5321 suggests that the responsibility for dealing with this or rejecting the message is with the submission host:
The following changes to a message being processed MAY be applied when necessary by an originating SMTP server, or one used as the target of SMTP as an initial posting (message submission) protocol:
o Addition of a message-id field when none appears
o Addition of a date, time, or time zone when none appears
o Correction of addresses to proper FQDN format
The less information the server has about the client, the less likely these changes are to be correct and the more caution and conservatism should be applied when considering whether or not to perform fixes and how. These changes MUST NOT be applied by an SMTP server that provides an intermediate relay function.
The context strongly suggests that a similar caution applies to final delivery servers, and I would assume Mediators such as Mailman. I conclude that the post is broken and very good reason would be needed to patch it up.
Therefore, Mailman3 using LMTP means exim will NOT "fix up" this problem before mailman3 receives the message.
As I read the passage you quoted, Exim won't fix up the problem regardless of whether it delivers to Mailman via LMTP or by pipe, etc. The problem is that Mailman's LMTP server rejects malformed mail. I seem to recall that in Mailman 2, Mailman itself would add a Message-ID field if one was not present. I don't know how easy it would be to provide this feature, since we would have to patch the LMTP server code so the message could make it to Mailman proper (Mailman 3 imports the LMTP server from the stdlib).
My solution for now (apart from telling people not to use old broken Outlook!) is to modify the exim mailman3_transport so that any message with a missing Message-ID: will have one generated by exim before it's passed to LMTP. This reproduces the same behaviour exim uses for locally submitted messages.
I'm not sure it's a good idea to do this (and certainly not by default). The only times I've seen messages without a Message-ID are spam messages. I suppose we can add this to the documentation.
Steve