Back to Community Threads
2
Outbound email delivery issues after updating to version 8250/8251 (message-id header modification)
Problem reported by Software Operations - 9/8/2022 at 5:46 AM
Submitted
Hi team

Recording our experience, in case others are in the same situation, or SmarterTools can resolve.  
As well as SmarterMail use for regular email clients, we also use SmarterMail as an outbound SMTP proxy for a number of various different applications. Some of these applications DKIM sign at source, some don’t.

We updated to 8251 in August. Near immediately we started receiving reports of outbound emails from a selection of various systems being suddenly treated as spam by numerous end recipients.

From the release notes, we suspected the issue to be related to the new feature of SmarterMail modifying headers with the new message-id header (formatted as some-unique-identifier@com), whether the format of the message-id header is affecting downstream delivery or breaking a DKIM hash needs more investigation, or it could be some other unrelated change in the new version.

We did not have time to investigate further – wanting to urgently resolve mail delivery – we rolled back to 8223, and mail delivery and integrity was immediately restored. So we do not have full details of the why, just the clear observation that installing the new version impacted delivery for a number of types of mail and rolling back resolved it.

So a caution for those installing 8250, 8251, and beyond, for those with internal applications using SmarterMail as a proxy, that delivery may be affected by the new modification of headers, and to watch out for any changes in delivery in case you meet the same experience.

For the dev team, perhaps this header modification might need more testing across a number of different use cases: could be that by improving delivery to gmail it has detrimentally affected delivery to other targets?

Hope this helps!

1 Reply

Reply to Thread
0
Douglas Foster Replied
9/8/2022 at 6:38 PM
You really need to get your hands on some sample messages to solve the problem.   Hopefully you can collect this from one of the recipients that was not blocked.   Once you have examples, here are some possibilities to investigate:

Are the Signatures Missing Completely?
There was a bug which has been reported frequently in this post, where DKIM credentials are lost and as a result messages have no signature.   The solution is to recreate the DKIM keys for each domain, which of course is frustrating in direct proportion to the number of domains under your control.  We have been assured that this is a one-time problem, and that has been my experience.   When I first configured SM to apply signatures, the administrator chose the DKIM scope identifier.   In more recent releases, SM chooses the scope identifier.   I think the bug is related to this transition.   Build 8223 and 8251 seem close enough that I would think you would have encountered this problem already, or that it had been fixed so it will not happen to anyone anymore.

Are the Signatures Unverifiable?
DKIM applies to the headers that are specified in the signature's header list.   If the originating system does not supply a message-id, but includes message-id in the header field list, then the signature will be invalidated if SM adds a message-id header.   

If SM adds the message-id header and adds a signature (for the same domain), then any non-verifiable signature should be be ignored and the verified signature should be accepted (if the recipient implementation is complaint, which seems likely.) 

If SM applies a Message-ID header and adds a signature, it might not be including the added field in the signature calculation, which would be a bug.

If your source system supplies the message-id, then SM should not be adding anything and no signature problems should be expected.  SM seemed to think that this was the norm, and this most recent patch was to handle the exceptions.

You should be able to evade message-id problems by ensuring that message-id is not in the header list of your signatures.

Finally, missing signatures should only be a problem if your domain is publishing DMARC with p=reject.   You  could consider changing to p=none before your next test.
Back to Community Threads

Reply to Thread

Related Knowledge Base Articles

Deploying Rspamd For Use With SmarterMailSmarterMail > Server Configuration and Management
Find a Compromised AccountSmarterMail > Troubleshooting
Messages to Yahoo! Emails are Temporarily DeferredSmarterMail > Troubleshooting
Cannot Send Email MessagesSmarterMail > Troubleshooting
Recommended SPAM SettingsSmarterMail > Antispam and Antivirus