Mails to Gmail - message-id header is missing
SMTP email proxy and relay server
Brought to you by:
graeme_walker
Menu
▾
▴
#80 Mails to Gmail - message-id header is missing
Hello, we are new to using E-Mailrelay on Windows Server 2022, since the IIS SMTP is no longer supported.
It works without problems, but e-mails to Googlemail / Gmail aren't accepted by Google, because of a missing message-id header.
We have many other projects where mail is sent to Googlemail via IIS SMTP without any problem.
But the new projects / servers with E-Mailrelay have this problem.
How can we force the E-Mailrelay to add the message-id?
*******@gmail.com: host gmail-smtp-in.l.google.com[173.194.79.27]
said: 550-5.7.1 [212.124.36.26] Messages missing a valid messageId header
are not 550 5.7.1 accepted.
Best regards
Stefan
You can add content headers with a --filter script.
The "Message-ID:" header should be added by whatever originally submitted the message to the email network, typically an email user agent. There should be only one, so your filter script would have to check for an existing one before adding its own. The message id value is normally as described on page 25 of RFC-2822.
The error message from Gmail was misleading.
They refused the message because of the combination of wrong SPF entry and missing Message-ID.
After setting the correct SPF entry, the missing Message ID is obsolete, and the message arrives in Gmail.
Can you give me an example how the filter script regarding the Message-ID should look like?
The example script emailrelay-set-from.js would be a good starting point: replace the three regular expressions with one for the message-id and then write a message-id line just before the 'break' in the first while loop if there was no match.
As attached, completely untested.
IMHO there is so many thing relaying on the Message-ID so that it should be required by the ER too. Or at least added. The JS filter won't work on Linux and slow but that may be few lines in C++.
As a temp solution that great.
Yes, you have made the case for having more built-in filters and this might be a particularly good candidate because there is no configuration required -- only the domain name is needed and that's already available.
I have added a built-in "msgid:" filter as a last-minute addition to the v2.5 release.