SMTP Service Cleartext Login Permitted: How to Fix Nessus 54582

SMTP Service Cleartext Login Permitted (Nessus plugin 54582) means your mail server offers SMTP AUTH with PLAIN or LOGIN before the connection is encrypted, so a client can send its password in cleartext. Fix it by advertising AUTH only after STARTTLS: smtpd_tls_auth_only = yes in Postfix, BasicAuthRequireTLS on Exchange receive connectors, or a TLS condition in Exim.

What the scanner is actually detecting

The scanner opens a plain connection to an SMTP port, sends EHLO and reads the advertised extensions. An AUTH line offering a plaintext mechanism before any STARTTLS exchange tells every client it may send a password unencrypted.

A typical EHLO reply that triggers it:

220 mail.example.com ESMTP
EHLO scanner.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
250-STARTTLS
250-AUTH PLAIN LOGIN
250 8BITMIME

Seeing STARTTLS in the same list does not help: offering encryption is not requiring it before login. Tenable’s solution reads: “Configure the service to support less secure authentication mechanisms only over an encrypted channel.” RFC 4954 agrees: sites should not permit plaintext password mechanisms without STARTTLS or similar protection against password snooping.

How serious is it, honestly

• It needs a network position. Someone must be able to read traffic between client and server: the same segment, a compromised router or Wi-Fi network, a mirrored switch port.
• It only leaks when a client logs in without TLS. Mail clients set to STARTTLS encrypt first. The real leaks come from devices and jobs configured with no encryption: scan-to-email printers, monitoring tools, old scripts.
• STARTTLS can be stripped. RFC 3207 describes an attacker deleting STARTTLS from the EHLO reply so the client never tries TLS. If the server still accepts plaintext AUTH, a client that does not insist on TLS hands over its password; otherwise the attack only produces a failed login.
• The credential is usually a real account. Exchange authenticates against Active Directory, and Postfix or Exim often share mailbox passwords with IMAP and webmail.

How to confirm it on the host

From the network

# List the EHLO extensions on a plaintext connection
nmap -p 25,587 --script smtp-commands mail.example.com

# Or check by hand
telnet mail.example.com 587
EHLO test.example.com
AUTH LOGIN
*
QUIT

If EHLO lists AUTH with PLAIN or LOGIN and AUTH LOGIN returns a 334 prompt, the finding is a true positive. The * line cancels the exchange (RFC 4954), so no credentials are sent. Test from the scanner’s network zone, because servers can advertise differently per client.

Postfix

postconf smtpd_sasl_auth_enable smtpd_tls_auth_only smtpd_tls_security_level
postconf -P | grep -E 'smtpd_(sasl_auth_enable|tls_auth_only|tls_security_level)'

The second command (Postfix 2.11 and later) shows master.cf overrides, which take precedence for that listener. The problem pattern is smtpd_sasl_auth_enable = yes, smtpd_tls_auth_only = no (the default) and a security level of may or empty.

Exchange Server

Get-ReceiveConnector | Format-Table Identity,Bindings,AuthMechanism -AutoSize -Wrap

Look for connectors with BasicAuth but not BasicAuthRequireTLS. For Exchange 2016, 2019 and Subscription Edition, Microsoft’s receive connector documentation lists the default Client Frontend (587) and Default Frontend (25) connectors with BasicAuthRequireTLS already set, so a hit usually means a custom connector, such as an application relay where only Basic authentication was ticked.

Exim

exim -bP auth_advertise_hosts    # the binary is exim4 on Debian and Ubuntu

The default is *, which advertises AUTH to every host whether or not the session is encrypted. Also check each authenticator for a server_advertise_condition.

Sendmail

grep -i AuthOptions /etc/mail/sendmail.cf

Without the p flag, sendmail does not hold back PLAIN and LOGIN until a security layer such as STARTTLS is active.

How to fix it

Postfix

cp -p /etc/postfix/main.cf /etc/postfix/main.cf.bak
postconf -e 'smtpd_tls_auth_only = yes'
postfix check
postfix reload

smtpd_tls_auth_only (Postfix 2.2 and later) stops Postfix from announcing or accepting SASL authentication over unencrypted connections when TLS is optional. Server-to-server delivery does not use AUTH, so it is unaffected. TLS has to work first: without a usable certificate, AUTH is never offered.

A cleaner layout keeps SASL off on port 25 and enables it only on the submission port with mandatory TLS. Move any clients that authenticate on port 25 to 587 first. Postfix documents that smtpd_tls_security_level = encrypt implies smtpd_tls_auth_only = yes, and that encrypt must not be used on a publicly referenced server, only on dedicated services such as port 587:

# /etc/postfix/main.cf
smtpd_sasl_auth_enable = no

# /etc/postfix/master.cf
submission inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes

Keep any other -o lines your submission entry already has, such as relay restrictions, and look for services that set -o smtpd_tls_auth_only=no, since master.cf overrides beat main.cf.

Exchange Server

# Record the current value first, for rollback
Get-ReceiveConnector "EXCH01App Relay" | Format-List Identity,AuthMechanism

Set-ReceiveConnector -Identity "EXCH01App Relay" -AuthMechanism Tls,BasicAuth,BasicAuthRequireTLS,Integrated

AuthMechanism replaces the whole value, so carry over anything else the connector had, such as ExchangeServer. Microsoft documents that BasicAuthRequireTLS also requires BasicAuth and Tls. In the Exchange admin center, open the connector under Mail flow > Receive connectors, go to the Security tab and tick Offer basic authentication only after starting TLS. TLS needs a certificate that includes the name the connector advertises in its EHLO response.

Port 2525 is the backend Default connector between Exchange transport services. Microsoft lists it without BasicAuthRequireTLS and says clients do not connect to it directly, so restricting who can reach 2525 is safer than editing it untested.

Exim

# Main section of the Exim configuration (before the first "begin" line)
auth_advertise_hosts = ${if eq{$tls_in_cipher}{}{}{*}}

This is the setting the Exim specification gives for advertising AUTH only on encrypted connections: when $tls_in_cipher is empty, the expansion matches no hosts, and Exim rejects AUTH from clients it did not advertise it to. exim -bV syntax-checks the file but cannot test expanded values, so restart and test a real session. To hold back only PLAIN and LOGIN, set server_advertise_condition = ${if eq{$tls_in_cipher}{}{no}{yes}} on those authenticators instead.

Sendmail

# sendmail.cf
O AuthOptions=p,y

# or in the .mc file, then regenerate sendmail.cf
define(`confAUTH_OPTIONS', `p,y')dnl

The p flag disallows mechanisms susceptible to simple passive attack, such as PLAIN and LOGIN, unless a security layer like STARTTLS is already active. The y flag also disallows anonymous login. Restart sendmail after regenerating the configuration.

Verify the fix and rescan

# Plaintext EHLO must no longer offer PLAIN or LOGIN
nmap -p 25,587 --script smtp-commands mail.example.com

# After STARTTLS, AUTH must still be offered where clients need it
openssl s_client -connect mail.example.com:587 -starttls smtp -crlf -quiet
EHLO test.example.com
QUIT

In a plaintext telnet session, AUTH LOGIN should now return a 5xx error instead of 334. On Exchange, NTLM from Integrated authentication may still be listed before STARTTLS; what must disappear is PLAIN and LOGIN. Send a test message from a real client configured for STARTTLS, then rescan with the same Nessus policy. Plugin 54582 is a remote check and needs no host credentials.

What can break and how to roll back

• Clients that authenticate without encryption. Printers, monitoring tools and scripts set to “no encryption” will fail to authenticate. Beforehand, search the Postfix mail log for sasl_username and compare those clients with TLS handshake lines (smtpd_tls_loglevel = 1 or higher). On Exchange, enable protocol logging on the connector with Set-ReceiveConnector -ProtocolLoggingLevel Verbose for a few days.
• Certificate problems. A broken or expired certificate now takes authenticated submission down with it, because AUTH is only offered after a successful STARTTLS. Keep mail certificates in your TLS certificate inventory.
• Devices that cannot do TLS at all. A separate listener or connector limited to that device’s IP address is better than reopening cleartext AUTH for every client. Track it through your vulnerability risk acceptance process with an owner and a review date.

To roll back: on Postfix, restore main.cf.bak (or run postconf -e ‘smtpd_tls_auth_only = no’) and postfix reload. On Exchange, rerun Set-ReceiveConnector with the AuthMechanism value you recorded. On Exim or sendmail, remove the line or flag you added and restart.

Common false positive reasons

• “Must issue STARTTLS first” is not a pass. Some servers advertise AUTH before TLS but answer MAIL FROM with a 530 reply. In a Greenbone community thread about exactly this output, the Greenbone reply pointed out that the session was still in cleartext and showed a correct server advertising STARTTLS with no AUTH until TLS started. Treat it as a true positive.
• Different listener for different source IPs. Exchange uses the receive connector with the most specific remote IP match, and Postfix and Exim can advertise AUTH per client network. Your admin VLAN test may hit a different connector than the scanner did.
• Another port, or change not live. Fixing 587 leaves the finding open if port 25 still offers plaintext AUTH (check the port in the plugin output). Also confirm Postfix was reloaded, Exim restarted and no master.cf override remains.
• Wrong asset. An email gateway, load balancer or NAT rule owns that address. More patterns: common causes of vulnerability scanner false positives.

FAQ

Does offering STARTTLS close Nessus 54582?

No. The server must stop advertising PLAIN and LOGIN until TLS is active; STARTTLS next to plaintext AUTH is exactly what the plugin reports.

Will smtpd_tls_auth_only break inbound internet mail?

No. It only affects SASL authentication, and other mail servers deliver to your MX without AUTH. Do not set smtpd_tls_security_level = encrypt on a public MX, though; Postfix says that level must not be used there.

Is port 465 affected?

Usually not. RFC 8314 defines port 465 (submissions) as implicit TLS: the handshake starts before any SMTP command, so AUTH is never offered in cleartext. Exchange differs: its port 465 is the backend Client Proxy connector, which uses STARTTLS and has BasicAuthRequireTLS by default.

Is disabling PLAIN and LOGIN before TLS enough?

It matches Tenable’s wording (in Postfix: smtpd_sasl_security_options = noanonymous, noplaintext plus smtpd_sasl_tls_security_options = noanonymous). Other mechanisms stay advertised before TLS, and some scanners flag any pre-TLS AUTH, so smtpd_tls_auth_only is simpler.

Tracking this finding across many hosts

This finding often shows up on relays, application servers and appliances at once. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results by uploading a .nessus export) and merges duplicates within each scanner, not across them, so Nessus and OpenVAS entries stay separate. Nessus findings such as plugin 54582 can be re-tested one at a time after the change, and AI-drafted, host-specific fix scripts reach Windows and Linux agents only after a person approves them.

Sources

• Tenable: SMTP Service Cleartext Login Permitted (plugin 54582)
• Postfix: postconf(5) configuration parameters
• Microsoft Learn: Set-ReceiveConnector
• Exim specification: main configuration (auth_advertise_hosts)
• RFC 4954: SMTP Service Extension for Authentication