Incoming Gateways Unable to Deliver (Build 8832)

Problem reported by Scarab - 3/8/2024 at 11:32 AM

Resolved

Running SM Free Edition on three Incoming Gateways to a primary SM Enterprise Edition. After upgrading the Incoming Gateways to Build 8832 email stopped being delivered to the primary server. Looking in the logs I have tons of these errors:

WARNING: Certificate name mismatch. Expected Hostname: 207.55.232.8, Certificate Information: Subject=CN=smartermail.scarabmedia.com Issuer=CN=R3, O=Let's Encrypt, C=US

Since the SETTINGS > GATEWAYS only allow you to define an IP Address instead of a Host Name SmarterMail expects the CN (Certificate Name) to match the IP Address (and certificates cannot be issued for IP Addresses).

The workaround is to go to SETTINGS > PROTOCOLS > SMTP OUT and disable "ENFORCE STRICT CERTIFICATE VALIDATION". The errors will still be thrown in the detailed logs, but email will at least now be delivered.

Seems to me that either the SETTINGS > GATEWAY needs to be changed to allow FQDN Host Names instead of IP Address or the Strict Certificate Validation routine needs to not assume Hostname ahead of the TLS handshake and actually be comparing Hostname given in the HELO/EHLO with the Certificate Name.

4 Replies

Reply to Thread

Scarab Replied

3/8/2024 at 12:10 PM

It would also appear that on Build 8832 the SETTINGS > GATEWAY > SMTP USER VERIFICATION for any Gateways setup with Domain Forward is also not working as intended. As of this version it is attempting to verify local users on the gateway from the RCPT TO: instead of verifying the remote user on the primary. This is resulting in all inbound email getting rejected for "rsp: 550 Relay Is Not Allowed". (SMTP User Verification was working properly as recently as Build 8768)

The work-around for resolving this is disabling SMTP User Verification and enabling "Enable SmarterMail Gateway Mode" (which had been previously disabled due to other issues in prior versions where SmarterTools suggested that this feature is deprecated and should no longer be used).

kevind Replied

3/8/2024 at 1:01 PM

Scarab, we ran into this same issue with messages not being delivered from the gateway! This occurred after installing the Feb. 29th Build and we immediately did a rollback to get things working again.

Nice detective work! Thanks for posting the all the details and for finding possible work-arounds!

Scarab Replied

3/13/2024 at 8:44 AM

I may have spoken too soon. The workarounds above did not seem to work on Build 8838 entirely. About half of our inbound email is bouncing for "550 Relay is not allowed"...but Enable SmarterMail Gateway Mode is at least allowing about half the emails through just fine. My Incoming Gateways are also getting blocked due to IDS Harvesting and IDS Denial of Service which they never triggered in previous builds.

Looks like I'm going to have to roll-back to a previous Build as well.

Scarab Replied

3/21/2024 at 3:51 PM

Marked As Resolution

Turns out the "550 Relay is not allowed" had little to do with either SMTP User Verification or SmarterMail Gateway Mode. It had to do with multiple left-over/orphaned cached files in the \SmarterMail\Service\Settings\SmartHostCaches\ folder that dated all the way back to 2019. After stopping the service, deleting these cache files, and restarting the SM service, everything started working properly again.

IMPORTANT NOTE: The "ENFORCE STRICT CERTIFICATE VALIDATION" still had to be disabled on the Incoming Gateways otherwise they wouldn't be able to connect to the primary as certificates cannot have an IP Address as a CN. This will probably remain this way until they change the Incoming Gateways to be set to use a FQDN instead of IP Address.

Back to Community Threads

Please leave this box unchecked

4 Replies

Reply to Thread

Tags

Related Knowledge Base Articles