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?
 
 

8 Replies

Reply to Thread
3
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
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
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
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
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
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
1
Was anything ever completed on this?

Christopher

Reply to Thread