Sending email off my (non-mail) server with sSMTP
Table of Contents
This article is originally from 2016, but I edited it a few times. Instead of trying to cover all sorts of usage scenarios, here's the disclaimer: this works on my setup. Yours may be different.
My server is not a mail server, and I never learned to use UNIX' internal mailing system.
But sometimes I want to get email from it, usually diagnostic messages from services (e.g. SMART daemon, fail2ban), sent to my third party email address.
And do the same if someone tries to contact me on my website.
The server runs debian stable (written when jessie was stable, all this still applies to stretch).
Previously I had been messing around with dovecot and exim4, which only resulted in breakage, until I realised that these are overkill for my needs.
What I really want is sSMTP, an "extremely simple MTA to get mail off the system to a mail hub".
Remove unneeded stuff-up-
I purged all packages that contain 'dovecot' and 'exim4' in their names, and
apt-get --purge autoremove afterwards. Then I went through all
leftover configuration/modification in
/etc and removed/undid it manually.
There was a lot of it, even after purging the packages.
It seems that even after that some residual configuration files are interfering.
aptitude search ~c will show what is leftover (I should probably have started with that).
aptitude -s purge ~c will simulate the removal, and this:
aptitude purge ~c will finally do it.
If you don't want to use aptitude, this has similar functionality:
dpkg -l | grep ^rc to see what residual config files are left over and
for i in $(dpkg -l | grep ^rc | cut -d” ” -f3); do dpkg –purge $i; done
to commit (source).
With a hopefully clean system, I installed ssmtp and mailutils:
apt-get install ssmtp mailutils.
sSMTP is not a daemon, it provides the
ssmtp binary which can be invoked
manually or by other processes.
sendmail is symlinked to
PHP by default relies on sendmail to send out e-mail (you can check with
grep sendmail_path -r /etc/php*), and most contact form plugins or code snippets rely on that.
/etc/ssmtp/ssmtp.conf along these lines:
# Config file for sSMTP sendmail # # The person who gets all mail for userids < 1000 # Make this empty to disable rewriting. #root= # The place where the mail goes. The actual machine name is required no # MX records are consulted. Commonly mailhosts are named mail.domain.com # (not my mail provider though - it's just domain.com) mailhub=domain.com:465 # Where will the mail seem to come from? #rewriteDomain= # The full hostname # (can be the server name or an IP address) #hostname= # probably not required # Are users allowed to set their own From: address? # YES - Allow the user to specify their own From: address # NO - Use the system generated From: address FromLineOverride=NO AuthMethod=LOGIN UseTLS=YES #UseSTARTTLS=YES # this way is safer, but you may need to uncomment. in this case you likely # also need to change the port for mailhub, probably to 587 AuthUserfirstname.lastname@example.org AuthPass=verysecret
I gleaned most of this information from my email client.
Sending a test mail-up-
# ssmtp email@example.com
I needed to be root for this.
sSMTP will then wait for you to type your message, which needs to be formatted like this:
To: firstname.lastname@example.org From: email@example.com Subject: test email hello world! ^D
Note the blank like after the subject, everything after this line is the body of the email. Then I pressed Ctrl-D. sSMTP may take a few seconds to send the message before closing (source).
If that worked, try again from your website's contact form. If that doesn't work,
you need to go searching for helpful log entries. There's
/var/log/mail.* which might provide the answers you need.
After that it's server logs.
Here's what I had to do, more than once:
Fix permissions on /etc/ssmtp/ssmtp.conf (also for /etc/ssmtp/revaliases, see below):
The files in
/etc/ssmtp should probably look like this:
-rw-r----- 1 root mail 111 Mar 23 10:00 revaliases -rw-r----- 1 root mail 840 Mar 23 11:25 ssmtp.conf
This means that users that want to use sSMTP need to be in the mail group (in my experience contrary to what the arch wiki says; I'm doing this on Debian after all). This is what I had to do to enable my web server's PHP processes to send mail:
# usermod -a -G mail www-data
But that only enabled me to send mail with the same "From" address as is my account's, and the software sending out the mails usually fills this automatically with something like
To make it work more generally I additionally had to:
Set up both rewriting in /etc/ssmtp/ssmtp.conf and /etc/ssmtp/revaliases both for all involved users:
# /etc/ssmtp/ssmtp.conf: firstname.lastname@example.org email@example.com firstname.lastname@example.org
# /etc/ssmtp/revaliases: root:email@example.com:smtp.somemailbox.org:465 normaluser:firstname.lastname@example.org:smtp.somemailbox.org:465 www-data:email@example.com:smtp.somemailbox.org:465
(These are just example entries, replace with actual usernames / servers / ports)
Disallow users to set their own from address in /etc/ssmtp/ssmtp.conf:
Now sSMTP is able to send both system mail (generated by services) and website mail to my email address.
Configuration for Gmail-up-
This might be outdated; I wrote it three years ago and haven't used gmail since then.
Activate 'allow less secure apps' from your gmail profile.
/etc/ssmtp/ssmtp.conf should look like this:
firstname.lastname@example.org mailhub=smtp.gmail.com:587 #rewriteDomain=nn.nn.nn.nn (my IP) # should not be required #hostname=nn.nn.nn.nn # should not be required FromLineOverride=YES UseTLS=YES UseSTARTTLS=YES AuthUseremail@example.com # same as above AuthPass=verysecret AuthMethod=LOGIN