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?
The
503 AUTH command used when not advertised
essentially explains itself, it didn't offer the client the option to use theAUTH
command. This is most likely because the client usedHELO
rather thanEHLO
(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 onHELO
type connections.** UPDATE **
According to this post here: http://www.exim.org/lurker/message/20040901.063858.126f66ac.en.html
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: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):
Change the fsockopen port argument from 25 to 465.
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.