Why 'authentication is required for relay' for some not others
Question asked by Ray Cook - February 12, 2016 at 7:55 AM
Unanswered
We used to have the flag 'Enable domain's SMTP auth setting for local deliveries' set OFF.
To improve security and anti-spam defenses we set it ON.
 
We have situations as a hosting company whereby we send mail from one of our webservers and relay through the mail server to ensure it has the right headers etc and to avoid vulnerabilities on the webservers. For example, in a WordPress site we have SMTP settings where we set up our mail server FQDN, user name and password for an email account we are going to use to send the mail, for example, for an order acknowledgement and port number. There are various methods depending on the platform but they all require to be authenticated through our mail server. All work fine with the flag ON.

However, we have customers who do not host their sites with us, but only email. We tell them how to configure mail to be relayed through our server.

Since changing the setting to ON for '
Enable domain's SMTP auth setting for local deliveries' two customers are getting 'authentication is required for relay' bounces and the same in the logs. One of these customers uses a CCTV camera system which sends an email with a photo every time somebody walks in the building. They read out to me the settings in the software that does this and it seems perfect. They send an email from cctv@domainname.com to cctv@domainname.com I don't know if that is part of the problem but we have tried scripts that replicate that and it works fine for us.
 
The other customer does exactly as we do: they have an e-commerce site that sends order acknowledgments etc. relayed through our server and, supposedly, authenticated. I say 'supposedly' because this customer uses a 3rd party hosted service and they are very secretive about the settings they use. So I am dangerously assuming that they are configured correctly.

Now, as I have not personally seen either configuration for myself it could be both are misconfigured. But I am wondering if anyone has had a similar situation where this can happen if the flag mentioned is set to 'ON" and there are circumstances other than plain authentication misconfiguration that could cause it?
 

6 Replies

Reply to Thread
0
Does the camera system allow for SMTP authentication?
 
If so, can you change to SMTP PORT to 587?  I ask only because COMCAST, and many other backbone providers now prohibit clients, including CCTV systems, from sending on port 587 - they filter all of the NO-MAIL SERVER SMTP traffic out and block it.
 
Here's a link to their announcement about their implementation of port 25 for clients, see: https://portal.chicagonettech.com/kb/a165/xfinity-comcast-blocks-all-traffic-on-port-25-alternate-port-465-and-port-587.aspx
 
 
 
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
Well they claim to have authentication via user name (email address) and password.
It's our server rejecting it. cctv@example.com is sending to cctv@example.com purportedly using the correct authentication and then getting 'authentication is required for relay' from our server. We allow port 25.
 
We can try 587band see if that does the trick
0
Port 25 may be blocked, for SMTP CLIENTS, between their camera system and you.  Even if you're not blocking, one of the networks between you and them may be blocking it.
 
If you are capable of running TLS over port 587, I would also engage that - so that the data is not transmitted in plain text.
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
With regard to TLS, this is our next big project - but that's for another day. Tx for your help and suggestions. I think I need to see how these are set up at their end otherwise I might just be chasing my own tail.
 
0
This is not a criticism of your security schedule but it should be given the HIGHEST priority!
 
We got a five-year, enterprise, wildcard, 4096 bit, SHA2 certificate, which we can install on as many servers as we want, so long a the domain matches "chicagonettech.com" for about $270.00 last December. from Comodo.  Took less than 12 hours to apply, download, and install, along with the 3 supporting certificates
 
We're seeing tons of "man-in-the-middle" attacks to capture usernames and passwords on non-secured connections.
 
We're now totally locked down, no more plain text anything, and only had a problem with one customer who balked.  He left over the new security, and we picked up 12 more new clients because of our enforcement.
 
It only takes one compromised account to gain access to the data for millions of user accounts;
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
Well, you are right to stress the importance. Our problem is lack of understanding of the implication of making the move and so much other stuff takes precedence as usual in small organisations but I'm working on it, trying to understand how best to make the change.

We have a cert which is already associated with the SM log in, which enforces https. It is already associated with the correct port bindings (I just haven't switched to them yet) and validates OK and we have, of course, your very detailed articles of how to go about implementing for our 1000+ email accounts for 100+ customers. I know this thread has now gone off at a tangent but not that much of a tangent. Apologies in advance for the long reply here.

Problem 1.

We know that many customers have local SMTP mail client settings of mail.theirdomain.com rather than mail.ourdomain.com - we need to trawl through these and get them to change so they can use TLS ports (if my understanding is correct) otherwise they will get a certification domain error.

Problem 2

We can't reasonably expect all our customers' mail users (many of whom are not very skilled at making changes to mail configs) to all switch overnight. This is the crux of our lack of understanding and maybe you can enlighten me. But I am not sure what happens if we suddenly switch all the port bindings to TLS ports - if we still allow Auth login - will it work for everyone regardless of their settings until we gradually work our way through persuading and cajoling them to use SSL/TLS and when we are confident everyone has migrated - we disable Auth login?

It would be nice to have a workflow diagram of how to make the switch - not just technically but logistically, taking into account the above considerations. There may be others. You can understand our trepidation in doing anything which stops mail working for customers because this is the most important thing for them, more important than their websites being up 100% of the time.
 
There is a final complication but I think it will be ok. We have a customer who white labels our mail server so his customers login to SM using mail.hisdomain.com and their SMTP server is the same. The certificate includes that domain so I think it will be valid but I'm not sure which settings such as hostnames need to be set up - not sure about multiple hostnames at all. There may be other settings and it may be that this just will not work at all. That domain is NOT set up in IIS (ours is, however), instead, it is just a DNS A record pointing to the mail server IP. We have no custom branding specifically to avoid his customers seeing our company logo etc. They are oblivious of us - in theory - and that's how he wants it to remain.

So there you have it. I understand completely if you feel I am pushing my luck picking your brains here but I think it's a subject which seems to be poorly explained by ST. I'm prepared to to do midnight testing to answer some of the questions above myself but it would certainly help move things along if you can advise on this and we can move up a notch in security.
 

Reply to Thread