Allow manual selection of supported authentication methods

[cketti]

Right now we offer the options "Normal password", "Encrypted password" and "Client certificate" during setup. Using a client certificate should complement the password authentication and thus be a separate setting (see #793). That leaves us with "Normal password" and "Encrypted password", which are not terribly useful options. In my opinion the default should be "Automatic" where we select the option we like best and use that. Additionally, we list the individual authentication methods we support. That would allow users to override the automatic behavior in case it doesn't work.

For additional information see issue #2648

[mhoran]

@cketti would it still be possible to use only client certificate authentication (no password) with the proposed change? There has been some work in Postfix to make the user case I described in #793 possible. This would make Postfix compatible with AUTH EXTERNAL as implemented in K9 today. I don't have the desire to use both a password AND certificate auth once this is the case.

[cketti]

Sure, AUTH EXTERNAL is a supported authentication mechanism.

[Fellhahn]

Just commenting to add my support for client certificate + password as an authentication method. (Is PEAP the correct term to describe this?)

I came here intending to submit this as a feature request. My current mail server back-end (Axigen) does not support the auth external method, but does support securing a connection with a client certificate before password exchange.

Perhaps a tick box could be added for "Use client certificate", which triggers the certificate selection prompt.

Following from that, where "Client certificate" is currently present in the authentication select list, it could be replaced by an "AUTH External" selection?

This way providing support for people that only want to use a certificate, as well as those that want to use certificate + password.

[anarcat]

I came here intending to submit this as a feature request. My current mail server back-end (Axigen) does not support the auth external method, but does support securing a connection with a client certificate before password exchange.

I have the same problem here: from my point of view, K9/thunderbird doesn't actually support client cert authentication for SMTP in any meaningful way because (a) it doesn't actually prompt for a password when client cert authentication is enabled for SMTP and (b) it then proceeds to require AUTH EXTERNAL to be provided on EHLO from the SMTP server, which is kind of nonsense: either you authenticate (in which case you need a password) or you don't (and then you don't ask for a password).

Related conversations on the server side:

• https://www.dovecot.org/list/dovecot/2017-February/106884.html
• https://marc.info/?l=postfix-users&m=155294562123736

neither which seems to have led anywhere. the latter, in particular, is a patch that specifically works around this by "faking" the AUTH EXTERNAL specifically to satisfy k9/TB, that doesn't seem right to me...

[eehakkin]

I have the same problem here: from my point of view, K9/thunderbird doesn't actually support client cert authentication for SMTP in any meaningful way

Yes, it does.

because (a) it doesn't actually prompt for a password when client cert authentication is enabled for SMTP and (b) it then proceeds to require AUTH EXTERNAL to be provided on EHLO from the SMTP server, which is kind of nonsense: either you authenticate (in which case you need a password) or you don't (and then you don't ask for a password).

That is very much on purpose. In K9/Thunderbird, Client certificate authentication means AUTH EXTERNAL authentication, which is an authentication method (you authenticate that you are the holder of the client certificate) and which does not ask or use a login password. So it works correctly.

But you, @anarcat, do not want that. You want client certificate + password authentication. In K9/Thunderbird, in order to enable that, one has to:

1. select a Normal password (or Encrypted password) authentication,
2. fill in a username and a password, and
3. select a client certificate.

This authentication method has been available since 2021 or so (see #793). It works.

---

This issue, on the other hand, if think, is not about client certificate authentication (which works) but more about different password authentication schemas and how they are presented in the account settings.

[anarcat]

But you, @anarcat, do not want that. You want client certificate + password authentication. In K9/Thunderbird, in order to enable that, one has to:

You, @eehakkin, are incorrect: i do not want password-based authentication. I want client cert only authentication. I thought I made that pretty clear above.

That is very much on purpose. In K9/Thunderbird, Client certificate authentication means AUTH EXTERNAL authentication, which is an authentication method (you authenticate that you are the holder of the client certificate) and which does not ask or use a login password. So it works correctly.

Well then, there's a disagreement between thunderbird and Postfix about how this should work, because Postfix doesn't advertise AUTH EXTERNAL even when it's (correctly, IMHO) configured to accept only TLS-based authentication. I thought I made that pretty clear above, but it seems this crucial bit of information was lost along the way.

Now, maybe someone here could make a hard claim that the SMTP server MUST announce AUTH EXTERNAL in such situations and that, in this case, Postfix is at fault. I'd be happy to collect my marbles here and start up the hill on the other side to see if we can fix that in Postfix. But so far this issue here led me to believe this is also an issue in TB.