The other thing I would hope for is wildcard certificates. I stopped using S/MIME because I usually create a new email (based on the same domain) for each vendor that I deal with. I would find it useful to be able to get a single certificate covering all email with that domain. Obviously that does mean that anyone else using an email from that domain would have to share the certificate, but for private use that can be acceptable - I don't worry about my wife reading my currently unencrypted email!

If Lets encrypt sets up an automated system then MUAs could automatically request certificates for you. So the user wouldn’t have to deal with the issue.

There may be a need to distribute your certificate if you read and write mail on multiple devices.

Maybe with a local passkey on device ?

S/MIME is about the mail (content) itself, not the transport. For the transport part there are things like (START)TLS and MTA-STS. With S/MIME you include your certificate in the mail and can either sign the mail with a signature (with your private key, others can verify it using your public key from the certificate) or encrypt the mail (with the receiver's public key, so only he can decrypt it using his private key). Certificate trust is determined normally via the CA chain and trusted CAs.

Oof, I don’t like this article much at all.

The first two major points they pose against email can be summed up as ‘people don’t use security unless it is by default, and because it wasn’t built-in to email we shouldn’t try.’ To which I respond with: perfect is the enemy of progress. Clearly, email is sticky (many other things have tried to replace it), and it has grown to do more than just send plaintext messages. People use it for document transfer, agreements, as a way to send commands over the internet, etc. Email encryption and authentication is simply an attempt to add some cryptographic tooling to a tool we already use for so many things. Thus, these points feel vacuous to me.

The last two points are less to do with email and more to do with encryption in general, and it is probably the most defeatist implication of the fact that there is no ‘permanent encryption.’ It is an argument against encryption as a whole, and paints the picture for me that the author would find other reasons to dislike email encryption because they already dislike encryption. These last two points are an extension of wanting an ideal solution and refusing to settle for anything less.

I disagree. Email is not going away so not encrypting it at all is by far the worst option. Don‘t let perfection be the enemy of good.