feature request: add support for generating RFC-2822 Message-ID header

[tmancill]

msmtp is a great utility - thank you for maintaining it. This is a request to add support to generate a Message-ID header field as per RFC-2822 if one isn't already present in the message being sent. This field is required by many email providers to avoid a reject and would be a convenient feature for those of us who sometimes pipe messages straight into msmtp.

There a lot of ways to generate a Message-ID, and I don't have strong opinions on how it the feature should be implemented. Perhaps something like concatenating an epoch-millis timestamp with the account field would work for a simple, zero-conf option.

If you aren't interesting in implementing this, would you consider a PR? This was requested in Debian bug #945024, so there are at least two of us who would use the feature, but I suspect many others would find it useful.

[marlam]

Originally the purpose of msmtp was to submit mail to a server that takes care of everything else - including adding a Message-ID header if necessary.
I can see why today it might be a good idea for msmtp to generate such a header. There should be a new configuration command set_msgid_header (on|off|auto), but it might default to auto which would mean to generate the header if it is not present.
Regarding the content of this header, it's unfortunate that the @right-hand-side part is required since there is no meaningful way for msmtp to find a usable host name or domain to use (that's far easier on the server side!), and even if there were, some people would not want that information to appear in that header.
I'm currently leaning towards using a 128 bit pseudo random number in hex format for both left side and right side. That's valid syntax, does not reveal any private information, and collisions are extremely unlikely.

[marlam]

I must correct myself, the pseudo random number idea was stupid.
Instead, the right hand side should use /etc/machine-id (or gethostid() as a fallback) plus some fixed information fed through a hash function. Then the same machine will generate the same right hand side, but there will be no recoverable private information.
The left hand sight should use the time (including nanoseconds via clock_gettime()) and the pid. This should already be unique per machine since msmtp only handles one mail for each invocation, but one could add a few extra bytes from /dev/urandom to make collisions extremely unlikely. This information can go through a hash function too.
So that would give a fixed per-machine right hand side and a random-looking left hand side, both without recoverable information.

[marlam]

OK I went ahead and implemented this. This change should appear in this mirror repository soon, alternatively you can get it from the main repository.
The Message-ID does not use any pseudo random numbers because the only ones that would be useful in this context are those provided by /dev/urandom, and those should be used sparingly. It also does not use /etc/machine-id because that is not portable and requires file i/o.
Instead, the envelope from address provides the second half of the ID. It is not confidential anyway and already has the right format. The first half is generated from unique information: the system is identified via boot time and host name, and the mail via system time and pid. This information is then hashed so that it cannot be recovered.

[tmancill]

Thank you @marlam !