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).

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!

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.

One of my clients was reporting getting a bunch of bounces ( 600 error ) when sending emails.  These were not blasts, these were individual messages.  Logs showed a ton of WARNING: Certificate name mismatch.  Hopefully after disabling that setting this issue goes away, but it does bring to question why so many  mail server don't get their own SSL for their domains?

@Paul - a lot of the certificate errors we see (at least from a support perspective) stem from antispam gateways and the like, which typically leverage self-signed certificates when set up as an appliance because they anticipate communication being done on private channels between the gateway and server, though that isn't how most businesses end up actually using them! Does that align with the examples you've seen so far?

@Kyle - Here is an example of what I am seeing my delivery logs

[2024.07.22] 13:36:16.300 [34517809] WARNING: Certificate name mismatch. Expected Hostname: tamu-relay.tamu.edu, Certificate Information: Subject=CN=*.pphosted.com, O="Proofpoint, Inc.", S=California, C=US Issuer=CN=Sectigo RSA Organization Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB

Those entries all stopped when I disabled that setting.

I agree they should match.  What is strange is my logs are filled with these and for many domains.