In this tutorial, we'll configure everything needed to send emails from the
terminal. We'll use
msmtp, a lightweight SMTP client. For the sake of
the example, we'll use a GMail account, but any other email provider can do.
Your OS is expected to be
Debian, as usual on this blog, although it
doesn't really matter. We will also see how to store the credentials for the
email account in the system keyring. And finally, we'll go the extra mile, and
see how to configure various command-line utilities so that they automatically
use msmtp to send emails. Even better, we'll make msmtp the default email
sender, to actually avoid configuring these utilities one by one.
Prerequisites
Strong prerequisites (if you don't recognize yourself here, you probably landed
on the wrong page):
- You run Linux on your computer (let's assume a Debian-like distro).
- You want to send emails from your terminal.
Weak prerequisites (if your setup doesn't match those points exactly, that's
fine, you can still read on):
- Your email account is a GMail one.
- Your desktop environment is GNOME.
GMail account setup
For a GMail account, there's a bit of configuration to do. For other email
providers, I have no idea, maybe you can just skip this part, or maybe you will
have to go through a similar procedure.
If you want an external program (
msmtp in this case) to talk to the GMail
servers on your behalf, and send emails, you can't just use your usual GMail
password. Instead, GMail requires you to generate so-called
app passwords,
one for each application that needs to access your GMail account.
This approach has several advantages:
- it will basically work, GMail won't block you because it thinks that you're
trying to sign in from an unknown device, a weird location or whatever.
- your main GMail password remains secret, you won't have to write it down
in any configuration file or anywhere else.
- you can change your main GMail password, no breakage, apps will still work as
each of them use their own passwords.
- you can revoke an app password anytime, without impacting anything else.
So app passwords are a good idea, it just requires a bit of work to set it up.
Let's see what it takes.
First,
2-Step Verification must be enabled on your GMail account. Visit
https://myaccount.google.com/security, and if that's not the case, enable it.
You'll need to authorize all of your devices (computer(s), phone(s) and so on),
and it can be a bit tedious, granted. But you only have to do it once in a
lifetime, and after it's done, you're left with a more secure account, so it's
not that bad, right?
Enabling the 2-Step Verification will unlock the feature we need:
App
passwords. Visit
https://myaccount.google.com/apppasswords, and under
"
Signing in to Google", click "
App passwords", and generate one. An app
password is a 16 characters string, something like
qwertyuiopqwerty. It's
supposed to be used from only one place, ie. from ONE application that is
installed on ONE device. That's why it's common to give it a name of the form
application@device, so in our case it could be
msmtp@laptop, but really
it's free form, choose whatever name suits you, as long as it makes sense to
you.
So let's give a name to this app password, write it down for now, and we're
done with the GMail config.
Send your first email
Time to get started with
msmtp.
First thing first, installation, trivial:
Let's try to send an email. At this point, we did not create any configuration
file for msmtp yet, so we have to provide every details on the command line.
# Write a dummy email
cat << EOF > message.txt
From: YOUR_LOGIN@gmail.com
To: SOMEONE_ELSE@SOMEWHERE_ELSE.com
Subject: Cafe Sua Da
Iced-coffee with condensed milk
EOF
# Send it
cat message.txt msmtp \
--auth=on --tls=on \
--host smtp.gmail.com \
--port 587 \
--user YOUR_LOGIN \
--read-envelope-from \
--read-recipients
# msmtp prompts you for your password:
# this is where goes the app password!
Obviously, in this example you should replace the uppercase words with the
real thing, that is, your email login, and real email addresses.
Also, let me insist, you must enter the
app password that was generated
previously, not your real GMail password.
And it should work already, this email should have been sent and received by
now.
So let me explain quickly what happened here.
In the file
message.txt, we provided
From: (the email address of the person
sending the email) and
To: (the destination email address). Then we asked
msmtp to re-use those values to set the
envelope of the email with
--read-envelope-from and
--read-recipients.
What about the other parameters?
--auth=on because we want to authenticate with the server.--tls=on because we want to make sure that the communication with the
server is encrypted.--host and --port tells where to find the server. If you don't use GMail,
adjust that accordingly.--user is obviously your GMail username.
For more details, you should refer to the
msmtp documentation.
Write a configuration file
So we could send an email, that's cool already.
However the command to do that was a bit long, and we don't want to juggle with
all these arguments every time we send an email. So let's write down all of
that into a configuration file.
msmtp supports two locations:
~/.msmtprc and
~/.config/msmtp/config, at
your preference. In this tutorial we'll use
~/.msmtprc for brevity:
cat << 'EOF' > ~/.msmtprc
defaults
tls on
account gmail
auth on
host smtp.gmail.com
port 587
user YOUR_LOGIN
from YOUR_LOGIN@gmail.com
account default : gmail
EOF
And for a quick explanation:
- under
defaults are the default values for all the following accounts.
- under
account are the settings specific to this account, until another
account line is found.
- finally, the last line defines which account is the default.
All in all it's pretty simple, and it's becoming easier to send an email:
# Write a dummy email. Note that the
# header 'From:' is no longer needed,
# it's already in '~/.msmtprc'.
cat << 'EOF' > message.txt
To: SOMEONE_ELSE@SOMEWHERE_ELSE.com
Subject: Flat White
The milky way for coffee
EOF
# Send it
cat message.txt msmtp \
--account default \
--read-recipients
Actually,
--account default is not needed, as it's the default anyway if you
don't provide a
--account argument. Furthermore
--read-recipients can be
shortened as
-t. So we can make it real short now:
At this point, life is good! Except for one thing maybe: we still have to type
the password every time we send an email. Surely it must be possible to avoid
that annoyance...
Store your password in the system keyring
For this part, we'll make use of the
libsecret tool to store the password
in the system keyring via the
Secret Service API. It means that your
desktop environment should implement the Secret Service specification, which is
the case for both GNOME and KDE.
Note that GNOME provides
Seahorse to have a look at your secrets, KDE has
the
KDE Wallet. There's also
KeePassXC, which I have only heard of but
never used. I guess it can be your password manager of choice if you use
neither GNOME nor KDE.
For those running an up-to-date Debian unstable, you should have
msmtp >=
1.8.11-2, and you're all good to go. For those having an older version than
that however, you will have to install the package
msmtp-gnome in order to
have msmtp built with libsecret support. Note that this package depends on
seahorse, hence it pulls in a good part of the GNOME stack when you install
it. For those not running GNOME, that's unfortunate. All of this was discussed
and fixed in
#962689.
Alright! So let's just make sure that the libsecret tools are installed:
sudo apt install libsecret-tools
And now we can store our password in the system keyring with this command:
secret-tool store --label msmtp \
host smtp.gmail.com \
service smtp \
user YOUR_LOGIN
If this looks a bit too magic, and you want something more visual, you can
actually fire a GUI like
seahorse (for GNOME users), or
kwalletmanager5
(for KDE users), and then you will see what passwords are stored in there.
Here's a screenshot of Seahorse, with a msmtp password stored:
Let's try to send an email again:
No need for a password anymore, msmtp got it from the system keyring!
For more details on how msmtp handle the passwords, and to see what other
methods are supported, refer to the
extensive documentation.
Use-cases and integration
Let's go over a few use-cases, situations where you might end up sending emails
from the command-line, and what configuration is required to make it work with
msmtp.
Git Send-Email
Sending emails with git is a common workflow for some projects, like the Linux
kernel. How does
git send-email actually send emails? From the
git-send-email manual page:
the built-in default is to search for sendmail in /usr/sbin, /usr/lib and
$PATH if such program is available
It is possible to override this default though:
--smtp-server=
[...] Alternatively it can specify a full pathname of a sendmail-like program
instead; the program must support the -i option.
So in order to use msmtp here, you'd add a snippet like that to your
~/.gitconfig file:
[sendemail]
smtpserver = /usr/bin/msmtp
For a full guide, you can also refer to
https://git-send-email.io.
Debian developer tools
Tools like
bts or
reportbug are also good examples of command-line tools
that need to send emails.
From the
bts manual page:
--sendmail=SENDMAILCMD
Specify the sendmail command [...] Default is /usr/sbin/sendmail.
So if you want bts to send emails with msmtp instead of sendmail, you must use
bts --sendmail='/usr/bin/msmtp -t'.
Note that bts also loads settings from the file
/etc/devscripts.conf and
~/.devscripts, so you could also set
BTS_SENDMAIL_COMMAND='/usr/bin/msmtp
-t' in one of those files.
From the
reportbug manual page:
--mta=MTA
Specify an alternate MTA, instead of /usr/sbin/sendmail (the default).
In order to use msmtp here, you'd write
reportbug --mta=/usr/bin/msmtp.
Note that reportbug reads it settings from
/etc/reportbug.conf and
~/.reportbugrc, so you could as well set
mta /usr/bin/msmtp in one of those
files.
So who is this sendmail again?
By now, you probably noticed that
sendmail seems to be considered the
default tool for the job, the "traditional" command that has been around for
ages.
Rather than configuring every tool to use something else than sendmail,
wouldn't it be simpler to actually replace sendmail by msmtp? Like, create a
symlink that points to msmtp, something like
ln -sr /usr/bin/msmtp
/usr/sbin/sendmail? So that msmtp acts as a drop-in replacement for sendmail,
and there's nothing else to configure?
Answer is yes, kind of. Actually, the
first msmtp feature
that is listed on the homepage is "
Sendmail compatible interface (command
line options and exit codes)". Meaning that msmtp
is a drop-in replacement
for sendmail, that seems to be the intent.
However, you should refrain from creating or modifying anything in
/usr, as
it's the territory of the package manager,
apt. Any change in
/usr might be
overwritten by apt the next time you run an upgrade or install new packages.
In the case of msmtp, there is actually a package named
msmtp-mta that will
create this symlink for you. So if you really want a definitive replacement for
sendmail, there you go:
sudo apt install msmtp-mta
From this point, sendmail is now a symlink
/usr/sbin/sendmail
/usr/bin/msmtp, and there's no need to configure
git,
bts,
reportbug or
any other tool that would rely on sendmail. Everything should work "out of the
box".
Conclusion
I hope that you enjoyed reading this article! If you have any comment, feel
free to send me a short email, preferably from your terminal!
DebConf20 is taking place online, from 23 August to 29 August 2020.
It is the 21st Debian conference, and organizers and participants are working hard
together at creating interesting and fruitful events.
We would like to warmly welcome the 17 sponsors of DebConf20, and introduce them to you.
We have four Platinum sponsors.
Our first Platinum sponsor is Lenovo.
As a global technology leader manufacturing a wide portfolio of connected products,
including smartphones, tablets, PCs and workstations as well as AR/VR devices,
smart home/office and data center solutions, Lenovo
understands how critical open systems and platforms are to a connected world.
Our next Platinum sponsor is Infomaniak.
Infomaniak is Switzerland's largest web-hosting company,
also offering backup and storage services, solutions for event organizers,
live-streaming and video on demand services.
It wholly owns its datacenters and all elements critical
to the functioning of the services and products provided by the company
(both software and hardware).
Google is our third Platinum sponsor.
Google is one of the largest technology companies in the
world, providing a wide range of Internet-related services and products such
as online advertising technologies, search, cloud computing, software, and hardware.
Google has been supporting Debian by sponsoring DebConf for more than
ten years, and is also a Debian partner.
Amazon Web Services (AWS) is our fourth Platinum
sponsor.
Amazon Web Services is one of the world's
most comprehensive and broadly adopted cloud platforms,
offering over 175 fully featured services from data centers globally
(in 77 Availability Zones within 24 geographic regions).
AWS customers include the fastest-growing startups, largest enterprises
and leading government agencies.
Our Gold sponsors are Deepin, the Matanel Foundation, Collabora, and HRT.
Deepin is a Chinese commercial company focusing on
the development and service of Linux-based operating systems. They also lead
research and development of the Deepin Debian derivative.
The Matanel Foundation operates in Israel,
as its first concern is to preserve the cohesion of a society and a nation
plagued by divisions. The Matanel Foundation also works in Europe, in Africa
and in South America.
Collabora is a global consultancy delivering
Open Source software solutions to the commercial world.
In addition to offering solutions to clients, Collabora's engineers and developers
actively contribute to many Open Source projects.
Hudson-Trading
is a company led by mathematicians, computer scientists, statisticians,
physicists and engineers. They research and develop automated trading algorithms
using advanced mathematical techniques.
Our Silver sponsors are:
Linux Professional Institute, the global
certification standard and career support organization for open source professionals,
Civil Infrastructure Platform,
a collaborative project hosted by the Linux Foundation,
establishing an open source base layer of industrial grade software,
Ubuntu,
the Operating System delivered by Canonical,
and Roche,
a major international pharmaceutical provider and research company
dedicated to personalized healthcare.
Bronze sponsors:
IBM,
MySQL,
Univention.
And finally, our Supporter level sponsors, ISG.EE
and Pengwin.
Thanks to all our sponsors for their support!
Their contributions make it possible for a large number
of Debian contributors from all over the globe to work together,
help and learn from each other in DebConf20.
Participating in DebConf20 online
The 21st Debian Conference is being held online, due to COVID-19,
from August 23 to 29, 2020. Talks, discussions, panels and other activities run from 10:00 to 01:00 UTC.
Visit the DebConf20 website at https://debconf20.debconf.org
to learn about the complete schedule, watch the live streaming and join the different
communication channels for participating in the conference.
Like 
Welcome to the 29th post in the randomly repeating R recommendations series or 
This fails for RSPM as no binary is present and a source build fails for the familiar lack of a 
The installation of 
After this output appears, you ll need to reboot your machine before you can
continue.
Once your machine is rebooted, you need to install a Linux distribution.
Different communities and companies ship their own versions of Linux and the
various services and utilities required to use it, and these versions are
called distributions.
If you re not sure which one to use, I would recommend 
After:
After we gave our talk at DebConf 20, 
Shortly after yesterday s start of the 
After a short introduction by Hong Phuc we turned to a self-introduction and what is equality for me round. This brought up already a wide variety of issues that need to be addressed if we want to counter inequality in free software (culture differences, language barriers, internet connection, access to services, onboarding difficulties, political restrictions, ).
Unfortunately, on-air time was rather restricted, but even after the DebConf related streaming time slot was finished, we continued discussing problems and possible approaches for another two hours. We have agreed to continue our collaboration and meetings in the hope that we, in particular the FOSSASIA community, can support those in need to counter inequality.
Concluding, I have to say I am very happy to be part of the FOSSASIA community where real diversity is lived and everyone strives for and tries to increase social equality. In the DebConf IRC chat I was asked why at FOSSASIA we have about a 50:50 quote between women and men, in contrast to the usual 10:90 predominant in most software communities including Debian. For me this boils down to many reasons, one being competent female leadership, Hong Phuc is inspiring and competent to a degree I haven t seen in anyone else. Another reason is of course that software development is, especially in developing countries, one of the few escape pods for any gender, and thus fully embraced by normally underrepresented groups. Finally, but this is a typical chicken-egg problem, the FOSSASIA community is not doing any specific gender politics, but simply remains open and friendly to everyone. I think Debian, and in particular the diversity movement in Debian can learn a lot from the FOSSASIA community. At the end we are all striving for more equality in our projects and in the realm of free software as a whole!
Thanks again for all the participants for the very inspiring discussion, and I am looking forward to our next meetings!
As client certificates are on the way out and Debian's SSO solution is effectively not maintained any longer, I switched self-service buildd givebacks over to Salsa authentication. It lives again at 
As we grow old, so do our computing machines. And just like we don t decommission ourselves, so should be the case of the machines. They should be semi-retired, delegating major tasks to newer machines while they can still serve some less demaning work: File Servers, UPNP Servers et cetera.
It is common on a Debian installer based derivative, and otherwise too, to use block encryption on Linux. With machines from this decade, I think we ve always had CPU extension for encryption.
So, as would be the usual case, all my laptops are block encrypted. But as they reach the phase of their life to retire and serving as a headless boss, it becomes cumbersome to keep feeding it a password and all the logistics involved to feed it. As such, I wanted to get rid of feeding it the password.
Then, there s also the case of bad/faulty hardware, many of which mostly can temporarily fix their functionality when reset, which usually is to reboot the machine. I still recollect words of my Linux Guru - Dhiren Raj Bhandari - that many of the unexplainable errors can be resolved by just rebooting the machine. This was more than 20 years ago in the prime era of Microsoft Windows OS and the context back then was quite different, but yes, some bits of that saying still apply today.
So I wanted my laptop, which had LUKS set up for 2 disks, to go password-less now. I stumbled across a