Mutt Says "No Authenticators Available" on Termux

Decision: prove a usable mechanism before changing a password

No authenticators available

No usable mechanism was selected. Check the local SASL feature, plugin files and dependencies, the server's AUTH advertisement after TLS, and any forced authenticator list.

SASL authentication failed

A mechanism was selected and attempted, so move to the username, app-password or OAuth policy, and the exact bounded server reply.

Message accepted

Authentication is no longer the failing boundary. Preserve the SMTP response and follow provider and recipient delivery evidence.

What the current Termux recipes prove

At Termux Mutt recipe revision 95ba7f4a806bb363e0d9b4cb3f63484a94631c81, Mutt 2.4.1 depends on libsasl and is configured with --enable-debug, --enable-smtp, --with-sasl, and --with-ssl. The recipe therefore does not support a blanket conclusion that Termux compiled SMTP or SASL out.

At libsasl recipe revision ce7bd64f2cf6145ca67a78997c2ba953d7d89320, plugins are installed under $PREFIX/lib/sasl2, LOGIN is enabled, and the package build is gated on the expected shared-object files. That gate proves file creation, not whether each plugin's runtime libraries will be installed on a user's device.

In the current issue, the reporter has now shown +USE_SASL, both plugin files present, post-TLS AUTH PLAIN LOGIN, an unset automatic authenticator policy, and no attempted-method line before the same error. That evidence narrows the next safe check to plugin loadability; it does not justify changing or exposing the password.

A historical Termux report produced the same message when libplain.so was absent at runtime. The package was repaired and a plugin-presence build gate was added. That history makes package integrity a useful first check; it is not proof that every current report has the same cause.

Run the bounded local checks

These commands report feature, package, file-presence, and dependency-presence evidence. They do not print a mail password:

mutt -v 2>&1 | grep -E '[+-]USE_(SASL|GSASL)'
apt-cache policy mutt libsasl libcrypt
dpkg -V mutt libsasl

for plugin in libplain.so liblogin.so; do
  test -r "$PREFIX/lib/sasl2/$plugin" \
    && echo "$plugin present" \
    || echo "$plugin missing"
done

test -r "$PREFIX/lib/libcrypt.so" \
  && echo "libcrypt.so present" \
  || echo "libcrypt.so missing"

mutt -Q smtp_authenticators

If and only if that check prints libcrypt.so missing, install the official dependency with pkg install libcrypt, repeat the same check, and rerun one controlled Mutt attempt. The package-level repair is to declare libcrypt as a libsasl dependency and bump the package revision.

If libcrypt.so is already present but no method is attempted, keep the full log local and inspect only bounded loader evidence:

for plugin in libplain.so liblogin.so; do
  ldd "$PREFIX/lib/sasl2/$plugin" 2>&1 | grep -E 'libcrypt|not found'
done

grep -E 'SASL:|sasl_client_start|No worthy mechs|No authenticators available' \
  "$HOME/.muttdebug0"

An empty smtp_authenticators value is intentional: Mutt's documented default is to try the mechanisms available to both the client and server. A forced list is useful only when it names a mechanism the server actually advertises.

Inspect the post-TLS capability list

For STARTTLS, Mutt sends EHLO again after TLS specifically to obtain the authentication mechanisms. The relevant capability is the post-TLS 250-AUTH line, not a pre-TLS line and not a provider's generic setup page.

mutt -d 2

# Inspect locally after the controlled attempt:
grep -E '250[- ]AUTH|smtp_authenticate: Trying method| unavailable|SASL authentication failed' \
  "$HOME/.muttdebug0"

Do not publish the full log. It can contain account, host, message, and protocol data. A safe issue update needs only: SASL feature present or absent, PLAIN/LOGIN plugin present or absent, libcrypt.so present or missing, bounded loader messages, post-TLS AUTH mechanism names, whether smtp_authenticators is unset or intersects that list, and the final bounded outcome.

Classify the first evidenced boundary

SASL feature absent

Verify the actual Termux repository and installed Mutt package. Do not repair this by changing a provider password.

PLAIN or LOGIN plugin absent

Refresh package metadata, reinstall the official libsasl package, and rerun package verification before another send.

Plugin present, libcrypt absent

Install the official libcrypt package, prove the library is readable, and repeat the same attempt. Do not download a standalone shared object.

Plugin and libcrypt present, still no method

Inspect local ldd output and only the bounded SASL loader lines before moving to server or credential policy.

No AUTH after TLS

Confirm the SMTP endpoint, port, TLS mode, and whether that provider enables SMTP AUTH for the account. The client has no server mechanism to choose.

Forced list has no intersection

For one controlled test, leave smtp_authenticators unset so Mutt can intersect its available mechanisms with the server list.

Mechanism attempted, then 53x

The selection stage passed. Follow the provider's current credential policy, account state, app-password or OAuth requirement, and exact reply.

Keep Gmail account policy separate

Google no longer supports ordinary account-password sharing for third-party mail clients. Its current guidance prefers Sign in with Google; where a client cannot use that flow, an app password may be available only for eligible accounts with 2-Step Verification. A Google 534 5.7.90 or 535 5.7.80 reply belongs to this later credential-policy stage, not to the earlier "No authenticators available" stage.

Other providers can expose different mechanisms and account controls. Use their current documentation only after the local runtime and the post-TLS AUTH list identify what the client can actually attempt.

Evidence required before calling it fixed

1. mutt -v reports a SASL feature and the installed package versions are known.
2. The required local plugin file is readable and dpkg -V reports no unexplained package-integrity failure.
3. libcrypt.so is readable and the PLAIN or LOGIN plugin has no unresolved runtime dependency.
4. The post-TLS EHLO advertises at least one mechanism the client can use.
5. smtp_authenticators is unset or intersects that server list.
6. A controlled attempt advances beyond mechanism selection and receives either a bounded credential reply or successful message acceptance.
7. If accepted, the SMTP response, provider event, recipient-server outcome, and mailbox visibility remain separate evidence.