Msmtp: About Authentication Methods

There is value in using PLAIN inside of TLS instead of SCRAM-* methods. If you use SCRAM-, you're committing your password storage to only* use that method for storing the plaintext. So if you were state-of-the-art 20 years ago and used CRAM-MD5, and then you wanted to upgrade to SCRAM-SHA-1 when that came out... you don't have a good migration story, since the password storage has the information needed to validate CRAM-MD5 but not SCRAM-SHA-1, and there's no way to regenerate the information for SCRAM-SHA-1 without the plaintext password.

But if the authentication server gets the plaintext password, it can validate it against the old CRAM-MD5 storage, see that it matches, and then update the storage to SCRAM-SHA-1 on the fly. The entire process is invisible to the user, who gets a security upgrade in the process.

There's another class of use-cases, where a service needs to authenticate a user based on a token from another service. But for this, it's better to dispense with passwords entirely and instead go to something like Kerberos, where the authentication service gives you tokens in lieu of any password information.

Password based authentication is very bad news. We've known that for decades. It became the first resort anyway†. The RFC this author is complaining about (which is a decade old at this point) is just yet another way to use passwords. Stop it.

If you actually wanted to build one of these today you would not build one of those toy digest systems, you'd use a PAKE such as OPAQUE https://tools.ietf.org/html/draft-irtf-cfrg-opaque-01

But arguably instead of dedicating effort to trying to "fix" password authentication it's better to just do much less of it. On the web that means much more WebAuthn.

† This mistaken inversion happens a lot. When working on the British railways there is supposed to be an assessment of the safest practical method of performing the work. What used to be known as "red zone" working, where there are still trains using the railway while you work on it, is inherently dangerous and to be avoided. Red zone should be a last resort. But in practice what you will routinely find after a red zone accident is that they picked red zone not out of necessity but simply their planners had fallen into a habit of always justifying this unsafe practice rather than choose methods that might delay things, inconvenience workers or require purchasing equipment. It had become their first resort instead.

> Every organization, whether tiny or enormous, needs a members-only messaging service that cannot receive traffic from external or unapproved senders.

> Organizations that need to let certain members hear from the general public, or communicate with untrusted (perhaps anonymous) customers, may establish a separate service instance for that purpose.

Rather than throwing away all existing email clients and servers, couldn't this be achieved by configuring an inbound mail rule to drop all email from addresses that aren't in your address book (and from servers that don't support DKIM)?

It doesn't seem very meaningful to say "Users should only receive messages from approved senders, unless they need to receive messages from unapproved senders". Email is useful precisely because it doesn't have the extra step of requiring users to manually add an address to their address book before receiving a message from a new contact, such as a receipt from an online purchase.

That’s my conclusion too. It seems like SCRAM prevents complete security failure if TLS fails (rouge certificate)