Simon Josefsson wrote an article about the current state of authentication mechanisms. It highlights problems with the SCRAM family of methods, but also points out that SCRAM addresses some shortcomings of simpler mechanisms such as PLAIN. This is worth reading!
This release adds support for SCRAM-SHA-256 authentication via libgsasl thanks to Simon Josefsson.
It also fixes a bug with %M in the envelope from address and updates translations.
A month ago, I questioned the value of newer authentication methods, in particular SCRAM-SHA-*, compared to simple PLAIN authentication over TLS, and concluded with "I really hope I'm wrong". Well, the good news is: I was wrong!
Here are the main points that convinced me:
My thanks to everyone who sent me comments and helped to convince me!
Also, to clarify: with GNU SASL, msmtp and mpop support SCRAM-SHA-1 and in the next version will also support SCRAM-SHA-256.
Update 2021-01-30: This does not mean that SCRAM-SHA-* is without flaws. See this comment by Simon Josefsson, who is an expert in these matters.
Update 2021-06-15: Simon Josefsson wrote an article about authentication mechanisms. It highlights problems with SCRAM, but also points out that SCRAM addresses some shortcomings of simpler mechanisms such as PLAIN.
This article asks why there are so many authentication methods when the simplest one works just fine.
There are several methods for password-based authentication with SMTP, POP3,
IMAP and other protocols. The simplest one is PLAIN. It just sends user name
and password, and that's it. The server side only needs to store a hash of the
password, not the password itself, so it cannot be stolen from the server. The
client side can store the password encrypted, so it cannot be stolen from the client
either (in msmtp and mpop: use a keyring or use gpg with passwordeval).
The transmission of the password is inside a TLS-secured session, so the
client knows it is really talking to the right service and not to an attacker,
and eavesdropping is prevented.
So, all problems are solved, right? But why then are there so many authentication methods? I have not found a convincing answer to this question yet. In the following, I will argue that even the relatively new SCRAM-SHA-256 method does not provide any practical benefit over PLAIN and is far more complex than it should be. If I am wrong, please send me a mail and correct me. I promise I will update this article with all the convincing arguments I receive.
My premise is that everyone is using TLS for every SMTP, POP3 or IMAP session
nowadays, since there is no such thing as a trustworthy network.
So what benefits does SCRAM-SHA-256 promise? According to RFC 5802:
stringprep and other Unicode-interpreting mess like in SCRAM-SHA-256!Update 2021-01-27: Here's the update I promised. The good news: I was wrong.
Update 2021-06-15: Simon Josefsson wrote an article about authentication mechanisms. It highlights problems with SCRAM, but also points out that SCRAM addresses some shortcomings of simpler mechanisms such as PLAIN.
This release adds support for the libtls library (provided by the LibreSSL project), thanks to Nihal Jere.
This is the third TLS library supported by msmtp. Use the --with-tls= option of the configure script to choose one.
Here's an overview:
--with-tls=gnutls): The default choice. Full feature set.--with-tls=libtls): A brand new addition. Already with full feature set.--with-tls=openssl): Old code, in bad shape. Needs to be updated or it will be removed.
This release add support for XOAUTH2 authentication, the predecessor of OAUTHBEARER that is still in use.
The passwordeval command can now handle long inputs for these methods.
Furthermore, translations were updated. Thanks again to the translators at translationproject.org!
With this release, msmtpd supports session reuse and improves standard compliance, and
automatic account matching in msmtp supports subaddresses. For example,
user+detail@example.com will match account user@example.com.
Furthermore, translations were updated. Thanks again to the translators at translationproject.org!
If you see "permission denied" errors with msmtp, please disable AppArmor to see if this fixes the problem:
sudo aa-disable /etc/apparmor.d/usr.bin.msmtp
More information: unfortunately Debian and Ubuntu provide an AppArmor profile for msmtp that
frequently breaks functionality, and in ways that are very hard to debug. Until they fix that profile,
I can only recommend disabling it whenever you see a "permission denied" error that has no apparent reason.
The latest example affects OAUTH2 authentication.
Thanks to Github user marcelolaia for figuring this out!
This release adds the undisclosed_recipients command that replaces all To, Cc, and Bcc headers with
a single "To: undisclosed-recipients:;" header. This is useful for example if you forward system mails and your
mail provider does not accept headers like "To: root" or similar.
Furthermore, portability was improved. There should be no "permission denied" errors for temporary files on Windows systems anymore.
Translations were updated. Thanks again to the translators at translationproject.org!
Christian Tenllado documented how to use msmtp with OAuth2 authentication for Gmail. Thanks!
This release fixes the msmtpq script that was accidentally broken in 1.8.8.
Furthermore, internationalization files are updated and a new serbian translation is included.
Thanks to the translators at translationproject.org!
Note that version 1.8.9 only partially fixed the msmtpq problem and was quickly replaced by 1.8.10.
This version includes the folowing changes:
socket command and --socket option to connect via local sockets.tls_host_override command and --tls-host-override option to
override the host name used for TLS verification.set_from_header command and --set-from-header option with three
settings:
on: always set a From header, possibly replacing an existing oneoff: never set a From headerauto: add a From header if there is none (this is the default).add_missing_from_header command (which remains supported).set_date_header command and --set-date-header option with two
settings:
off: never set a Date headerauto: add a Date header if there is none (this is the default).add_missing_date_header option (which remains supported).--read-recipients/-t.source_ip command for proxies.
This version extends the from command that sets the envelope from address: the patterns
%U, %H, %C, %M are now
replaced with user name, host name, canonicalized host name, and the contents of /etc/mailname.
This is useful for system-wide installations and is more powerful than the old
auto_from and maildomain commands, which are now
deprecated (but still supported, of course).
This version adds support for recursive alias expansion. Additionally, a few minor bugs were fixed.
This version fixes OAUTHBEARER authentication, adds support for TLS client certificates via PKCS11 devices such as smart cards, and fixes a few minor bugs.
This version adds support for the OAUTHBEARER authentication method and fixes a few minor bugs.
The git repository contains new support for the OAUTHBEARER authentication
method, formerly known as XOAUTH2, a method pushed mainly by Google.
This means msmtp can now use an OAuth2 token for authentication by setting
auth oauthbearer in the configuration file. The token is typically
passed to msmtp via the passwordeval command since it changes
regularly.
However, msmtp does not provide a way to generate such a token. This depends on
your mail provider.
Since I do not use this method myself, it would be great if you could test this
feature and maybe document how to generate the necessary token for your mail
provider, so that I can add examples to the documentation.
Looking forward to your feedback!
The source code moved to git.marlam.de, see the updated download instructions.
The reason is that gitlab vanished from Debian stable and there is no working upgrade path
to the version in Debian backports. Sorry for the inconvenience.
This version fixes a security problem that affects version 1.8.2 (older versions are not affected):
when the new default value system for tls_trust_file is used, the result
of certificate verification was not properly checked.
Update 2019-02-14: This problem has been assigned CVE-2019-8337. This is the patch that fixes it (included in version 1.8.3).
This version simplifies configuration:
--configure user@example.com option automatically
generates a configuration for the given mail address. This works for domains
that publish appropriate SRV records (as they should according to RFC 8314).tls on to activate TLS because
there is a new default value for tls_trust_file that selects
the system default trust.This version fixes a bug that broke TLS 1.3 support.
If you do not want to upgrade to the 1.8 series yet but you need TLS 1.3 support, you can apply this patch to msmtp version 1.6.8 or 1.4.32.
This is the first release of the new stable release series. Noteworthy changes since 1.6.8:
--without-msmtpd.passwordeval command does not require the password to be terminated by a
new line character anymore.logfile_time_format command allows to customize log file time stamps.This is a release candidate for the upcoming 1.8.x stable release series. The following changes were made:
--without-msmtpd.It is recommended to use msmtp with GnuTLS instead of OpenSSL. The upcoming version of msmtp will not use OpenSSL automatically anymore, and if you choose it manually, you will get a warning.
The reason for this is that the OpenSSL-related code in msmtp is essentially
unmaintained. I don't work on it myself anymore, and the last time somebody
sent a patch was 8 years ago.
As a result, if you use msmtp with OpenSSL today, you don't get support for
TLS SNI, --tls-priorities, --tls-crl-file, or
--tls-min-dh-prime-bits.
The code is hard to read, maintain, and improve due to severe limitations in the usability and documentation of the OpenSSL API. A few examples:
time_t.
This is insane, as both actions are required by virtually all TLS clients
and are hard to get right, see e.g.
here and
here.
Any usable TLS library must provide such functions. I understand that OpenSSL
1.1.0 finally added support for host name verification, but it still leaves you
alone with the terrible ASN1 time representation.Complexity is the enemy of security. I have given up on OpenSSL years ago and will not work to improve and update the OpenSSL-related code in msmtp. If someone wants to do that work, I will accept patches, but I will continue to recommend using GnuTLS instead. If the OpenSSL support in msmtp remains in its current state, it will eventually be removed.
There is an experimental new feature in the git repository: msmtpd, a minimal SMTP server
that listens on a local interface and pipes each incoming mail to msmtp (or a different program).
It is intended to be used with system services that expect an SMTP server on the local host and
cannot be configured to use the sendmail interface that msmtp provides.
If you are interested, use configure --with-msmtpd to enable it, and let us know
what you think.
New in this release:
--source-ip option or source_ip commandNew in this release:
~/.config/msmtp/config as configuration fileThe main git repository at gitlab.marlam.de/marlam/msmtp is now mirrored at github.com/marlam/msmtp-mirror.
After many years, this project moved from Sourceforge to a self-hosted gitlab instance:
https://gitlab.marlam.de/marlam/msmtp.
Older news are stored in the news archive.