Subject: smarthost Outsmarting me so Far
You are reading this message because I hacked together a one-of
setup to post this message.
This system is running
Exim version 4.92 #5 built 01-May-2021 09:42:39 and was doing
just fine until March 14 of this year when my ISP, suddenlink.net
changed something on smtp.suddenlink.net which killed the
configuration I had been using for 7 years.
The smtp.suddenlink.net server used and, appears
to still be using TLS encryption for the login credentials and
this is good but something changed in the sequence of
events that constitutes a successful login since the login has
failed 100% of the time since March 14.
When it used to work, one established the session on TCP port
465 so the session was encrypted from the start. Encryption
continued until the session end so the transaction was quite
secure.
After the change, it appears that the waye the
server wants to start the session is on the traditional email
port of 25.
I've actually been able to use the swaks utility to send
a message through smtp.suddenlink.net using TLS after the initial
helo routine which is how the message you are reading got sent.
This totally bypasses what exim4 is doing and successfully starts
the message on it's way but that's a total Jake-leg way to do
things so I would like to be able to just send the message
normally, of course.
After the helo on port 25, swaks enables starttls and the
rest is obscured so only the bad guys really know what happened
and when but it does work.
The folks in far-off call centers at Suddenlink state
that it works fine with Outlook. I'm sure it does and they never
heard of exim so it's a dialog of the deaf as far as useful
details that might help script the authentication such that it
works again via exim.
Here is a wireshark trace of the successful sending of a
test message via swaks. The fact that it is successful proves
that there is nothing wrong with any of the login credentials
such as user ID and password. The Cname record resolves
smtp.suddenlink.net.
smtp.suddenlink.net CNAME smtp.mx-altice.prod.cloud.synchronoss.net
A 208.180.40.68 90 26.529173517 192.168.1.1 â 192.168.1.64 DNS
212 Standard query response 0xcaa2 smtp.suddenlink.net CNAME
smtp.mx-altice.prod.cloud.synchronoss.net SOA ns-124.awsdns-15.com
Now here it all starts on P25.
192.168.1.64 â 208.180.40.68 TCP 74 50518 â 25
SMTP 247 S: 250-omta02.suddenlink.net | 250-HELP | 250-XREMOTEQUEUE |
250-ETRN | 250-AUTH=LOGIN PLAIN | 250-AUTH LOGIN PLAIN | 250-PIPELINING
| 250-DSN | 250-8BITMIME | 250-SIZE 52428800 | 250 STARTTLS 117
33.774814356 192.168.1.64 â 208.180.40.68 SMTP 78 C: AUTH LOGIN 118
The next appears to be encrypted traffic and then it's
all in the clear again.
208.180.40.68 â 192.168.1.64 SMTP 97 S: 235 Authentication successful
126 33.845629021 192.168.1.64 â 208.180.40.68 SMTP 103 C: MAIL
FROM: 127 33.865203950 208.180.40.68 â
One can read the message sent and responses from
smtp.suddenlink.net which were picked up by wireshark so only the
authentication is encrypted unless I am misreading the capture.
I can't change how it is done but exim needs to duplicate
this behavior in order to send messages out through it again.
I telnetted in to smtp.suddenlink.net on Port 25 and
tried to glean some ideas from what's there but this little gem
from one attempt says it all:
$ telnet smtp.suddenlink.net 25
Trying 208.180.40.68...
Connected to smtp.mx-altice.prod.cloud.synchronoss.net.
Escape character is '^]'.
220 omta03.suddenlink.net ESMTP server (InterMail vM.8.04.03.22.02
201-2389-100-169-20190213) ready Thu, 5 May 2022 07:48:47 -0500
helo martim.n
250 omta03.suddenlink.net
help login
214 No help information for 'LOGI'
help
214-This SMTP server is a part of the Email Mx E-mail system. For
214-information about Email Mx, please see http://www.owmessaging.com
I did just that, preparing to be enlightened to blinding
brilliance but the documentation appeared to be in some foreign
language I did not recognize much less know. The no-help continues:
214-
214- Supported commands:
214-
214- EHLO HELO MAIL RCPT DATA
214- VRFY RSET NOOP QUIT
help help
214-Usage: HELP [command]
214-
214-Without an argument, the HELP command lists all of the supported
214-SMTP commands. If a command is specified, then help about that
214 specific command is given (but you figured it out yourself :-)
Yup. I was roaring with laughter by this time. As a
smarthost, it's more like a smart-a--ed host but that's unkind, I
know.
What's needed is a modular approach to these things so
programs like exim can continue to do well and those of us who
appreciate all the hard work to create them can monitor and
script logins similar to what we do with expect and