503 AUTH command used when not advertised

I have a (customer) Linux machine that was working before I "upgraded" the Linux from Mandrake 9 to gentoo 2004.2 last night. (The upgrade basically was to save away /usr/local som /var stuff some /etc stuff and then wipe / /usr /var and install fresh gentoo, put back the saved away stuff and run).

I have to exim config files

exim4.conf and exim4-tls.conf

The exim4-tls.conf file looks like:

utah# more exim4-tls.conf

tls_advertise_hosts = *
tls_certificate = /usr/local/etc/exim_key_cert
tls_privatekey = /usr/local/etc/exim_key_cert

..include /usr/local/etc/exim4.conf
utah#

The exim4.conf runs without tls and it works with normal AUTH stuff. Users can send through it and they authenticate just fine. However, if they try and enable "SSL" on their client, for their smtp connection, then sending fails and a debug run of the exim daemon shows:

7433 LOG: smtp_protocol_error MAIN
7433 SMTP protocol error in "AUTH PLAIN
AGNoYWRAdGVzdC5vYmplY3QuY29tAF9zZWlrbzAw" H=([192.168.99.66])
[67.161.247.57] AUTH command used when not advertised
7433 SMTP>> 503 AUTH command used when not advertised
7433 SMTP>> 421 mail.object.com lost input connection

This was working before the upgrade and works without the TLS/SSL stuff after the upgrade.

It appears the TLS stuff works as we get some SSL stuff in the dbug log

7432 SMTP<< STARTTLS
7432 tls_certificate file /usr/local/etc/exim_key_cert
7432 tls_privatekey file /usr/local/etc/exim_key_cert
7432 Initialized TLS
7432 host in tls_verify_hosts? no (option unset)
7432 host in tls_try_verify_hosts? no (option unset)
7432 SMTP>> 220 TLS go ahead
7432 Calling SSL_accept
7432 SSL_accept was successful

before it does the EHLO/HELO processing and the AUTH stuff.

Any hints or clues on what might be wrong? The exim binary is the same one after the upgrade. exim was not "emerge"d or anything and it works on the non-SSL port

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.

First, check you confs once again for correct advertising.

Second, if an Exim installation serves many broken clients, the patch attached could help. Otherwise, one must patch every client.

Code:

---

=3Dcut
--- src/smtp_in.c.orig Mon May 12 17:39:22 2003
+++ src/smtp_in.c Fri Jun 20 14:54:05 2003
@@ -1776,12 +1776,6 @@
authentication_failed =3D TRUE;
cmd_list[CMD_LIST_AUTH].is_mail_cmd =3D FALSE;
=20
- if (!auth_advertised)
- {
- synprot_error(L_smtp_protocol_error, 503, NULL,
- US"AUTH command used when not advertised");
- break;
- }
if (sender_host_authenticated !=3D NULL)
{
synprot_error(L_smtp_protocol_error, 503, NULL,
@@ -1832,12 +1826,11 @@
}
=20
/* Search for an authentication mechanism which is configured for
use
- as a server and which has been advertised. */
+ as a server */
=20
for (au =3D auths; au !=3D NULL; au =3D au->next)
{
- if (strcmpic(s, au->public_name) =3D=3D 0 && au->server &&
- au->advertised) break;
+ if (strcmpic(s, au->public_name) =3D=3D 0 && au->server) break;
}
=20
if (au =3D=3D NULL)
=3Dcut

---

It advertises it and the client does an EHLO but then the client tries a HELO so something is not working in the conversation or something.

The client works fine when the TLS stuff is not running and it works fine using the same exim conf talking to another server I have with TLS. It is related to my upgrade somehow, even though the exim installation was not touched in the upgrade.


Here is a complete debug run from the server side showing what is going on.

7333 Connection request from 67.161.247.57 port 57814
7333 1 SMTP accept process running
7333 Listening...
4655 sender_fullhost = [67.161.247.57]
4655 sender_rcvhost = [67.161.247.57]
4655 Process 4655 is handling incoming connection from [67.161.247.57]
4655 checking for IP options
4655 no IP options found
4655 host in host_lookup? no (option unset)
4655 set_process_info: 4655 handling incoming connection from
[67.161.247.57]
4655 host in host_reject_connection? no (option unset)
4655 host in sender_unqualified_hosts? no (option unset)
4655 host in recipient_unqualified_hosts? no (option unset)
4655 host in helo_verify_hosts? no (option unset)
4655 host in helo_try_verify_hosts? no (option unset)
4655 host in helo_accept_junk_hosts? no (option unset)
4655 SMTP>> 220 mail.object.com ESMTP Exim 4.22 Wed, 01 Sep 2004
11:50:23 -0600
4655 Process 4655 is ready for new message
4655 smtp_setup_msg entered
4655 SMTP<< EHLO [192.168.99.66]
4655 [192.168.99.66] in helo_lookup_domains? no (end of list)
4655 sender_fullhost = ([192.168.99.66]) [67.161.247.57]
4655 sender_rcvhost = [67.161.247.57] (helo=[192.168.99.66])
4655 set_process_info: 4655 handling incoming connection from
([192.168.99.66]) [67.161.247.57]
4655 host in pipelining_advertise_hosts? yes (matched "*")
4655 host in auth_advertise_hosts? yes (matched "*")
4655 host in tls_advertise_hosts? yes (matched "*")
4655 SMTP>> 250-mail.object.com Hello [192.168.99.66] [67.161.247.57]
4655 250-SIZE 52428800
4655 250-PIPELINING
4655 250-AUTH PLAIN LOGIN
4655 250-STARTTLS
4655 250 HELP
4655 SMTP<< STARTTLS
4655 tls_certificate file /usr/local/etc/exim_key_cert
4655 tls_privatekey file /usr/local/etc/exim_key_cert
4655 Initialized TLS
4655 host in tls_verify_hosts? no (option unset)
4655 host in tls_try_verify_hosts? no (option unset)
4655 SMTP>> 220 TLS go ahead
4655 Calling SSL_accept
4655 SSL_accept was successful
7333 child 4655 ended: status=0xb
7333 0 SMTP accept processes now running
7333 Listening...
7333 Connection request from 67.161.247.57 port 57817
7333 1 SMTP accept process running
7333 Listening...
4656 sender_fullhost = [67.161.247.57]
4656 sender_rcvhost = [67.161.247.57]
4656 Process 4656 is handling incoming connection from [67.161.247.57]
4656 checking for IP options
4656 no IP options found
4656 host in host_lookup? no (option unset)
4656 set_process_info: 4656 handling incoming connection from
[67.161.247.57]
4656 host in host_reject_connection? no (option unset)
4656 host in sender_unqualified_hosts? no (option unset)
4656 host in recipient_unqualified_hosts? no (option unset)
4656 host in helo_verify_hosts? no (option unset)
4656 host in helo_try_verify_hosts? no (option unset)
4656 host in helo_accept_junk_hosts? no (option unset)
4656 SMTP>> 220 mail.object.com ESMTP Exim 4.22 Wed, 01 Sep 2004
11:50:25 -0600
4656 Process 4656 is ready for new message
4656 smtp_setup_msg entered
4656 SMTP<< HELO [192.168.99.66]
4656 [192.168.99.66] in helo_lookup_domains? no (end of list)
4656 sender_fullhost = ([192.168.99.66]) [67.161.247.57]
4656 sender_rcvhost = [67.161.247.57] (helo=[192.168.99.66])
4656 set_process_info: 4656 handling incoming connection from
([192.168.99.66]) [67.161.247.57]
4656 SMTP>> 250 mail.object.com Hello [192.168.99.66] [67.161.247.57]
4656 SMTP<< AUTH PLAIN XXXXXXX-REDACTED-XXXXXXXX
4656 LOG: smtp_protocol_error MAIN
4656 SMTP protocol error in "AUTH PLAIN XXXXXXX-REDACTED-XXXXXXXX"
H=([192.168.99.66]) [67.161.247.57] AUTH command used when not
advertised
4656 SMTP>> 503 AUTH command used when not advertised
4656 SMTP>> 421 mail.object.com lost input connection
4656 LOG: smtp_connection MAIN
4656 SMTP connection from ([192.168.99.66]) [67.161.247.57] lost
4656 search_tidyup called
7333 child 4656 ended: status=0x100
7333 0 SMTP accept processes now running
7333 Listening...

A successfull STARTTLS resets the session as if it were a new connection (which it is, in a sense). The EHLO and response from that preceded the STARTTLS negotiation are not applicable any more. After successfull negotiation, the server returns a new welcome banner and the client sends a fresh HELO/EHLO.

Your client is choosing to send HELO instead of EHLO. That is not in exim's control.

| The client works fine when the TLS stuff is not running

Because it sends EHLO before STARTTLS.

I can state that it worked with the 4.22 before I switched from Mandrake to gentoo. The exim is exactly the same. I tarr'ed it up and put it back (all in /usr/local) so the exim binary and conf files were the same (and keys and certs). This has been working for months before I did this upgrade and no user complained that it didn't work (as it was working). The clients involved are OS X Mail.app (OS X10.3.5 version) and a version of Mulberry for Windows. These are the two main users of the system and both are having the same problem. I need to test better to see if I can see some more info or something to clue me in.