jstedfast/MailKit · critical · AuthenticationException

The LOGIN command is disabled.

Error message

The LOGIN command is disabled.

What it means

MailKit throws this AuthenticationException when the server advertises LOGINDISABLED, meaning the classic LOGIN command is disabled — typically because the server only permits authentication over a secure (TLS) connection or has disabled plaintext login entirely. CheckCanLogin raises it before the LOGIN command is sent when no suitable SASL mechanism was used.

Solutions

  1. Connect with TLS: use SecureSocketOptions.SslOnConnect or StartTls (and port 993), which usually re-enables LOGIN
  2. Use a SASL mechanism (e.g. Authenticate with a SaslMechanism like XOAUTH2 or CRAM-MD5) instead of relying on the LOGIN fallback
  3. Check (client.Capabilities & ImapCapabilities.LoginDisabled) after Connect and switch strategy before authenticating
  4. Enable SMTP/IMAP basic-auth or app passwords on the account if the provider recently disabled LOGIN

Example fix

// before
client.Connect (host, 143, SecureSocketOptions.None);
client.Authenticate (user, pass); // LOGIN disabled -> AuthenticationException
// after
client.Connect (host, 993, SecureSocketOptions.SslOnConnect);
client.Authenticate (user, pass);
Defensive patterns

Strategy: fallback

Validate before calling

if ((client.Capabilities & ImapCapabilities.LoginDisabled) != 0) throw new InvalidOperationException ("Server requires TLS/SASL; plaintext LOGIN disabled");

Type guard

bool CanLogin (ImapClient c) => (c.Capabilities & ImapCapabilities.LoginDisabled) == 0;

Try / catch

try { client.Authenticate (user, pass); } catch (AuthenticationException ex) when (ex.Message.Contains ("LOGIN command is disabled")) { // reconnect with TLS or use SASL mechanism
}

Prevention

When it happens

Trigger: Authenticating via the plaintext LOGIN fallback while (Capabilities & ImapCapabilities.LoginDisabled) != 0 — e.g. connecting on port 143 without TLS, or passing a credential set that forces LOGIN instead of a SASL mechanism.

Common situations: Connecting with SecureSocketOptions.None to a server requiring TLS; Gmail/Office365 disabling basic auth/LOGIN; credentials retrieved via ICredentials that have no SASL-compatible mechanism so MailKit falls back to LOGIN.

Related errors


AI-assisted analysis of jstedfast/MailKit@9d3859a785 (2026-09-15). Data as JSON: /api/errors/49335b4bb3cf4311. Report an issue: GitHub.

Appendix: source

Thrown at MailKit/Net/Imap/ImapClient.cs:1213

		{
			if (encoding == null)
				throw new ArgumentNullException (nameof (encoding));

			if (credentials == null)
				throw new ArgumentNullException (nameof (credentials));

			CheckDisposed ();
			CheckConnected ();

			if (engine.State >= ImapEngineState.Authenticated)
				throw new InvalidOperationException ("The ImapClient is already authenticated.");
		}

		void CheckCanLogin (ImapCommand? ic)
		{
			if ((Capabilities & ImapCapabilities.LoginDisabled) != 0) {
				if (ic == null)
					throw new AuthenticationException ("The LOGIN command is disabled.");

				throw CreateAuthenticationException (ic);
			}
		}

		/// <summary>
		/// Authenticate using the supplied credentials.
		/// </summary>
		/// <remarks>
		/// <para>Authenticates using the supplied credentials.</para>
		/// <para>If the IMAP server supports one or more SASL authentication mechanisms,
		/// then the SASL mechanisms that both the client and server support (not including
		/// any OAUTH mechanisms) are tried in order of greatest security to weakest security.
		/// Once a SASL authentication mechanism is found that both client and server support,
		/// the credentials are used to authenticate.</para>
		/// <para>If the server does not support SASL or if no common SASL mechanisms
		/// can be found, then LOGIN command is used as a fallback.</para>
		/// <note type="tip">To prevent the usage of certain authentication mechanisms,

View on GitHub (pinned to 9d3859a785)