Jasen Betts via Exim-users <exim-users@exim.org> writes:
> you probably need encryption to use authentication.
True.
>
> openssl s_client -connect smtp.suddenlink.net:25 -starttls=smtp
That gives me what I see the beginning of in
/var/log/exim4/mainlog.
> Use ESMTP "ehlo" instead of "helo":
Thanks. I didn't realize the difference until I began
digging more.
The ehlo screen is a bit more helpful when one sends the
ehlo command
$ telnet smtp.suddenlink.net 587
Trying 208.180.40.68...
Connected to smtp.mx-altice.prod.cloud.synchronoss.net.
Escape character is '^]'.
220 omta04.suddenlink.net ESMTP server (InterMail vM.8.04.03.22.02 201-2389-100-169-20190213) ready Mon, 9 May 2022 06:52:02 -0500
ehlo martin.m
250-omta04.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
I send the starttls command.
starttls
220 Ready to start TLS
There are about 10 seconds between that and:
Connection closed by foreign host. I am not good at doing TLS
calculations in my brain so I am taking it on faith that if I had
spoken TLS, it would have picked right up.
I noticed that one can also call for starttls from port
25 and we get
220 Ready to start TLS
exit
In that respect helo and ehlo behave the same in that one could
starttls from either P25 or P587 so the starttls request could be
sent but 587 is the port mentioned first in the skimpy
documentation I have found.
I also tried
openssl s_client -connect smtp.suddenlink.net:465 -starttls=smtp
That gets you:
Didn't find STARTTLS in server response, trying anyway...
write:errno=32
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
That used to be the port one used until March 13 when we
morphed in to the quagmire that exists now.
The opacity of this process is astounding but tshark has
been helpful here and has made this chew toy give up some secrets
that may point to the solution although this has been 2 months of
I wish + coulda' woulda' shoulda' and very little progress.
If I capture net traffic from and to the system in
question, I see a couple of differences between when swaks
successfully delivers a message and exim almost but not quite
does.
With swaks, the ehlo capture is:
192.168.1.64 ? 208.180.40.68 SMTP 82 C: EHLO localhost
When I send through a normal exim4 delivery, the ehlo
capture looks like:
192.168.1.64 ? 208.180.40.68 SMTP 79 C: EHLO wb5agz
wb5agz is my amateur radio call which is the hostname for
this computer and I bet it should actually read "localhost" as in
the swaks capture.
both are also giving the starttls request at the end of
the suddenlink menu of authentication options.
The trouble appears to start after the TLS key exchange.
With swaks, I see a clear message from smtp.suddenlink
that authentication was successful.
With exim4, things grind and grind with incrypted traffic
going back and forth only to see a clear message:
208.180.40.68 ? 192.168.1.64 TLSv1.2 617 Certificate,
Server Key Exchange, Server Hello Done. That looks good but
then there's more encrypted fog and then:
208.180.40.68 TLSv1.2 192 Client Key Exchange, Change Cipher
Spec, Encrypted Handshake Message
I feel like I am fighting World War III with a dried-out
rubber band and a wad of paper.
The interesting observation I can remember from past
examination of logs, etc, is that I think the ehlo or helo
strings have had the host computer's name in the past when things
were working. It could be that smtp.suddenlink.net tightened
their authentication requirements in an upgrade recently and this
is what changed. Ya' got to love these complex operations that
have but one good outcome and infinite permutations of failures.
It will be two months and counting as of May 14 when the last
normal email was sent.
Hopefully, the next email I send will be through exim4 in
the normal manner.
Martin McCormick
> you probably need encryption to use authentication.
True.
>
> openssl s_client -connect smtp.suddenlink.net:25 -starttls=smtp
That gives me what I see the beginning of in
/var/log/exim4/mainlog.
> Use ESMTP "ehlo" instead of "helo":
Thanks. I didn't realize the difference until I began
digging more.
The ehlo screen is a bit more helpful when one sends the
ehlo command
$ telnet smtp.suddenlink.net 587
Trying 208.180.40.68...
Connected to smtp.mx-altice.prod.cloud.synchronoss.net.
Escape character is '^]'.
220 omta04.suddenlink.net ESMTP server (InterMail vM.8.04.03.22.02 201-2389-100-169-20190213) ready Mon, 9 May 2022 06:52:02 -0500
ehlo martin.m
250-omta04.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
I send the starttls command.
starttls
220 Ready to start TLS
There are about 10 seconds between that and:
Connection closed by foreign host. I am not good at doing TLS
calculations in my brain so I am taking it on faith that if I had
spoken TLS, it would have picked right up.
I noticed that one can also call for starttls from port
25 and we get
220 Ready to start TLS
exit
In that respect helo and ehlo behave the same in that one could
starttls from either P25 or P587 so the starttls request could be
sent but 587 is the port mentioned first in the skimpy
documentation I have found.
I also tried
openssl s_client -connect smtp.suddenlink.net:465 -starttls=smtp
That gets you:
Didn't find STARTTLS in server response, trying anyway...
write:errno=32
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
That used to be the port one used until March 13 when we
morphed in to the quagmire that exists now.
The opacity of this process is astounding but tshark has
been helpful here and has made this chew toy give up some secrets
that may point to the solution although this has been 2 months of
I wish + coulda' woulda' shoulda' and very little progress.
If I capture net traffic from and to the system in
question, I see a couple of differences between when swaks
successfully delivers a message and exim almost but not quite
does.
With swaks, the ehlo capture is:
192.168.1.64 ? 208.180.40.68 SMTP 82 C: EHLO localhost
When I send through a normal exim4 delivery, the ehlo
capture looks like:
192.168.1.64 ? 208.180.40.68 SMTP 79 C: EHLO wb5agz
wb5agz is my amateur radio call which is the hostname for
this computer and I bet it should actually read "localhost" as in
the swaks capture.
both are also giving the starttls request at the end of
the suddenlink menu of authentication options.
The trouble appears to start after the TLS key exchange.
With swaks, I see a clear message from smtp.suddenlink
that authentication was successful.
With exim4, things grind and grind with incrypted traffic
going back and forth only to see a clear message:
208.180.40.68 ? 192.168.1.64 TLSv1.2 617 Certificate,
Server Key Exchange, Server Hello Done. That looks good but
then there's more encrypted fog and then:
208.180.40.68 TLSv1.2 192 Client Key Exchange, Change Cipher
Spec, Encrypted Handshake Message
I feel like I am fighting World War III with a dried-out
rubber band and a wad of paper.
The interesting observation I can remember from past
examination of logs, etc, is that I think the ehlo or helo
strings have had the host computer's name in the past when things
were working. It could be that smtp.suddenlink.net tightened
their authentication requirements in an upgrade recently and this
is what changed. Ya' got to love these complex operations that
have but one good outcome and infinite permutations of failures.
It will be two months and counting as of May 14 when the last
normal email was sent.
Hopefully, the next email I send will be through exim4 in
the normal manner.
Martin McCormick