Hi Simon! On Wed, 21 Jan 2015 15:28:17 +0100, Simon Josefsson wrote: > That's true for CRAM-MD5, but not for SCRAM-SHA1. SCRAM-SHA1 allows > the server to only store a hash, so it is nice. However, that makes > it harder to in the future migrate to another mechanism which uses > another hash. I would say SCRAM-SHA1 is still better than CRAM-MD5, > DIGEST-MD5, and PLAIN though. Thanks for this information! I got that wrong. > > For the special case of authentication via TLS client certificates, > > method EXTERNAL may be used. > > Yep. Alas, it is a bit underspecified whether EXTERNAL means > TLS-and-client-certs or something else. You need to out-of-band > policy agreement about this between client and server. Yes, and sometimes TLS-with-client-certs is used but a confirmation via EXTERNAL is not supported. > > These three methods are really the only useful ones now, as far as I > > can see. > > GSSAPI and GS2-KRB5 are useful for Kerberos people. Yes, but I have never encountered these Kerberos people ;) Do you know in which scenarios Kerberos is actually being used? > There ought to be some checks to make sure GSSAPI/GS2 isn't selected > if it is likely that it won't succeed (e.g., no Kerberos tickets > available). I thought GNU SASL checked that, but I'm not confident. Probably GNU SASL checks this. Msmtp does not use gsasl_client_suggest_mechanism(), but chooses the method itself. I did some digging to find out why. Currently a comment reads "TODO: use gsasl_client_suggest_mechanism()?". In msmtp-1.2.2 (more than ten years ago) that comment read "Do not use gsasl_client_suggest_mechanism() because it seems to always return ANONYMOUS (libgsasl 0.0.7)". I guess that problem was solved in the meantime... Thanks for your work on all the essential libraries that msmtp depends on! Regards, Martin
Attachment:
pgpmLZauAcTRk.pgp
Description: OpenPGP digital signature