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

8 Replies

Reply to Thread

Kyle Kerst Replied

1/11/2022 at 2:01 PM

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

Lead Internal Network/System Administrator

SmarterTools Inc.

smartertools.com

Scarab Replied

1/11/2022 at 2:18 PM

@Kyle

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

Kyle Kerst Replied

1/11/2022 at 2:54 PM

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

Lead Internal Network/System Administrator

SmarterTools Inc.

smartertools.com

Scarab Replied

1/11/2022 at 4:14 PM

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

Kyle Kerst Replied

1/11/2022 at 4:30 PM

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

Lead Internal Network/System Administrator

SmarterTools Inc.

smartertools.com

Webio Replied

11/29/2022 at 3:51 AM

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

Zach Sylvester Replied

11/29/2022 at 7:11 AM

Employee Post

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,

Zach Sylvester

Software Developer
SmarterTools Inc.

www.smartertools.com

Webio Replied

11/29/2022 at 11:52 AM

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.

Back to Community Threads

Reply to Thread

Enter the verification text