Sometimes an update causes a chain reaction which borks a system. Here are some notes on how I fixed a SMTP mail issue on my Raspberry Pi camera project.
A quick recap: the RPi camera takes pictures every ten minutes, each night the images get sent to a server and each week the transferred images get deleted. It’s all automated and I have setup the RPi to email me when the images are transferred and when they get scrubbed so I know that everything is going OK. Details are here, here and here.
First problem – a server update causes an issue
I updated my server (where the images are stored). This deprecated smb1 on the NAS so that my transfer script no longer worked. No files were transferred that night and the RPi dutifully emailed me to alert me to this problem. I could fix this easily enough by changing this line
sudo mount -t cifs -o user=xxx,pass=xxx,vers=1.0 //server.address/xxx/ /mnt/abc
to specify smb2.1
sudo mount -t cifs -o user=xxx,pass=xxx,vers=2.1 //server.address/xxx/ /mnt/abc
I decided that, having run this system for several years, I should make sure everything is up to date. I decided to upgrade from Stretch to Buster (there are many guides online for how to do this). All went well, or (and you may be ahead of me here) so I thought.
Second problem – no email and no error
The following day, I had no email from the RPi telling me what it had been doing. I checked the transfer of the previous days files to the server and all was fine. So email was broken. I first suspected that the because I had updated the OS, I needed to issue a new app password for gmail. However, a new password didn’t fix the problem.
I was pretty lost. Testing the email like this
echo "Hello, World!" | ssmtp email@email.com
ssmtp: (picam)
Produced no error. Using -v to give a verbose output showed that everything went fine until it came to actually sending the message.
echo "Hello, World!" | ssmtp -v email@email.com
[<-] 220 smtp.gmail.com ESMTP xxxxxxxxxxxxxx - gsmtp
[->] EHLO picam
[<-] 250 SMTPUTF8
[->] STARTTLS
[<-] 220 2.0.0 Ready to start TLS
[->] EHLO picam
[<-]
ssmtp: (picam)
TLS and EHLO all seem OK but no message is sent (see blank line).
If ever there was a case of needing to Google the correct thing to fix the problem, this is a great example.
The web is awash with posts on how to setup and troubleshoot SSMTP on linux and many messages that relate to gmail authentication. Googling the 250 SMTPUTF8 line brought me to a wonderous page which – despite the title sounding like someone with a gmail authentication problem – had the answer (via an additional page).
SSMTP does not work on Buster
Knowing this was a relief. Fixing it took a few seconds, it just needed a switch to MSMTP
sudo apt-get install msmtp msmtp-mta
then using sudo nano /etc/msmtprc
# Generics
defaults
auth on
tls on
# following is different from ssmtp:
tls_trust_file /etc/ssl/certs/ca-certificates.crt
# user specific log location, otherwise use /var/log/msmtp.log, however,
# this will create an access violation if you are user pi, and have not changes the access rights
logfile ~/.msmtp.log
# Gmail specifics
account gmail
host smtp.gmail.com
port 587
from root@picam
user your-gmail-accountname@gmail.com
password your-gmail-account-password
# Default
account default : gmail
A test message was sent successfully using:
echo "Hello, World!" | msmtp email@email.com
I just needed to update my shell script which fires off the email so that it specifies msmtp rather than smtp. Since a full path to the program is needed, you can quickly check what is needed using which msmtp
Happy days! The setup is working again now.