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
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
S: 503 AUTH command used when not advertised | 500 unrecognized command
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?

  • 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. 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

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?


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
  • 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 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
  • 1
    It actually looks like there is a solution in current versions of exim. See the description of allow_auth_unadvertised here.
    – 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." =) Sep 20 '11 at 21:08

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! 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. Nov 19 '19 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.