exim4 and TLS Once Again
After about two weeks of going down all sorts of rabbit holes
and wasting tons of time, I am at a loss trying to get
exim4 to resume the ability to send messages via the smarthost
used by our ISP. The real trouble here is that all one really
knows is that something's broken. It happens as soon as exim4
contacts the server. The server immediately aborts. It's the
ultimate "Check engine" light. 30-thousand moving parts and one
is bad. Go figure.
It was all working fine for nearly 3 years save for a
hiccup of some kind at the ISP's site last January but this time,
it is on my end and I know that for sure.
Connections are made using TLS on port 465.
Originally, what one did was to enter the user name and
password in to a file called /etc/exim4/passwd.client as follows:
# password file used when the local exim is authenticating to a remote
# host as a client.
#
# see exim4_passwd_client(5) for more documentation
#
# Example:
### target.mail.server.example:login:password
*.suddenlink.net:martin.m@suddenlink.net:deepsecret
The other modification was to a file called
/etc/exim4/update-exim4.conf.conf which is a debian-specific file
that configures the configurations hence .conf.conf.
One added a couple of lines to indicate we are using the
protocol called smtps.
After that, one ran dpkg-reconfigure exim4-config and
selected to send mail through a smarthost and receive via
fetchmail.
It all worked until I upgraded to stretch at which point
the smarthost began dumping the connection upon the login
attempt. At least that is what appears to happen.
Actually, I couldn't even run the reconfigure because it
complained about the protocol = smtps line and refused to build
/var/lib/exim4/conf.autogenerated file. I had to remove that
line and then it built a dead-on-arrival conf.autogenerated file
that still allows exim4 to deliver local mail but always gets the boot
from the suddenlink server.
After a week of web searches, there is a bundle of
out-dated how-to's that used to work but nothing useful for what
to do to fix it now.
So, you might ask, How am I sending this message?
It's a proper question, all right.
There has been a program called msmtp that only does one
thing well and that is to make a smtps connection to a smtp
smarthost.
One sets up a configuration file called ~/.msmtprc and
there is where you put the smarthost's fully-qualified domain
name plus one's login credentials.
It works just fine. You link the name sendmail to
/usr/bin/msmtp and call it via that link with the -t flag as you
pipe your message to it. The message must be a
properly-formatted email message and msmtp makes the login to the
smarthost and delivers the message.
The trouble is that you lose local mail on the system so
you don't get all the gory detains when a shell script run by
cron blows up, etc. I've got a few of those kinds of scripts and
it is nice to know when they misbehave.
The real problem is that there does not appear to be a
reasonable way to listen to the transaction when you need it
most. Since the encryption is end-to-end, wireshark or some
third-party monitoring device will just spout garbage when what
one needs is a clear-text feed of what exim4 and the server are
saying to each other. If exim4 could do that, we would know what
the last words were before the wheels came off.
At least I know the login credentials have not changed
since msmtp works but this business of manually piping a
formatted message to msmtp is for the birds but at least it beats
nothing by a hair.
exim -d -M on a message puts out about 400 plus lines of
mostly useless information, a full-color check engine light so to
speak.
Any constructive ideas are much appreciated.
Thank you.
Martin McCormick
Reply to: