Unauthenticated users able to send local email

Question asked by Tina Cline - 12/15/2014 at 12:17 PM

Answered

Came across an issue while testing some features for ourselves in Azure where we can send an email through our SM server without authentication to local SmarterMail users only. So using it to send to an external email address such as GMail does fail, but I can still get the email delivered to any domain on my SM server. Although without authentication, the emails do fails most SPAM checks, but mostly RDNS failures which still let the emails through.

I do not like this little loophole as it appears that spammers could use our server to send SPAM at least to our own users. Any ideas how to lock this down?

We do want an unauthenticated users to be able to use our mail server period (unless they are in the SMTP Bypass list).

I see a few options in the SM Settings for Protocol Settings that lists "Enable domains SMTP auth setting for local deliveries" (unchecked)

Would this solve our issue and I do not want to make this change if it will void our SMTP Bypass list?

8 Replies

Reply to Thread

Bruce Barnes Replied

12/15/2014 at 12:22 PM

Looks like you may have ALLOW RELAY set improperly. The only secure setting for ALLOW RELAY is NOBODY.

You will also need to set ALLOW RELAY for AUTHENTICATED USERS and make certain that REQUIRE SMTP AUTHENTICATION is checked for all hosted domains. That can be found in DOMAIN ===> EDIT ===> TECHNICAL:

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

Tina Cline Replied

12/15/2014 at 12:27 PM

We do have the Allow Relay set to "Nobody" and the domain(s) do have "Require SMTP Authentication" on each one. The only piece missing is the checkmark for "Enable domains SMTP auth setting for local deliveries" I assume if I turn this on it will fix our issue, but want to make sure it does not hurt our SMTP Authentication Bypass list.

Tina Cline Replied

12/15/2014 at 12:34 PM

I checked the "Enable domains SMTP auth setting for local deliveries" and I am still able to relay to local domains. Do I need to restart the SM service for this change to take effect?

Bruce Barnes Replied

12/15/2014 at 1:03 PM

Sounds like you have something whitelisted which should not be whitelisted.

I am not a fan of whitelisting at all and we prohibit whitelisting for all hosted domains. Everything send must be SMTP authenticated. It's way too easy to start by passing SMTP authentication when you start whitelisting and a pain to troubleshoot.

Tina Cline Replied

12/15/2014 at 2:25 PM

Here is some deeper info:

The External IP it is coming from is not in the whitelist or ByPass SMTP as it is a brand new Azure IP.

The logs we see for SMTP shows that the email fails authentication yet it still sends to any domain in our local server. If you try to send outside the server (gmail) then it fails since it can not find a "local" user for gmail.

We used a fake email address "blahblah@relayme.com" and the below log shows that it sent the email to an internal domain.

If it was on the whitelist/bypass, then would it not then let me send to GMail? This is basically telling me that if you use the server to relay, even with a bad password, you can still send to internal domains, just not external.

[2014.12.15] 16:18:24 [191.238.34.22][39077737] connected at 12/15/2014 4:18:24 PM
[2014.12.15] 16:18:24 [191.238.34.22][39077737] cmd: EHLO EMAT-WEB1
[2014.12.15] 16:18:24 [191.238.34.22][39077737] rsp: 250 MySMxServer.com Hello [191.238.34.22]250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-STARTTLS250 OK
[2014.12.15] 16:18:24 [191.238.34.22][39077737] cmd: STARTTLS
[2014.12.15] 16:18:24 [191.238.34.22][39077737] rsp: 220 Start TLS negotiation
[2014.12.15] 16:18:24 [191.238.34.22][39077737] cmd: EHLO EMAT-WEB1
[2014.12.15] 16:18:24 [191.238.34.22][39077737] rsp: 250-My SM Server Hello [191.238.34.22]250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250 OK
[2014.12.15] 16:18:24 [191.238.34.22][39077737] cmd: AUTH login QmxhaEJsYWhAcmVsYXltZS5jb20=
[2014.12.15] 16:18:24 [191.238.34.22][39077737] Authenticating as BlahBlah@relayme.com
[2014.12.15] 16:18:24 [191.238.34.22][39077737] rsp: 334 UGFzc3dvcmQ6
[2014.12.15] 16:18:24 [191.238.34.22][39077737] rsp: 535 Authentication failed
[2014.12.15] 16:18:24 [191.238.34.22][39077737] cmd: MAIL FROM:<BlahBlah@relayme.com>
[2014.12.15] 16:18:24 [191.238.34.22][39077737] rsp: 250 OK <blahblah@relayme.com> Sender ok
[2014.12.15] 16:18:24 [191.238.34.22][39077737] cmd: RCPT TO:<MyEMailXX@gmail.com>
[2014.12.15] 16:18:24 [191.238.34.22][39077737] rsp: 550 <MyEmailXX@gmail.com> No such user here
[2014.12.15] 16:18:24 [191.238.34.22][39077737] cmd: RCPT TO:<Wmail@OnMyServer.com>
[2014.12.15] 16:18:24 [191.238.34.22][39077737] rsp: 250 OK <Email@OnMyServer.com> Recipient ok
[2014.12.15] 16:18:24 [191.238.34.22][39077737] cmd: DATA
[2014.12.15] 16:18:29 [191.238.34.22][39077737] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2014.12.15] 16:18:29 [191.238.34.22][39077737] rsp: 250 OK
[2014.12.15] 16:18:29 [191.238.34.22][39077737] Data transfer succeeded, writing mail to 317437282817.eml

My settings you posted in the picture above are exactly the same and we have restarted the SM service to be sure.

Joe Wolf Replied

12/16/2014 at 4:37 PM

The only problem I see in your example is that the sender attempted to SMTP authenticate and it failed. I'm not sure what the RFC on this that issue, but if you exclude that your server did exactly what it's supposed to do. The rest of the transaction is the same as it would be from any other SMTP server. It accepted the message to a local recipient and refused to relay for a non-local recipient. That's how SMTP works. Your message does bring up an interesting scenario. I think it would be a good idea for SmarterMail to drop the connection once it issues a "535 Authentication Failed", but there may be an RFC that defines behavior on this issue. If so I don't know about it. Again, with the exception of the failed authentication your server did exactly what it's supposed to do. -Joe

Thanks, -Joe

Tina Cline Replied

12/17/2014 at 4:40 PM

Thanks Joe - That does make sense and I was not thinking about it that way. I was just panicking and not thinking it all through. I was assuming that a authentication fail should stop the SMTP connection, but duh, how else I am going to receive emails...

Tina Cline Replied

12/17/2014 at 4:40 PM

Marked As Answer

"The only problem I see in your example is that the sender attempted to SMTP authenticate and it failed. I'm not sure what the RFC on this that issue, but if you exclude that your server did exactly what it's supposed to do. The rest of the transaction is the same as it would be from any other SMTP server. It accepted the message to a local recipient and refused to relay for a non-local recipient. That's how SMTP works. Your message does bring up an interesting scenario. I think it would be a good idea for SmarterMail to drop the connection once it issues a "535 Authentication Failed", but there may be an RFC that defines behavior on this issue. If so I don't know about it. Again, with the exception of the failed authentication your server did exactly what it's supposed to do. -Joe"

Back to Community Threads

Please leave this box unchecked

8 Replies

Reply to Thread

Tags

Related Knowledge Base Articles