2

I'm running a piece of software on a Windows server that sends email notifications via a remote SMTP server. It has very few configuration options, and only supports basic SMTP authentication without SSL/TLS. I have exim4 running on a Debian server that will be the SMTP server for this Windows program. It is set up with default configuration, plus allowing AUTH PLAIN and AUTH LOGIN unencrypted connections. I have successfully sent an email over telnet:

telnet servername 25
ehlo test
250-AUTH PLAIN LOGIN
...
auth plain XXX
235 Authentication succeeded
mail from: ...
...

However, the program I want to connect to this server fails to connect. To see why, I ran a packet sniffer during the connection, and see the following session:

C: HELO hostname
S: 250 Hello hostname
C: AUTH LOGIN XXX | XXX
S: 503 AUTH command used when not advertised | 500 unrecognized command
C: QUIT
S: 221 closing connection

I'm not familiar enough with the SMTP protocol to understand what's going on here. What do I need to change on my exim4 SMTP server to allow for this connection to be made?

jrdioko
  • 567
  • 5
  • 9
  • 18
  • This bypasses your question, but you could also set exim to allow relaying from the ip address of your windows server. This may be required if you can't get your application to do ehlo as Coding Gorilla mentions. – becomingwisest Sep 20 '11 at 19:13
  • @Christopher: Thanks, that seems like an easier way to approach it. Although I believe this machine is on a dynamic IP... – jrdioko Sep 20 '11 at 19:25
  • Bad idea to set `allow_auth_unadvertised` on exim. The protocol explicitly requires advertising, and your client program is broken, period. This feature should never have got into exim. One server I'm responsible for doesn't advertise AUTH (it has alternative authentication) but occasionally gets attacked for days on end by automated clients who AUTH anyway, then just guess names/passwords. I've 'fixed' this by terminating clients who send unwanted AUTHs. IMO, unwanted AUTHs are a good indication that the client is a hacker. – EML Feb 09 '22 at 19:00

2 Answers2

11

The 503 AUTH command used when not advertised essentially explains itself, it didn't offer the client the option to use the AUTH command. This is most likely because the client used HELO rather than EHLO (which I would note you used when you did your telnet test).

SMTP Authentication is part of Extended SMTP, which is initiated with the EHLO command; "plain old" SMTP did not support authentication and so it is technically an illegal command, even though some SMTP servers may still allow it.

Best possible solution is to tell your program to use Extended SMTP (EHLO) if possible, otherwise there might be an exim command to force it to allow AUTH on HELO type connections.

** UPDATE **

According to this post here: http://www.exim.org/lurker/message/20040901.063858.126f66ac.en.html

EHLO (not HELO) must be given by client before AUTH.

That is, AUTH command could not be used unless advertised (through EHLO, according to auth_advertise, etc). This behavior was hardened in Exim 4.20 and is not an option.

Looks like you need a differnt MTA if your can't get your application to do EHLO. Or, do you require authentication, can you accomplish the same thing using IP based ACL's?

FINAL SOLUTION

Exim does have a work around for this, using allow_auth_unadvertised as described here, you can do something like this:

hosts   = *
control = allow_auth_unadvertised
Coding Gorilla
  • 1,938
  • 12
  • 10
  • Strange, sounds like it's breaking the protocol then. I'd be interested to hear if anyone has more information on advertising AUTH on a `HELO` connection. – jrdioko Sep 20 '11 at 19:24
  • @jrdioko Updated with additional info on Exim – Coding Gorilla Sep 20 '11 at 19:28
  • Thanks for the clarification. As mentioned in a comment above the client is on a dynamic IP so ACL's won't work. My only other thought that I read somewhere is to make exim reject `HELO` commands to try to force the client to send `EHLO` instead. – jrdioko Sep 20 '11 at 19:33
  • What about basing the ACL on the `HELO` host name? I'm guessing your application won't send the `EHLO` (although definitely try), it's probably a poorly written SMTP implementation, which I often find in older software. – Coding Gorilla Sep 20 '11 at 19:36
  • Ah, didn't realize that was possible, that sounds like it could work, I'll look into it. – jrdioko Sep 20 '11 at 19:37
  • It's not the best solution, since if someone figured it out, it's obviously very easy to spoof; but if you don't mind the risk it should get you by. – Coding Gorilla Sep 20 '11 at 19:40
  • True, but that's a risk of unencrypted authentication in general. – jrdioko Sep 20 '11 at 20:45
  • 1
    It actually looks like there is a solution in current versions of exim. See the description of `allow_auth_unadvertised` [here](http://www.exim.org/exim-html-current/doc/html/spec_html/ch40.html#SECTcontrols). – jrdioko Sep 20 '11 at 21:06
  • 2
    Ok, that's good to know! I like this comment in that link, which seems to sum up your situation: "Furthermore, because there are apparently some really broken clients that do this, Exim will accept AUTH after HELO (rather than EHLO) when this control is set." =) – Coding Gorilla Sep 20 '11 at 21:08
  • That worked like a charm. Could you post a quick update to your answer, for people that don't read through all these comments? – jrdioko Sep 20 '11 at 22:01
  • The link is not showing anything it's supposedly showing. – Giszmo Aug 01 '17 at 12:32
1

I had a similar problem. This message can occur even if EHLO is used, when the server is running Exim.

In WHM > Home > Service Configuration > Exim Configuration Manager, the option "Require clients to connect with SSL or issue the STARTTLS command before they are allowed to authenticate with the server" was set to the default (On). I'm not sure if I did this or not, and it is ordinarily a great idea for security, but forces the mailserver to enable (advertise) only the STARTTLS command, not AUTH. So when my script sends AUTH, the error message the server sends is correct. Further information is at http://blog.networkpresence.co/?p=8923 . Someday when I have time I will find out how to change my script to use TLS, so I can turn that Exim option On for security.

ADDED 11/19/19:

I have found how to change my local "send email" script to use TLS, and I have changed my server back to requiring either TLS or STARTTLS.

Why did I do this?

Because several websites I use require secure mailservers when sending email notifications. I had a devil of a time figuring out why they kept complaining about my email address: it was because my mailserver accepted insecure connections!

Thinking about it further, I realized that all Web operations should be secure (this is the basic idea behind the Let's Encrypt project, which was the first to provide free security certificates that renew automatically).

Two changes need to be made to a PHP "send email" application that uses the fsockopen function to change it from an insecure to a secure connection with the mailserver (this will eliminate the 503 error message the right way):

  1. Change the fsockopen port argument from 25 to 465.

  2. Change the fsockopen host argument scheme from (empty) to ssl:// . So, if the host was "mail.example.com", change it to "ssl://mail.example.com".

It may also be necessary to enable the line "LoadModule ssl_module modules/mod_ssl.so" in the httpd.conf file (for local Apache servers) or make some other local change to make PHP internet transports work. I'm not sure about this. Just these two changes worked for me right away.

  • It works like a charm! – Marco Demaio Nov 19 '19 at 11:12
  • Yes, making a mailserver accept insecure connections works like a charm, but it will allow lots more access by malicious users and increases the chances of getting your mailserver compromised. I've edited my answer to favor using secure connections. I apologize for my ignorance in advocating insecure access, but detailed mailserver security is not a well-documented topic and I was just trying to help in the only way I could at the time. – David Spector Nov 19 '19 at 21:19