SMTP Missing Support For STARTTLS is a Greenbone/OpenVAS finding raised when a mail server does not accept the STARTTLS command, so messages and logins on that port travel unencrypted. Fix it by installing a certificate and enabling STARTTLS: smtpd_tls_security_level = may in Postfix, Enable-ExchangeCertificate -Services SMTP on Exchange, or the TLS certificate options in Exim and Sendmail.
What the scanner is actually detecting
The Greenbone check runs against every port detected as SMTP (25 by default, also 587 or nonstandard ports). It sends EHLO, then STARTTLS whether or not EHLO advertised it. A reply starting with 220 counts as support. A 5xx error, or 454 (which RFC 3207 defines as TLS temporarily unavailable), raises the finding. Ports that speak TLS from the first byte, such as implicit TLS on 465, are skipped.
| Scanner | Finding title | What it means |
|---|---|---|
| Greenbone/OpenVAS (OID 1.3.6.1.4.1.25623.1.0.105091) | SSL/TLS: SMTP Missing Support For STARTTLS (older feeds: SMTP Missing Support For STARTTLS, family SMTP problems) | STARTTLS was refused on that port. The check carries CVSS 0.0, so it is listed at Log severity. |
| Nessus (plugin 42088, Info) | SMTP Service STARTTLS Command Support | The positive case: it reports that STARTTLS works. An SMTP port that Nessus scanned without reporting 42088 points to the same gap. |
The Greenbone result text is short:
The remote SMTP server does not support the 'STARTTLS' command.
Real-world risk
- Everything on that port is readable in transit. Headers, bodies, attachments and any SMTP AUTH credentials cross the network in cleartext, readable by anyone with a position on the path (same segment, a compromised router, a mirrored switch port).
- On an internet MX, inbound mail loses opportunistic encryption. If your domain publishes an MTA-STS policy, RFC 8461 requires senders to validate your MX certificate, so senders enforcing the policy will fail to deliver.
- It is not an exploitable bug. Greenbone scores it 0.0: nothing is broken, a protection is missing. Priority rises with what the port carries (authenticated submission, regulated data, untrusted networks).
- STARTTLS alone does not stop an active attacker. RFC 3207 notes that a man in the middle can delete the STARTTLS line from the EHLO reply. Enabling it defeats passive capture; clients that require TLS (or MTA-STS and DANE on the sending side) are what defeat stripping.
How to confirm it on the host
From the network
# Does EHLO list STARTTLS?
nmap -p 25,587 --script smtp-commands mail.example.com
# Try the upgrade; a certificate and handshake summary means STARTTLS works
openssl s_client -connect mail.example.com:25 -starttls smtp -brief
# Or by hand
telnet mail.example.com 25
EHLO test.example.com
STARTTLS
QUIT
A 220 reply to STARTTLS means support; anything else confirms the finding. Test from the scanner’s network zone.
Postfix
postconf smtpd_tls_security_level smtpd_tls_cert_file smtpd_tls_key_file smtpd_tls_chain_files
postconf -P | grep tls
smtpd_tls_security_level defaults to empty, and TLS is disabled in the Postfix SMTP server by default. The second command shows master.cf overrides; a -o smtpd_tls_security_level=none on one service turns STARTTLS off for that listener only. Also check smtpd_discard_ehlo_keywords and smtpd_discard_ehlo_keyword_address_maps, which can hide starttls from all or some clients.
Exchange Server
Get-ReceiveConnector | Format-Table Identity,Bindings,Fqdn,AuthMechanism -AutoSize -Wrap
Get-ExchangeCertificate | Format-List Thumbprint,Subject,CertificateDomains,Services,NotAfter,Status
Get-ExchangeCertificate -DomainName mail.example.com
Microsoft’s receive connector documentation says the Tls mechanism advertises STARTTLS in the EHLO response and needs a certificate that includes the name the connector advertises (its Fqdn). Look for a connector without Tls, or no valid certificate covering that name. The last command shows which certificate Exchange selects for a given FQDN.
Exim
exim -bV # the binary is exim4 on Debian and Ubuntu
exim -bP tls_advertise_hosts tls_certificate tls_privatekey
exim -bV lists the optional features compiled in; without OpenSSL or GnuTLS there is no STARTTLS. An empty tls_advertise_hosts means STARTTLS is switched off.
Sendmail
grep -E '^O (ServerCertFile|ServerKeyFile|CACertFile|CACertPath|DaemonPortOptions)' /etc/mail/sendmail.cf
Missing certificate options, or an S in a DaemonPortOptions modifier (which means “don’t offer STARTTLS”), explain the finding. The binary must also be compiled with STARTTLS support.
How to fix it
Every variant needs a certificate and private key. For opportunistic server-to-server TLS a self-signed certificate encrypts the session, but use one from a trusted CA for client submission and for any MX covered by MTA-STS. Track expiry in your TLS certificate inventory, because an expired mail certificate brings this finding (or worse) back.
Postfix
# /etc/postfix/main.cf, Postfix 3.4 and later
# (one file: private key first, then the certificate chain)
smtpd_tls_chain_files = /etc/postfix/mail.example.com.pem
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
# Postfix 3.3 and older
smtpd_tls_cert_file = /etc/postfix/mail.example.com.crt
smtpd_tls_key_file = /etc/postfix/mail.example.com.key
smtpd_tls_security_level = may
postfix check
postfix reload
The key must be owned by root and readable by no other user. On Postfix 3.1 and later with untouched server TLS settings, postfix tls enable-server followed by postfix reload enables opportunistic TLS for you. Keep port 25 at may: postconf(5) says encrypt must not be applied to a publicly referenced server and belongs on dedicated services such as submission:
# /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
Exchange Server 2016, 2019 and Subscription Edition
# After importing the CA-issued certificate:
Enable-ExchangeCertificate -Thumbprint <thumbprint> -Services SMTP
# Record the connector's current mechanisms, then include Tls in the new list
Get-ReceiveConnector "EX01App Relay EX01" | Format-List AuthMechanism,Fqdn
Set-ReceiveConnector "EX01App Relay EX01" -AuthMechanism Tls,ExternalAuthoritative
The example fits an externally secured relay connector (Tls is the only value allowed alongside ExternalAuthoritative); for other connectors, pass the existing values plus Tls. Enable-ExchangeCertificate prompts before replacing the default self-signed SMTP certificate (-Force skips the prompt); Microsoft notes that certificate is typically fine for internal SMTP between Exchange servers.
Exim
# Main section of the Exim configuration
tls_advertise_hosts = *
tls_certificate = /etc/exim/mail.example.com.crt
tls_privatekey = /etc/exim/mail.example.com.key
The Exim specification says the default tls_advertise_hosts (*) needs a certificate supplied with tls_certificate. On Debian and Ubuntu, the exim4 README says incoming TLS is on by default with an autogenerated self-signed certificate, so a finding there usually means MAIN_TLS_ADVERTISE_HOSTS was set empty. To use your own certificate, put the key and certificate in /etc/exim4/exim.key and /etc/exim4/exim.crt, then:
# /etc/exim4/exim4.conf.localmacros (non-split config)
# or /etc/exim4/conf.d/main/000_localmacros (split config)
MAIN_TLS_ENABLE = yes
update-exim4.conf
systemctl restart exim4
Sendmail
dnl /etc/mail/sendmail.mc
define(`confCACERT_PATH', `/etc/mail/certs/')dnl
define(`confCACERT', `/etc/mail/certs/CA.cert.pem')dnl
define(`confSERVER_CERT', `/etc/mail/certs/mail.cert.pem')dnl
define(`confSERVER_KEY', `/etc/mail/certs/mail.key.pem')dnl
These four are the minimum sendmail’s cf/README lists for STARTTLS to be offered. Remove any S modifier from DAEMON_OPTIONS, regenerate sendmail.cf the way your distribution does (m4 on the .mc file), and restart. The private key must be unencrypted and protected by file permissions; sendmail rejects a group-readable key unless DontBlameSendmail includes GroupReadableKeyFile.
IIS SMTP Service
Microsoft removed the SMTP Server feature from Windows Server 2025 and points to Exchange Server or a non-Microsoft SMTP server instead. On older versions, the SMTP virtual server (managed in the IIS 6 Manager) can only offer STARTTLS once a server certificate is installed for it. Given the removal, moving the relay to a maintained MTA is the more durable fix.
How to verify the fix and rescan
openssl s_client -connect mail.example.com:25 -starttls smtp -brief
openssl s_client -connect mail.example.com:587 -starttls smtp -brief
Both should complete a handshake and show your certificate. On Postfix, smtpd_tls_received_header = yes records TLS details in the Received header of a test message. If sendmail still lacks 250-STARTTLS, its README suggests running the daemon with -O LogLevel=14 to log certificate and permission problems.
Then rerun the same Greenbone task against the same target. The finding should clear, and the detection script instead logs that the server supports STARTTLS. In Nessus, plugin 42088 should appear for the port.
What can break and how to roll back
- A broken certificate or key. If the daemon cannot load them, clients get 454 or a failed handshake, and RFC 3207 leaves it to each client whether to continue in plaintext, retry later or give up. Run openssl s_client immediately after the change.
- Mandatory TLS on port 25. RFC 3207 says a publicly referenced server must not require STARTTLS to deliver mail locally. Keep port 25 opportunistic.
- Old devices. Printers and appliances with outdated TLS stacks may fail the handshake once STARTTLS is offered. Upgrade firmware, or give them a dedicated listener scoped to their IP addresses and record the exception.
- Exchange certificate assignments are one-way. Once a certificate is enabled for a service it cannot be disabled; roll back by enabling the previous certificate (record its thumbprint first) for SMTP.
Rollback elsewhere: restore the main.cf backup (or the previous smtpd_tls_security_level) and run postfix reload; remove the Exim macro or options and restart; restore the previous sendmail.cf and restart.
Common false positive reasons
- Something in front of the server. An email gateway, load balancer or NAT rule may own the scanned address. Test the backend and the front address separately.
- A different listener for the scanner. Exchange picks the receive connector with the most specific remote IP match, Exim’s tls_advertise_hosts is a host list, and Postfix can hide EHLO keywords per client address. Your admin workstation may get a different answer than the scanner did.
- A transient failure at scan time. An expired or unreadable certificate during the scan produces 454; if STARTTLS works now, rescan rather than accept the result.
- A non-mail service identified as SMTP. The check runs on any port detected as SMTP, including embedded listeners on appliances. More patterns: common causes of vulnerability scanner false positives.
FAQ
Greenbone rates it 0.0. Do I need to fix it?
On an internet MX or any port carrying logins, yes: without STARTTLS, mail and credentials cross the network in cleartext. On a loopback-only or isolated relay, documenting it as accepted risk can be reasonable.
Should I set smtpd_tls_security_level = encrypt on port 25?
No. Use may on port 25 and encrypt on submission (587). Postfix and RFC 3207 both say a publicly referenced server must not require TLS.
Is a self-signed certificate enough?
For opportunistic server-to-server TLS, yes: Postfix’s TLS_README says an MX without a public CA certificate should still present a self-signed one. With MTA-STS, and for client submission, use a publicly trusted certificate.
Does port 465 need STARTTLS?
No. Port 465 uses implicit TLS from the first byte, and the Greenbone check skips ports that already speak TLS.
Tracking this finding across many hosts
This finding tends to surface on relays and appliances nobody treats as mail servers. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners and can launch OpenVAS and Nessus scans directly, so closure for this OpenVAS check is confirmed by rerunning the scan (per-finding retest covers only Nessus, Acunetix and Burp). Duplicates are merged within each scanner, not across them, and AI-drafted, host-specific fix scripts reach Windows and Linux agents only after a person approves them.