550 Authentication is required for relay - Enable domain's SMTP auth setting for local deliveries
Question asked by CCC - April 5, 2016 at 7:24 AM
Unanswered
Hello,
 
It seems like smartermail is not taking SPF into account within the context of the following SMTPin setting
 
Settings > Protocol Settings > SMTPin > "Enable domain's SMTP auth setting for local deliveries"
 
We are a hosting company and frequently our clients have need to send mail through a 3rd party email service.  We have added the appropriate SPF records to our client's domains - however inevitably when they try to send themselves a test message from a 3rd party mail server, they get a "550 Authentication is required for relay" message.  The FROM address is a local mailbox, the TO address is a local mailbox, and the sending server passes an SPF check.
 
As I understand, this is related (at least in part) to a setting within SmarterMail's SMTPin Settings which reads "Enable domain's SMTP auth setting for local deliveries".  We have that setting enabled, and at each domain we have the "Enable SMTP Authentication" setting enabled as well.  This effectively blocks random spammers from emailing FROM @ourcustomer.com to @ourcustomer.com - however it is also forcing authentication on legitimate 3rd party mail servers that are authorized in the domain's SPF record. 
 
Obviously we don't want to disable SMTP authentication at the domain level, so the only workaround we have found is to add the sending SMTP servers IP address(es) to the SMTP Authentication Bypass whitelist.  Unfortunately that is not really a sustainable workaround. 
 
I am not sure if this behavior changed in smartermail over the last 6 months or so (we are running 14.5.5...), or if our customers are just using 3rd parties for SMTP more often - but in either case I have found myself adding more and more whitelist entries over the last few months. 
 
Senders are usually pretty good about updating their own SPF records, and since we include the senders SPF records in our customer's domain SPF records - we theoretically have a pretty up to date list of IP addresses that should be allowed to send mail through our customers domain and should not need any whitelist entries.
 
If the sender doesn't pass an SPF check for the FROM address, then i'm fine with our server rejecting with a 550 authentication required message, however if the sending IP passed an SPF check - smartermail should not require authentication for delivery to local users.
 
Has anyone else run into this and/or come up with another workaround that does not result in a less secure SMTP configuration?
 
 

23 Replies

Reply to Thread
3
Scarab Replied
I struggle with this every day as well.
 
To prevent relaying or delivery of Spoofed Spam the "Enable domain's SMTP auth setting for local deliveries" setting in SMTP IN and "Require SMTP Authentication" on Domains is necessary. However, doing such means that any email addressed from a domain that is not sent by your Mail Server is going to bounce with the "550 Authentication is Required for Relay" message.
 
In an ideal world we would take the hard-line and tell customers that their web application must simply use SMTP Authentication in order to send email as FROM: an address on their domain. However, it is not an ideal world and sometimes there are outdated web apps that still don't allow for SMTP Authentication, or 3rd Party Providers (such as Quickbooks, MailChimp, Constant Contact, etc.) that insist on sending email using their own Mail services addressed as FROM: the customer's domain.
 
SMTP Bypass is one way of handling the problem (which doesn't always work as intended). Alternately you can disable "Require SMTP Authentication" from that domain. There are potential repercussions of either course of action.
 
I'm not aware of any other solution. I, for two, would also like if SMTP IN did take into account SPF/DMARC before rejecting with a 550 Authentication is Required for Relay, because it is a daily struggle when SmarterMail does not take into account 3rd Party Services & Providers that legitimately address their email's FROM: the customer's account.
0
CCC Replied
I'm going to try updating from 14.5 to 15.0.5932 to see if there are any behavioral changes in the new version.  I don't see anything in the release notes that jumps out at me as addressing this issue but its worth a shot :)
 
0
Jerry Jacobs Replied
I have experienced the same problem, however the smtp bypass authentication doesn't even seem to work.
Example: I have a third party vendor sending un-authenticated mail.  The vendor's listed in SPF and on our server they are whitelisted and in the authentication bypass list.   If noreply@domain.com sends mail to someone@domain.com it bounces with a authentication error.   If I disable "enable domain's smtp auth setting for local deliveries" the error goes away.  I have confirmed the ip address in the sending email and it matches that within the bypass settings.  Seems like this should work even with authentication set for local deliveries.   Any thoughts or suggestions?
1
Bruce Barnes Replied
The "enable SRS" does nore to allow forwarding than to allow sending from 3rd party addresses You may also be experiencing an issue with the number of SPF lookups required with included records. SPF records are limited to 10 lookups. Adding includes sometimes causes the number of lookups tp spiral - tp 30, 30, 40 , or more, and that can cause non-delivery issues related to SPF. We require that all users authenticates with a location account, whether sending from another e-mail address, web form, or shopping cart. This cuts the outbound spam, which used to originate through 3rd party addresses, down to zero, as well.
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Jerry Jacobs Replied
Bruce, Thanks for the followup, never considered the spf lookups so that may be an issue.
Agree with you on the local account authentication requirement, however the third party sender doesn't yet have the option for utilizing credentials. That's disappointing, since they work with financial institutions. I'm still confused why a sending IP address in the authentication bypass group would generate the 550 error when the local delivery auth is enabled. Shouldn't it bypass this?
0
Jerry Jacobs Replied
My SRS is set to server default.....but I'm not quite sure what the default is. Are you suggesting this be enabled?
0
CCC Replied
If it was SPF related, it would be nice if that was logged

(as discussed in the forum thread 2014 - still marked as "under consideration")

http://portal.smartertools.com/community/a696/does-smartermail-strictly-enforce-spf-processing-limits-as-defined-in-rfc-4408.aspx
0
Jerry Jacobs Replied
CCC - Thanks for that link and I completely agree!
0
Bruce Barnes Replied
Here's a link with more information on the maximum number of SPF lookups. http://www.openspf.org/FAQ/Common_mistakes
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
CCC Replied
Still battling with the issue of "Enable domain's SMTP auth setting for local deliveries" not honoring SPF. 
 
I'm maintaining dozens of IP based whitelists at this point to support 3rd party senders like Office 365 and Shopify. 
 
IP based whitelists are not a scalable and maintainable method for solving this problem in this day and age.  This is what SPF was designed for...
 
Has anyone else found a solution?
3
Von-Austin See Replied
Employee Post
CCC, I've generated a ticket off this so we can track it internally. I'll be bringing this to the dev's on Friday. I'll update this thread once we've discussed this further. 
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
CCC Replied
Thanks Von, much appreciated!
0
Von-Austin See Replied
Employee Post
CCC, our developers have added a feature request for specifying a domain and having the whitelist entries dynamically added based on SPF record. They are in agreement that this would benefit a majority of our customers.
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
This is still a bug right? I have clients using shopify and they cant seem to get notifications that come from shopify relay servers when sent to their domain even with SPF record correct. Smartermail just keeps bouncing them with 550 error. Any comments Von?
0
I'm having the exact same issue with Zendesk as the sender. I need this resolved please. What's the word?
0
You happen to find a resolution for this? Seems the thread got quiet and I'm having the same problem... trying to stir the pot a bit. Thanks!
0
echoDreamz Replied
Was anything ever done on this?

Christopher

0
Patrick Ryan Replied
We've had to override SMTP auth safe IP list. Not ideal. I think this thread is in deep sleep.
1
echoDreamz Replied
Was anything ever completed on this?

Christopher

0
Miles Badger Replied
just bumping this thread, awaiting a solution...
0
Emmet McGovern Replied
I'll bump this too. It's only gotten worse in the two years since this was started.  Most of our clients use some sort of SAAS solution that uses their domain now.  The biggest issue we are having is Shopify users not getting their orders. 
0
Adam Lewis Replied
Smartermail seems to have gone silent on this like so many other issues.
0
Webio Replied
Isn't this normal behavior of all email servers? I'm not saying that it shouldn't be handled like it was proposed here but IMHO other mail servers are acting the same when they have local domain configured?
 
I think this should be handled just like it was with external MX servers:
 
 
Next to Inbound Message Delivery should be another dropdown or checkbox which would allow domain configuration to check SPF record during delivery for accepting remote emails for this domain. IMPORTANT thing that this scenariu should be also handled in incoming scenario gateway using web service validation.

Reply to Thread