Hello Scarab! I'm going to set up a test environment for this now and will post back when I have results. Are you using web service verification?

@Kyle

That is correct. We are using Web Service Verification on the Incoming Gateways.

Thank you. In my initial tests I was not able to reproduce but I have a couple of other ideas. In the meantime, using SMTP User Verification should work around this issue as it will simulate or proxy the SMTP session to the primary SM server rather than checking caches. 

@Kyle,

Can confirm that SMTP User Verification does eliminate the delivery problem for newly created accounts. 

As we have too many domains to manage using this work-around method I'll just setup a separate Gateway with Domain Forwarding and SMTP User Verification for those domains with the most users and leave all of the smaller domains that don't frequently have new users stay on the existing Web Service Verification for now.

The caching possibility is an interesting one as we've seen the 28800 second TTL on caching stop deliveries from the Incoming Gateways to the primary when we upgrade SM on the primary and don't restart the SM service on the Gateways but some of these new accounts we've added are 3-5 days old, which is far longer than 28800 seconds.

(BTW, to eliminate that it might be HTTP/3, ALTSVC, QUIC that might be causing the issue I did try setting up an Incoming Gateway to an IP & Domain that specifically has all of those disabled so it is just using HTTP/1.1 & TLS1.2 but the same problem persisted with "550 Relay Not Allowed" for new users.)

Thanks Scarab, this is all good information for my testing. I do believe the problem is stemming from the caching process in our gateway verification, so SMTP User Verification is likely the workaround development will suggest for the time being, as it was meant to replace the web service methods at one point in time. That said, I'll work on getting this replicated and discussed with development and I'll let you know when I know more. Have a good one!

@Kyle - does this has been resolved?

Main SmarterMail server and incoming gateway - both build 8251.

Mail account created on 9:24 AM. Mail rejected two minutes later:

2022.11.29 09:26:48.356 [REMOTEIPADDRESS][55962268] cmd: RCPT TO:<NEW@EMAIL.ACCOUNT>
2022.11.29 09:26:48.356 [REMOTEIPADDRESS][55962268] rsp: 550 <NEW@EMAIL.ACCOUNT> Relay is not allowed

I've started to look what has caused it, Spam checks empty for this connection and I ended up in this thread and I remember that I was experiencing some time in past the same issue.

I'm almost sure that enabling "SMTP User Verification" was causing some problems and thats why I don't have this enabled on incoming gateways.

Hey Guys, 

Did you whitelist your incoming gateway on the main SmarterMail server? To do this go to Settings->Secuirty->Whitelist create a new entry make sure that SMTP Auth Bypass is checked.

Please let me know if this helps. 

Kind Regards, 

Yes. Auth bypass is not a problem. This is specific scenario where incoming gateway is being used where emails to just created domain users are being bounced with "Relay is not allowed". I have 3 incoming gateways with volume in working days at about 280k level and all other traffic is being passed from incoming gateways to main server without any problems.

I just checked user which had "Relay is not allowed" today at 9:26AM and the same connection was made at 12:09 and 12:10 and both messages had been delivered correctly.

So again:

New domain with new (obviously) user created at 9:24AM, external connection to incoming gateway at 9:26AM caused "Relay is not allowed" error but message from the same external SMTP server at 12:09 and 12:10 didn't generated this error. No changes has been made to configuration.