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:marti...@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