Mutt compiled with SASL suddenly not working

[Russ Urquhart]

I’ve been using mutt for sometime now (1.5.23). Compiled with SASL it has worked with out issue. A couple of weeks ago I ended my contract with Verison/Frontier/AOL and was concerned that my ***@verizon.net email address would no longer work. I started to see this sporadic working of the SASL component of mutt, and I started to take apart my mutter file. As I WAS able to get the Mail app on my OS X laptop to work with my email address, I surmised that everything must be ok, I put my muttrc back to the way it was, and things worked fine. Until about now. :(

Here what is happening after I load mutt and do a Shift-g to load new mail:

1. Certificate Host failed:
Then it offers me to reject, accept once, or accept always. I take the always.

2. then it tries authenticating SASL (this seems to take a while, Then:
SASL authentication failed.

3. It goes to Logging in…
for a long time until it comes back with:
Login failed: PASS: [SYS/TEMP] Server error - Please try again later

I think my incoming and outgoing mail servers are ok. They are the ones and same credentials that I use for the OS X Mail app (which is working) and my iphone. Is there something on the SASL authentication?

Here are some specifics from my muttrc file:

set smtp_authenticators="external:anonymous:plain:otp:skey:digest-md5:scram:ntlm:gssapi:browserid-aes128:eap-aes128”

This is a pop access to the mail servers.

Can anyone shed any light on this? Please help don’t want to stay in Mail app!! :)



Thanks,


Russ

[Kevin J. McCarthy]

I’ve been using mutt for sometime now (1.5.23). Compiled with SASL it
has worked with out issue.

Are you still using 1.5.23? It might be worth trying the most recent
version. There have been a couple fixes to SASL in the 1.7 and 1.8
releases that might (or might not) affect you.

set smtp_authenticators="external:anonymous:plain:otp:skey:digest-md5:scram:ntlm:gssapi:browserid-aes128:eap-aes128”

Is there any particular reason for this list, and the order it occurs
in? For example, you are listing "external" first, which is not an
ordinary authentication mechanism. This is followed by "anonymous",
which doesn't seem to be a likely method you'd want to use. "otp" also
seems highly unlikely...

If this is "always the way it's been", you might want to try commenting
that line out and seeing if it just works.

[Russ Urquhart]

Hi Kevin,

Post by Kevin J. McCarthy

Post by Russ Urquhart
I’ve been using mutt for sometime now (1.5.23). Compiled with SASL it
has worked with out issue.

Are you still using 1.5.23? It might be worth trying the most recent
version. There have been a couple fixes to SASL in the 1.7 and 1.8
releases that might (or might not) affect you.

I might, but like I said, it WAS working ok, up until a few days ago. I compiled mutt back then, if it compiles cleanly for those versions I might. If not I was thinking of using the macports of Neomutt.

Post by Kevin J. McCarthy

Post by Russ Urquhart
set smtp_authenticators="external:anonymous:plain:otp:skey:digest-md5:scram:ntlm:gssapi:browserid-aes128:eap-aes128”

Is there any particular reason for this list, and the order it occurs
in? For example, you are listing "external" first, which is not an
ordinary authentication mechanism. This is followed by "anonymous",
which doesn't seem to be a likely method you'd want to use. "otp" also
seems highly unlikely...
If this is "always the way it's been", you might want to try commenting
that line out and seeing if it just works.

That correct. This was always the way it was, and it was working.

I tried commenting out this value. No change, unfortunately.

Thanks for your help. Any other ideas?

Thanks,

Russ