2
"550 Relay Not Allowed" for NEW Users When Using Incoming Gateway
Problem reported by Scarab - 1/11/2022 at 12:49 PM
Submitted
We are using SmarterMail Enterprise 100.0.8025.26489 with three Incoming Gateways running SmarterMail Free 100.0.8025.26489 setup with "Domain Forwarding" using "SmarterMail Gateway Mode" with "Web Service User Identification".

Remote deliveries through the Incoming Gateways works as expected for previously EXISTING users. However, after creating a NEW user on v100.0.8025.26489 all external deliveries to that user through the Incoming Gateways bounce with rsp "550 Relay Not Allowed". This is happening on multiple domains.

Local deliveries to these NEW users works fine.

We have reloaded the Domain. Restarted the SmarterMail Service on all servers, and rebooted all servers, yet problem continues to exist for NEW users.

We create new users pretty frequently so this appears to have occurred beginning with v100.0.8025.26489.

This is severe enough of an issue I'm willing to open a Support Ticket if needed.

5 Replies

Reply to Thread
0
Kyle Kerst Replied
Employee Post
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 Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Scarab Replied
@Kyle

That is correct. We are using Web Service Verification on the Incoming Gateways.
1
Kyle Kerst Replied
Employee Post
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 Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Scarab Replied
@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.)
0
Kyle Kerst Replied
Employee Post
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 Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com

Reply to Thread