On Mon, Jun 16, 2025 at 05:35:47PM -0500, Martin McCormick via Exim-users wrote:
> -> AUTH LOGIN
> <- 334 VXNlcm5hbWU6
> -> bWFydGluLm1Ac3VkZGVubGluay5uZXQ=
> <- 334 UGFzc3dvcmQ6
> -> V2VsY29tZTE=
$ ( echo VXNlcm5hbWU6 | openssl base64 -d
echo UGFzc3dvcmQ6 | openssl base64 -d
echo bWFydGluLm1Ac3VkZGVubGluay5uZXQ= | openssl base64 -d
echo V2VsY29tZTE= | openssl base64 -d )
Username:
[email protected]
Password:
Welcome1
If those are your actual username and password, you should change these
promptly, and avoid in the future posting the base64 encoded chatter
parts of SASL AUTH interactions.
> I wouldn't be posting this message if things were going
> smoothly in exim4 so this is what happens when I try to send
> anything through that same smaarthost. For prudence sake, the
> destination address is protected as destination.net:
(As before, trim or replace with placeholder text the details of
the SASL login:
> SMTP<< 220 altprdrgo002.altice.prod.cloud.openwave.ai ESMTP Service ready
> SMTP>> EHLO wb5agz
FWIW, the EHLO name used by swaks at least looked like an FQDN:
EHLO wb5agz.lan
Exim is sending an unqualified name. Typically tolerated for submission
via an MSA, but an MTA should have a "real" EHLO FQDN name set.
> SMTP<< 250-altprdrgo002.altice.prod.cloud.openwave.ai
> 250-DSN
> 250-8BITMIME
> 250-AUTH=LOGIN
> 250-AUTH LOGIN PLAIN
I am slightly surprised Exim ended up going with LOGIN rather than the
much simpler PLAIN, perhaps this choice was made by some underlying
library, ...
> SMTP>> STARTTLS
> SMTP<< 220 begin TLS negotiation
> SMTP(close)>>
> cmdlog: '220:EHLO:250-:STARTTLS:220'
> LOG: MAIN
> TLS session: (certificate verification failed): certificate invalid:
> delivering unencrypted to H=smtp.altice.prod.cloud.openwave.ai
> [66.179.105.209] (not in hosts_require_tls)
[ Switching to non-TLS is unlikely to succeed with many submission
servers, because often SASL is only available over TLS (to protect
the password and perhaps the content of sensitive messages). Your
TLS settings for this "route" (destination) should have TLS required. ]
The authentication failure is reproducible also in, e.g., Postfix:
$ posttls-finger -lsecure -F /etc/pki/tls/cert.pem
"[smtp.altice.prod.cloud.openwave.ai]:587"
posttls-finger: Connected to
smtp.altice.prod.cloud.openwave.ai[66.179.105.209]:587
posttls-finger: < 220 altprdrgo005.altice.prod.cloud.openwave.ai ESMTP
Service ready
posttls-finger: > EHLO chardros.imrryr.org
posttls-finger: < 250-altprdrgo005.altice.prod.cloud.openwave.ai
posttls-finger: < 250-DSN
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-AUTH=LOGIN
posttls-finger: < 250-AUTH LOGIN PLAIN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-DELIVERBY 300
posttls-finger: < 250 SIZE 104857600
posttls-finger: > STARTTLS
posttls-finger: < 220 begin TLS negotiation
posttls-finger: server certificate verification failed for
smtp.altice.prod.cloud.openwave.ai[66.179.105.209]:587: num=62:hostname mismatch
posttls-finger: smtp.altice.prod.cloud.openwave.ai[66.179.105.209]:587:
subject_CN=imap.suddenlink.net, issuer=Sectigo RSA Organization Validation
Secure Server CA, cert
fingerprint=90:EA:CA:AB:A8:94:EF:93:BB:26:77:37:3D:15:41:B8:59:65:C2:EA:71:3E:11:1D:72:BE:78:3A:39:3A:EF:22,
pkey
fingerprint=A3:C6:77:95:74:22:F0:99:FE:6C:E7:A5:68:AE:66:AE:B5:CF:66:C2:03:03:E0:3E:32:FF:18:D6:3E:36:4B:00
posttls-finger: Untrusted TLS connection established to
smtp.altice.prod.cloud.openwave.ai[66.179.105.209]:587: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
posttls-finger: > EHLO chardros.imrryr.org
posttls-finger: < 250-altprdrgo005.altice.prod.cloud.openwave.ai
posttls-finger: < 250-DSN
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-AUTH=LOGIN
posttls-finger: < 250-AUTH LOGIN PLAIN
posttls-finger: < 250-DELIVERBY 300
posttls-finger: < 250 SIZE 104857600
posttls-finger: > QUIT
posttls-finger: < 221 altprdrgo005.altice.prod.cloud.openwave.ai QUIT
Looking more closely at the certificate, the DNS subject alt names are
as below, and you should configure one of these as the MSA name (in
particular one of the two "smtp" names):
imap.suddenlink.net
imap.suddenlinkmail.com
mail.suddenlinkmail.com
pop.suddenlink.net
pop.suddenlinkmail.com
smtp.suddenlink.net
smtp.suddenlinkmail.com
However, there's another problem, the server's certificate is expired:
Not After : Apr 15 23:59:59 2025 GMT
So the provider has some work to do...
Cert details:
$ posttls-finger -cC -lsecure -F /etc/pki/tls/cert.pem
"[smtp.altice.prod.cloud.openwave.ai]:587" |
openssl x509 -text -certopt
no_header,no_serial,no_version,no_sigdump,no_pubkey
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited,
CN=Sectigo RSA Organization Validation Secure Server CA
Validity
Not Before: Apr 15 00:00:00 2024 GMT
Not After : Apr 15 23:59:59 2025 GMT
Subject: C=US, ST=New York, O=Altice USA, Inc.,
CN=imap.suddenlink.net
X509v3 extensions:
X509v3 Authority Key Identifier:
17:D9:D6:25:27:67:F9:31:C2:49:43:D9:30:36:44:8C:6C:A9:4F:EB
X509v3 Subject Key Identifier:
15:4D:1A:6F:E0:A4:F3:8F:2F:2E:16:86:38:3B:30:B0:EE:74:20:D8
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
...
X509v3 Subject Alternative Name:
DNS:imap.suddenlink.net, DNS:imap.suddenlinkmail.com,
DNS:mail.suddenlinkmail.com, DNS:pop.suddenlink.net,
DNS:pop.suddenlinkmail.com, DNS:smtp.suddenlink.net, DNS:smtp.suddenlinkmail.com
-----BEGIN CERTIFICATE-----
MIIHYzCCBkugAwIBAgIQDXs0C5j4fw7POFBmUicAJzANBgkqhkiG9w0BAQsFADCB
lTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT0wOwYDVQQD
EzRTZWN0aWdvIFJTQSBPcmdhbml6YXRpb24gVmFsaWRhdGlvbiBTZWN1cmUgU2Vy
dmVyIENBMB4XDTI0MDQxNTAwMDAwMFoXDTI1MDQxNTIzNTk1OVowWTELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMRkwFwYDVQQKExBBbHRpY2UgVVNBLCBJ
bmMuMRwwGgYDVQQDExNpbWFwLnN1ZGRlbmxpbmsubmV0MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAyYkdf2x0R3waz+0wkZ83wdr5GiTLE1pfjQl4/NFm
VhT9ErTpQyEhafrnKi0kTxuCn/J8Qyc1vnTj9RLt+CWWcmeCXvn7HhIeKWgUnSSj
mdEj2aaQ4QiMD1amE8gGT0/MhY7RdSuiNP5TKdxj6/fgEAr5MElTeQ7zd1ajXKau
uDXjzwhtdVEYX8pHWqepeqS9wAgRK2dI8sPqqLIFdndQdlMwBC+sj8GdY5niQOFj
lPGCjgT5VjpuUaPbu37puuHunEd72eXYP6MQ1NeKf66j32xehkCdj1na1TLUBBsR
f8FFh/3IDWJLYbOcfmlGKXojXVO17guWrG6iaAcbmMANmQIDAQABo4ID6DCCA+Qw
HwYDVR0jBBgwFoAUF9nWJSdn+THCSUPZMDZEjGypT+swHQYDVR0OBBYEFBVNGm/g
pPOPLy4Whjg7MLDudCDYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBKBgNVHSAEQzBBMDUGDCsGAQQB
sjEBAgEDBDAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAI
BgZngQwBAgIwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNv
bS9TZWN0aWdvUlNBT3JnYW5pemF0aW9uVmFsaWRhdGlvblNlY3VyZVNlcnZlckNB
LmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNl
Y3RpZ28uY29tL1NlY3RpZ29SU0FPcmdhbml6YXRpb25WYWxpZGF0aW9uU2VjdXJl
U2VydmVyQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNv
bTCCAX8GCisGAQQB1nkCBAIEggFvBIIBawFpAHcAzxFW7tUufK/zh1vZaS6b6Rpx
Z0qwF+ysAdJbd87MOwgAAAGO4zMjuAAABAMASDBGAiEA+EqxxdnDjkmIf0TvSLNl
WoLsLsSvJb65XSzqKz0uNxcCIQCHLr8Pq6QQ82HVP7x4eBm0WW9K3DgMMPreLdCE
MEjIYAB3AKLjCuRF772tm3447Udnd1PXgluElNcrXhssxLlQpEfnAAABjuMzI08A
AAQDAEgwRgIhAN2XpvWSZ5jG8su7CgTn+oskSJWX5GntwknKWU5y0FrTAiEA9GB8
BypWsDEAiyaXqEcr2PCOOaxyqp/cb8k47iIMNVwAdQBOdaMnXJoQwzhbbNTfP1Lr
HfDgjhuNacCx+mSxYpo53wAAAY7jMyNPAAAEAwBGMEQCIHasslWSQSeDu7/lOup4
clGhlWq/EG3jkSUv6YjGA10PAiApOi5i5AP736wGgR5cPCd6vdIPi9Zz9mgEFtNS
rz+FlDCBrAYDVR0RBIGkMIGhghNpbWFwLnN1ZGRlbmxpbmsubmV0ghdpbWFwLnN1
ZGRlbmxpbmttYWlsLmNvbYIXbWFpbC5zdWRkZW5saW5rbWFpbC5jb22CEnBvcC5z
dWRkZW5saW5rLm5ldIIWcG9wLnN1ZGRlbmxpbmttYWlsLmNvbYITc210cC5zdWRk
ZW5saW5rLm5ldIIXc210cC5zdWRkZW5saW5rbWFpbC5jb20wDQYJKoZIhvcNAQEL
BQADggEBAAnzyX2v7Og7DlWqYk3YfEzTfRese+VOJnNjR/+9hqhf8foPRt87xCiI
pkJ84irXFFVB1S11wHBj3QICZ/OGR4JrGo6RaOcJ/aYPFkEoOfKKQBRx0M6EPrgR
pqj4QLo4oCOhYDAZxVH4UcdHlf7Und2qrvJwvo57YVRgzMxTxucmnLmB+xRErzk/
yfSUOLYFm9H/WXF0tYlIli+KEn5T/ylTdz03sbicAdglkgc/oB7BHa+BiS6Wtq7G
eh7FjXJNlh6dR1aaPiigoWCmGlUfVKoxbDwKNapLXOTXAN6IPFCQlacoOI3IyGRl
MmkxhL/RttJN8YlldVCjL9lhRido8Oc=
-----END CERTIFICATE-----
> It appears that exim4 is wanting to verify the
> certificate of smtp.altice. The full output of this slow death
> involves repeated attempts by exim to establish a tls session and
> then yet another certificate invalid squawk.
That's actually sensible for an MSA, you shouldn't want to share your
login details with an MiTM attacker.
> Before June 4, that server was successfully letting me
> use STARTTLS just like the swaks session demonstrates so exim4
> should never have had any problem.
The expired certificate is of course invalid since ~April 15th, but
perhaps something else changed around June 4th on the server side or
on your end.
--
Viktor.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
