msmtp 1.8.30 is released

2025-06-01

This release fixes a double-free bug that was introduced in 1.8.29.

msmtp 1.8.29 is released

2025-05-29

In this release:

• Added a new configuration command set_to_header. If activated, this replaces To, Cc, Bcc with a new To header.
• Added a new substitution pattern %F for the from command. This allows to set the envelope-from address to the content of the From header.
• Many improvements in the msmtpq script.
• Updated translations, including a new zh_CN translation. Thanks to everyone at translationproject.org!

msmtp 1.8.28 is released

2025-01-13

This release improves internationalization support: it uses the SMTPUTF8 capability by default if available, and can handle international domain names in configure mode.
Additionally, several updates to the build system and to the msmtpq script were made.

msmtp 1.8.27 is released

2024-10-06

In this release:

• The option -F was fixed: it now overrides the configuration file setting again (this bug was introduced in 1.8.24), and non-ASCII characters are now properly encoded in the From header.
• The msmtpq script was improved by Github user Konfekt. Thanks!
• The vim script for configuration file editing was improved by Github user Konfekt. Thanks!
• A testing infrastructure was added (make check).
• Translations were updated and a new Spanish translation was added, thanks again to everyone at translationproject.org!

msmtp 1.8.26 is released

2024-05-01

This release adds support for SCRAM-SHA-*-PLUS authentication, and prefers to use the SCRAM methods if they are available.
A Resent-From header, if present, is now taken into consideration when --read-envelope-from is used.
Translations were updated, thanks again to everyone at translationproject.org!

msmtp 1.8.25 is released

2023-10-29

This is a bug fix release:

• Generation of Message-ID headers was improved to avoid problems with rspamd assigning SPAM points
• Documentation of ignored options was fixed
• The combination of envelope from addresses with wildcards and automatic account selection was fixed (thanks to Jonathan Wakely)
• Translations were updated, including a new Romanian translation (thanks again to everyone at translationproject.org)

20 years of msmtp

2023-07-27

On this day 20 years ago msmtp version 0.2.5 was released. This was the first public version.

It's been a long time, and I'm happy msmtp is still in use: there's a lot of msmtp packages out there, the Debian popcon numbers and Arch Linux relative usage numbers still suggest relevance, and msmtp copyright notices have popped up in many embedded system manuals and integrated software packages.

Most importantly: there is still regular feedback from users. This was always one of my main motivations for working on msmtp. Without your suggestions, bug reports and patches, msmtp would still be at version 0.2.5, and I would have learned nothing new, so I'd like to thank you all for the last 20 years, and I look forward to the coming years :)

msmtp 1.8.24 is released

2023-06-29

This release fixes the allow_from_override command, adds the from_full_name command, fixes a few minor bugs and updates the translations (thanks again to everyone at translationproject.org).

msmtp 1.8.23 is released

2023-01-30

This release fixes XOAUTH2 authentication with some servers, updates the msmtpq scripts, and updates the translations (including a new Swedish translation).

msmtp 1.8.22 is released

2022-08-08

This is a hotfix release that fixes building with libgsasl, which was accidentally broken in version 1.8.21 (released earlier today).
It also updates the msmtpq script.

msmtp 1.8.21 is released

2022-08-07

Changes in this release:

• A new configuration command eval replaces the current configuration file line with the output of a command (similar to passwordeval, but more general).
• A Message-ID header is now generated if none is present in the mail. This can be changed with the new command set_msgid_header.
• The optional msmtpd service now adds a Received header.

msmtp 1.8.20 is released

2022-03-23

This release adds the configuration command allow_from_override.
Setting this to off prevents the -f command line option from overriding the envelope-from address set via the from configuration command.
This is useful for system-wide installations of msmtp that need to enforce the correct envelope-from address and potentially also the From header (via set_from_header on).

msmtp 1.8.19 is released

2021-11-04

This release fixes a security problem in the minimal SMTP server msmtpd: mail addresses starting with a hyphen could be interpreted as command line options by the pipe command. This could be used to make the pipe command run arbitrary executables with the user id of the msmtpd process.

Note that msmtp itself is not affected. You are only affected if you run msmtpd without authentication and with a pipe command that does not end with -- (to separate options from arguments). Since msmtpd only accepts connections on the local interface by default, this bug can only be triggered by untrusted processes on your machine; it cannot be triggered over the network.

As a workaround, you can configure the msmtpd pipe command to end with --.
If you want to patch an older version instead of updating to 1.8.19, the relevant git commit is 2679609f72e27760f9785c3905f9943451b47a12 and this patch applies to all versions starting with 1.8.0 when used with patch -F3.

msmtp 1.8.18 is released

2021-10-22

This release fixes a few minor problems related to translations and the documentation.

msmtp 1.8.17 is released

2021-10-03

This release adds new options to the minimal SMTP server msmtpd to enable a new use case: now you can use it as a gateway between msmtp and mail software such as Thunderbird that cannot use msmtp directly and insists on using an SMTP server.
Similarly, the new minimal POP3 server mpopd (part of mpop) can now be used as a gateway between a local mail box on your disk and mail software that insists on using a POP3 server.
So now you can have full control over incoming and outgoing mail, including all the processing and filtering with any tools you want, while still using a mail client that does not give you these options itself.
See the msmtpd and mpopd documentation for examples.

msmtp 1.8.16 is released

2021-09-13

With this release, the from command now accepts patterns (as in shell file name matching) so that many different envelope from addresses given on the command line can match the same account. The domain command now supports expansion of %H, %C and %M. The msmtpd daemon now supports sysexits.h error codes from the pipe command. For configurations using libtls instead of GnuTLS, the tls_fingerprint and tls_certcheck commands were fixed.

msmtp and starttls security

2021-08-26

A recent security analysis of STARTTLS revealed many problems of STARTTLS (as opposed to immediate TLS) in mail clients and servers. The researchers published their fake mail server software that can be used for testing client software such as msmtp.
I used this software to test msmtp and found no problems, but I would be grateful if someone could double check this in case I missed something. Please let me know your results, I will update this news item accordingly!

Simon Josefsson on SCRAM authentication

2021-06-15

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!

msmtp 1.8.15 is released

2021-03-12

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.

About authentication methods: Update

2021-01-27

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:

• Storing hashed and salted passwords is good.
  Previously I believed that everyone should simply use unique strong passwords so that just hashing them is a sufficient countermeasure against password theft. But that is a naive view (and it was arrogantly phrased). It will never happen. So the attractiveness of authentication databases for the bad guys must be reduced as much as possible. Salting helps.
• Having guarantees about the server identity that are independent of the TLS trust model is good.
  With SCRAM-SHA-*, the server must prove to the user that it is in possession of the (hashed and salted) password. This makes it far more difficult for an attacker to impersonate a server, even if he manages to get the user to accept a forged TLS certificate. And this is a good thing, given the questionable trust model of TLS.

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.

About authentication methods

2020-12-28

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:

• There are some significant security concerns with the transmission of clear-text passwords over a TLS-protected channel.
  Are there? The RFC does not list any. Please specify.
• The authentication information stored in the authentication database is not sufficient by itself to impersonate the client.
  This is true also PLAIN when the server stores just hashes.
  The information is salted to prevent a pre-stored dictionary attack if the database is stolen.
  Dictionary attacks do not help with good passwords. And if the user is too stupid to use a password manager for good unique passwords, then inventing a more complicated authentication method will not help you: your user will still write the password on a post-it note, stick it on a monitor, and then post a photo of his desk on social media. He will also without hesitation run any software from any source on his computer and not care about security updates or privacy settings. In other words: the user must be educated, you cannot solve this problem with technical means.
• The server does not gain the ability to impersonate the client to other servers.
  If you cannot trust your mail server, then it is game over anyway, so this is not a relevant concern.
• Mutual authentication is supported.
  Why would the client want the server to authenticate itself? It is already using TLS and has verified that it is talking to the right server.
• SCRAM is capable of transporting authorization identities.
  For what purpose? This is not needed for password-based authentication.
• Support for channel binding.
  This has absolutely no benefit when always using TLS, as far as I can see.
• Support for Unicode user names and passwords.
  PLAIN supports that too, and in a much simpler way: it sees both user name and password simply as byte sequences. Of course both should be valid UTF-8, but that does not need to concern the method; this is handled simply on the client side. No need for 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.

msmtp 1.8.14 is released

2020-12-23

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:

• GnuTLS (--with-tls=gnutls): The default choice. Full feature set.
• libtls (--with-tls=libtls): A brand new addition. Already with full feature set.
• OpenSSL (--with-tls=openssl): Old code, in bad shape. Needs to be updated or it will be removed.

msmtp 1.8.13 is released

2020-11-13

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!

msmtp 1.8.12 is released

2020-08-21

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!

msmtp permission denied errors: disable apparmor!

2020-08-15

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!

Update 2021-09-13:The Debian package for msmtp 1.8.15 now disables the AppArmor profile by default. The profile has received many improvements in the mean time, so it might make sense to enable it depending on your use case. Many thanks to the Debian contributors for their work!

msmtp 1.8.11 is released

2020-06-03

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!

msmtp with oauth2 for gmail

2020-04-30

Christian Tenllado documented how to use msmtp with OAuth2 authentication for Gmail. Thanks!

msmtp 1.8.10 is released

2020-04-23

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.

msmtp 1.8.8 is released

2020-04-12

This version includes the folowing changes:

• Added a new socket command and --socket option to connect via local sockets.
• Added a new tls_host_override command and --tls-host-override option to override the host name used for TLS verification.
• Added a new set_from_header command and --set-from-header option with three settings:
  • on: always set a From header, possibly replacing an existing one
  • off: never set a From header
  • auto: add a From header if there is none (this is the default).
  This replaces the add_missing_from_header command (which remains supported).
• Added a new set_date_header command and --set-date-header option with two settings:
  • off: never set a Date header
  • auto: add a Date header if there is none (this is the default).
  This replaces the add_missing_date_header option (which remains supported).
• Fixed the handling of empty From headers with --read-recipients/-t.
• Fixed the source_ip command for proxies.

msmtp 1.8.7 is released

2019-12-24

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).

msmtp 1.8.6 is released

2019-09-27

This version adds support for recursive alias expansion. Additionally, a few minor bugs were fixed.

msmtp 1.8.5 is released

2019-07-12

This version fixes OAUTHBEARER authentication, adds support for TLS client certificates via PKCS11 devices such as smart cards, and fixes a few minor bugs.

msmtp 1.8.4 is released

2019-04-24

This version adds support for the OAUTHBEARER authentication method and fixes a few minor bugs.

Support for OAUTHBEARER / XOAUTH2

2019-04-06

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!

Source code moved

2019-02-19

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.

msmtp 1.8.3 is released

2019-02-11

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).

msmtp 1.8.2 is released

2019-01-12

This version simplifies configuration:

• A new --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).
• You now only need tls on to activate TLS because there is a new default value for tls_trust_file that selects the system default trust.

msmtp 1.8.1 is released

2018-12-08

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.

msmtp 1.8.0 is released

2018-09-04

This is the first release of the new stable release series. Noteworthy changes since 1.6.8:

• A minimal SMTP server called msmtpd was added that listens on the local host and pipes mails to msmtp (or another program). It is intended to be used with system services that cannot be configured to call msmtp directly. You can disable it with the configure option --without-msmtpd.
• Using OpenSSL is discouraged and may not be supported in the future. Please use GnuTLS instead. The reasons are explained here.
• As using GNU SASL is most likely unnecessary, it is disabled by default now. Since everything uses TLS nowadays and thus can use PLAIN authentication, you really only need it for GSSAPI.
• If your system requires a library for IDN support, libidn2 is now used instead of the older libidn.
• The CRAM-MD5 authentication method is marked as obsolete / insecure and will not be chosen automatically anymore.
• The passwordeval command does not require the password to be terminated by a new line character anymore.
• The new logfile_time_format command allows to customize log file time stamps.
• Builtin default port numbers are now used instead of consulting /etc/services.
• Support for DJGPP and for systems lacking vasprintf(), mkstemp(), or tmpfile() is removed.

msmtp 1.8.0rc1 is released

2018-08-20

This is a release candidate for the upcoming 1.8.x stable release series. The following changes were made:

• A minimal SMTP server called msmtpd was added that listens on the local host and pipes mails to msmtp (or another program). It is intended to be used with system services that cannot be configured to call msmtp directly. You can disable it with the configure option --without-msmtpd.
• Using OpenSSL is discouraged and may not be supported in the future. Please use GnuTLS instead. The reasons are explained here.
• As using GNU SASL is most likely unnecessary, it is disabled by default now. Since everything uses TLS nowadays and thus can use PLAIN authentication, you really only need it for GSSAPI.
• The CRAM-MD5 authentication method is marked as obsolete / insecure and will not be chosen automatically anymore.
• If your system requires a library for IDN support, libidn2 is now used instead of the older libidn.
• Builtin default port numbers are now used instead of consulting /etc/services.
• Support for DJGPP and for systems lacking mkstemp() or tmpfile() is removed.

Using msmtp with OpenSSL is discouraged, please use GnuTLS

2018-08-19

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:

• With OpenSSL, we need to write our own functions to verify host names and convert ASN1 times to 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.
• Just initializing the library is a complex topic. The OpenSSL wiki has a 1800 word long Wiki page on library initialization. Again, this is insane. If any explicit initialization is required at all, it should be done with one single simple function call.
• We have a function in msmtp that does nothing but try to find out why an OpenSSL input/output error occurred. It has 50 lines of code and has to consult three different error codes from various parts of the OpenSSL API to do just that. Insane.

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.

New experimental feature: msmtpd, a minimal SMTP server

2018-08-14

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.

msmtp 1.6.8 is released

2018-06-28

New in this release:

• Support for TLS Server Name Indication (SNI)
• Support for binding the outgoing connection to a source IP, using the new --source-ip option or source_ip command

msmtp 1.6.7 is released

2018-06-15

New in this release:

• Support for ~/.config/msmtp/config as configuration file
• Network timeout handling on Windows
• Fixed command line handling of SHA256 TLS fingerprints
• Fixed SIGPIPE handling (affects at least Mac OS X)
• Add french translation, and update german translation

Repository mirror

2018-06-14

The main git repository at gitlab.marlam.de/marlam/msmtp is now mirrored at github.com/marlam/msmtp-mirror.

Project moved

2018-06-12

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.