I have lately been trying to use the smtp server offered by BT Internet, which seems to defeat the authentication of nmh post. Sundry other muas are fine, including claws and various smartphone apps (ugh). The tale has been slightly round-about, but I will try my best to cut to the core and be succinct.
For starters, here is a cut/paste from a terminal window, with a few cuts and edits for brevity and clarity and a few explanatory comments, all denoted by []: [Attempting to send via the front door, as it were,] [but making as many parameters as possible explicit for clarity.] [There is also a .netrc file which of course I am not displaying.] send -mts smtp -initialtls -server mail.btinternet.com -port 465 \ -sasl -saslmech PLAIN -user [email protected] \ -verbose -snoop ~/.mh_dir/drafts/1 -- Posting for All Recipients -- Trying to connect to "mail.btinternet.com" ... Connecting to 213.120.69.4:465... TLS negotiation successful: ECDHE-RSA-AES128-GCM-SHA256(128) TLSv1.2 [ok, the TLS session is up and running and self-evidently working.] [TLS detail snipped.] {tls-decrypted) <= 220 sa-prd-rgout-004.btmx-prd.synchronoss.net ESMTP Service ready (tls-encrypted) => EHLO bryher.nodomain (tls-decrypted) <= 250-sa-prd-rgout-004.btmx-prd.synchronoss.net (tls-decrypted) <= 250-DSN (tls-decrypted) <= 250-8BITMIME (tls-decrypted) <= 250-PIPELINING (tls-decrypted) <= 250-AUTH=LOGIN [Huh? See below.] (tls-decrypted) <= 250-AUTH LOGIN PLAIN [as more in line with expectation] (tls-decrypted) <= 250-DELIVERBY 300 (tls-decrypted) <= 250 SIZE 41943040 [post immediately gives up, but the diagnostic follows below] (tls-encrypted) => RSET (tls-decrypted) <= 250 RSET (tls-encrypted) => QUIT (tls-decrypted) <= 221 sa-prd-rgout-004.btmx-prd.synchronoss.net QUIT [and the conclusion issued by post -] post: problem initializing server; [BHST] Chosen mechanism PLAIN not supported by server send: message not delivered to anyone So the nub of the matter is that PLAIN authentication clearly is being offered by the server, but post doesn't recognise that it is. What we do see is the mysterious "250-AUTH=LOGIN" from the server, immediately prior to the more understandable "250-AUTH LOGIN PLAIN". Peering in with gdb (in a separate but equivalent experiment) I can see that when netsec_negotiate_sasl (in netsec.c) is checking whether PLAIN is in the list offered by the server, that list (supposedly now in mechlist) contains the sole entry "=LOGIN", which of course is none of the mechanisms (LOGIN & PLAIN) that was actually offered, one of which (duly in nsc->sasl_mech) is the unremarkable one we are looking for. Post of course forthwith issues the failure. Without following the detail, it seems clear that post is reading "250-AUTH=LOGIN" as "250-AUTH LOGIN", and (perhaps correctly?) rejecting any subsequent "250-AUTH", including the "right" one. So what then is that mysterious "250-AUTH=LOGIN" construct? I have searched the standards and so far found no clue, but I am certainly no expert in this area. It looks as though it might be indicating a preference, but that's just a guess. Where is it in fact documented? And what should be done when something like "250-AUTH=LOGIN" actually is received in this context? Whatever that may, my thought is that post isn't doing it. Other muas, in particular claws-mail and sundry smartphone apps, do however seem to take it in their stride, whatever they do do. I am desultorily taking claws-mail to pieces to see what that does, but don't hold your breath. Yes, I have tried "-saslmech LOGIN" and simply omitting -saslmech, but the outcome is the same and having seen the logic of the code I can't see how it could alter that early stage rejection anyway. I am using nmh-1.7.1 taken from the Debian "bookworm" (the current "testing") distribution. Initially, and in the session recorded above, I was using the normal binary deb, but for experimenting under gdb I obviously needed an unstripped version so I got the source deb, unpacked nmh_1.7.1.orig.tar.gz and built it using "LDADD=-Bstatic ./configure --with-cyrus-sasl --with-tls --prefix=`pwd`/testdir". Can anyone help? Perhaps I'm missing something blindingly obvious and well-known, but I have at least searched the archives and faqs. If I have indeed missed a trick I will be delighted to be told, however embarrassing it may be, since it will save me wasting yet more time on something that is from my point of view a diversion. TIA Tony -- Tony Stoneley Preferred email address [email protected] ...not withstanding anything any ISP may force into my "From:" field
