It is no longer possible until I fix this problem to send
outgoing mail to the smarthost that our ISP provides for this
purpose.
I have been able to use swaks to test the updated
smarthost and am using it now to send this message so my
apologies for the Test subject line but it beats nothing.
esmtp appears to work fine with this server but when I use exim4,
the transaction blows up exactly the same way no matter what I
do. The provider changed something on June 4 so here are logs.
The first 1 is using swaks and you see it smoothly handle the
message:
1wb5agz martin tmp $ swaks
Trying smtp.altice.prod.cloud.openwave.ai:587...
=== Connected to smtp.altice.prod.cloud.openwave.ai.
<- 220 altprdrgo004.altice.prod.cloud.openwave.ai ESMTP Service ready
-> EHLO wb5agz.lan
<- 250-altprdrgo004.altice.prod.cloud.openwave.ai
<- 250-DSN
<- 250-8BITMIME
<- 250-AUTH=LOGIN
<- 250-AUTH LOGIN PLAIN
<- 250-STARTTLS
<- 250-DELIVERBY 300
<- 250 SIZE 104857600
-> AUTH LOGIN
<- 334 VXNlcm5hbWU6
-> bWFydGluLm1Ac3VkZGVubGluay5uZXQ=
<- 334 UGFzc3dvcmQ6
-> V2VsY29tZTE=
<- 235 LOGIN authentication successful
-> MAIL FROM:<[email protected]>
<- 250 MAIL FROM:<[email protected]> OK
-> RCPT TO:<[email protected]>
<- 250 RCPT TO:<[email protected]> OK
-> DATA
<- 354 Start mail input; end with <CRLF>.<CRLF>
-> Date: Mon, 16 Jun 2025 11:41:39 -0500
-> To: [email protected]
-> From: [email protected]
-> Subject: test Mon, 16 Jun 2025 11:41:39 -0500
-> Message-Id: <[email protected]>
-> X-Mailer: swaks v20201014.0 jetmore.org/john/code/swaks/
->
->
->
-> .
<- 250 <684C7115009ED78C> Mail accepted
-> QUIT
<- 221 altprdrgo004.altice.prod.cloud.openwave.ai QUIT
=== Connection closed with remote host.
As far as I know, swaks does not try to verify of the
smarthost's certificates but, as you can see, the whole process
went without a hitch.
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:
2wb5agz martin tmp $ delivering 1uRCBl-000BhD-39
R: smarthost for destination.net
T: remote_smtp_smarthost for destination.net
Transport port=25 replaced by host-specific port=587
Connecting to smtp.altice.prod.cloud.openwave.ai [66.179.105.209]:587 ... TFO
mode sendto, no data: EINPROGRESS
connected
SMTP<< 220 altprdrgo002.altice.prod.cloud.openwave.ai ESMTP Service ready
SMTP>> EHLO wb5agz
SMTP<< 250-altprdrgo002.altice.prod.cloud.openwave.ai
250-DSN
250-8BITMIME
250-AUTH=LOGIN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY 300
250 SIZE 104857600
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)
That's where all four wheels come off and we hit the wall in
a ball of fire.
Nothing I have tried to do to exim's configuration
changes anything. It is as if the situation is set in concrete.
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.
This loops several times until finally, the smarthost
appears to have enough and quits. I don't think tls ever gets
off the launch pad but it is sure not from lack of trying.
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.
Since the swaks test made no mention of certificate
verification, I don't know for sure if it just worked silently
but I don't think so since swaks is a test tool and there would be
some mention of certificates if it had to verify one.
The isp in question is not terribly helpful about
settings for 3RD-party mail clients but I simply need for exim4
to duplicate what swaks did and we are good to go.
Whatever change I must make is probably in one of the files in
/etc/exim4/conf.d/transport that starts with 30 and ends with
smarthost. If I make any change there, must I use
dpkg-reconfigure exim4-config or simply use
systemctl restart exim4?
I have been using exim4 to send mail through
tls-encrypted sessions for almost exactly ten years. In 2023,
our ISP killed the exim setup in use by monkeying with the ports
that one needed to use to contact the smarthost. They swore up
and down that they had made no changes. I honestly believe they
really think they made no changes. Their technological expertise
in the matter stopped cold at "It works with outlook."
I finally stumbled on the fix more by accident than by
any help from the ISP.
I was beginning to wonder if they had gone to some
2-factor system but swaks proves that not to be the case.
Any constructive ideas are greatly appreciated since I
think exim4 is perfectly capable of handling this slight change
but it sure is hard to watch what is happening and know exactly
where and why things went wrong.
Martin McCormick
--
## 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/
