Multiple Mail Server EXPN/VRFY Information Disclosure (Nessus plugin 10249) means your SMTP server answers VRFY or EXPN in a way that confirms which accounts and aliases exist. The fix is to disable VRFY and EXPN: set disable_vrfy_command = yes in Postfix, PrivacyOptions goaway (or novrfy,noexpn) in Sendmail, and leave acl_smtp_vrfy and acl_smtp_expn unset in Exim.
What the scanner is actually detecting
VRFY asks a mail server whether a mailbox exists. EXPN asks it to expand an alias or mailing list into the addresses behind it. Both commands were defined in RFC 821 in 1982, and a server that answers them truthfully gives anyone who can reach port 25 a free directory lookup.
| Scanner | Finding title | What triggers it |
|---|---|---|
| Nessus (plugin 10249, family SMTP problems) | Multiple Mail Server EXPN/VRFY Information Disclosure | A remote, unauthenticated check of the SMTP service (port 25 by default) finds that the server responds to EXPN, VRFY or both. Tenable rates it Medium (CVSS v2 5.0), assigns no CVE and notes that a Metasploit module, the SMTP User Enumeration Utility, automates the lookup. |
Tenable’s published solution covers only Sendmail (O PrivacyOptions=goaway in sendmail.cf). The disclosure lies in the difference between answers. On a Postfix server with the default disable_vrfy_command = no, a real address and an invented one get different replies (exact wording depends on your configuration):
VRFY root@example.com
252 2.0.0 root@example.com
VRFY no-such-user-x7@example.com
550 5.1.1 <no-such-user-x7@example.com>: Recipient address rejected: User unknown in local recipient tablePostfix runs its normal recipient checks on the VRFY argument, so the 252 versus 550 split confirms the account. Postfix does not implement EXPN at all. Sendmail and Exim can answer both commands, depending on configuration.
How serious is it, honestly
- It is information disclosure, nothing more. No code runs and no mail is read. The CVSS v2 vector Tenable lists (AV:N/AC:L/Au:N/C:P/I:N/A:N) scores a partial confidentiality impact only.
- Valid usernames feed password attacks. Local accounts on a Sendmail or Postfix host often share names with SSH, IMAP or webmail logins, so a confirmed list makes password spraying cheaper.
- EXPN leaks more than VRFY. According to Tenable, it can reveal the real delivery address behind an alias and sometimes recipients’ full names, which helps targeted phishing. Spammers use both commands to harvest addresses.
- Exposure decides priority. An internet facing MX can be probed by anyone; a relay reachable only from a server VLAN is a much smaller problem. Unsure which mail servers are reachable from outside? Start with your external attack surface scope.
- It does not close RCPT TO probing. A server that rejects unknown recipients during the SMTP session still reveals which addresses exist, and Nmap’s smtp-enum-users script tries RCPT first by default. That is a deliberate trade-off: Postfix rejects unknown recipients by default (smtpd_reject_unlisted_recipient = yes) so its queue does not fill with undeliverable bounces.
How to confirm it on the host
From the network
# Commands and extensions the server advertises
nmap -p 25 --script smtp-commands mail.example.com
# Enumeration attempt using only VRFY and EXPN
nmap -p 25 --script smtp-enum-users --script-args 'smtp-enum-users.methods={VRFY,EXPN}' mail.example.com
# Or by hand
telnet mail.example.com 25
EHLO test.example.com
VRFY root
VRFY no-such-user-x7
EXPN postmaster
QUITCompare the answers. If a real name and a nonsense name get different codes or text, enumeration works; if every name gets the same answer (a uniform 252, or a refusal), nothing is disclosed. Test from the scanner’s network zone, because MTAs can apply rules per client address.
Postfix
postconf disable_vrfy_command
postconf -P | grep -i vrfyThe default is no. The second command (Postfix 2.11 and later) lists master.cf overrides, which win for that service. If you use postscreen, postscreen_disable_vrfy_command inherits the main value unless someone set it explicitly.
Sendmail
grep -i PrivacyOptions /etc/mail/sendmail.cf
grep -i confPRIVACY_FLAGS /etc/mail/sendmail.mcThe sendmail cf README lists authwarnings as the default for confPRIVACY_FLAGS, and that flag blocks neither command. The effective sendmail.cf needs goaway, or novrfy and noexpn. Fedora’s packaged sendmail.mc already sets authwarnings,novrfy,noexpn,restrictqrun and listens on 127.0.0.1 only, so a hit on such a host usually means the file was edited or replaced.
Exim
exim -bP acl_smtp_vrfy acl_smtp_expn # the binary is exim4 on Debian and Ubuntu
grep -rn 'acl_smtp_vrfy|acl_smtp_expn' /etc/exim4 /etc/exim 2>/dev/nullBoth options are unset by default, and the Exim specification says that when the VRFY or EXPN ACL is not defined, the action is deny. A finding on Exim therefore means one of them was set, typically to accept.
How to fix it
The goal on every MTA is the same: disable VRFY and EXPN for untrusted clients, then make sure the running daemon has picked up the change.
Postfix
cp -p /etc/postfix/main.cf /etc/postfix/main.cf.bak
postconf -e 'disable_vrfy_command = yes'
postfix check
postfix reloadIf postconf -P showed an override such as -o disable_vrfy_command=no in master.cf, remove it and reload again. Once VRFY is disabled, Postfix also stops listing VRFY in its EHLO reply. Nothing is needed for EXPN, which Postfix already answers with a “command not recognized” error.
Sendmail
Make the change in sendmail.mc so it survives the next rebuild, then regenerate sendmail.cf and restart:
cp -p /etc/mail/sendmail.mc /etc/mail/sendmail.mc.pre-vrfy
cp -p /etc/mail/sendmail.cf /etc/mail/sendmail.cf.pre-vrfy
# In /etc/mail/sendmail.mc, edit the existing line (or add one):
define(`confPRIVACY_FLAGS', `goaway')dnl
# Fedora packaging: the helper script named in sendmail.mc
# (requires the sendmail-cf package)
/etc/mail/make
# Generic form from the sendmail cf README, run in /etc/mail
m4 ${CFDIR}/m4/cf.m4 sendmail.mc > sendmail.cf
systemctl restart sendmailTenable’s one-line alternative, O PrivacyOptions=goaway directly in sendmail.cf, works but is overwritten the next time someone rebuilds from the .mc file. According to the sendmail operations guide, goaway sets every privacy flag except noreceipts, restrictmailq, restrictqrun, restrictexpand, noetrn and nobodyreturn, so it also requires HELO or EHLO before MAIL and disables VERB. If you want only the two commands closed, list the flags yourself and keep any you already had:
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnlExim
Remove or comment out the acl_smtp_vrfy and acl_smtp_expn lines so the built-in deny applies. If administrators genuinely need VRFY, point the option at a named ACL instead of accept, and put that ACL in your existing ACL section (after the begin acl line):
# Main configuration section
acl_smtp_vrfy = acl_check_vrfy
# ACL section
acl_check_vrfy:
accept hosts = 127.0.0.1
denyTest the policy first with a fake session from a remote address (exim -bh 192.0.2.10, then type EHLO and VRFY), then restart Exim (the exim4 service on Debian and Ubuntu). If your distribution generates the configuration from templates, edit the template instead.
Verify the fix and rescan
Repeat the network test from the scanner’s zone. With default reply texts, you should see:
| MTA | VRFY reply | EXPN reply |
|---|---|---|
| Postfix | 502 5.5.1 VRFY command is disabled | 500 5.5.2 Error: command not recognized |
| Sendmail (goaway, or novrfy and noexpn) | 252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger) | 502 5.7.0 Sorry, we do not allow this operation |
| Exim (ACL unset or denying) | 252 Administrative prohibition | 550 Administrative prohibition |
The 252 replies are correct: RFC 5321 section 7.3 says a server that disables these commands for security reasons must answer 252, not a code that looks like successful or failed verification. What matters is that every name gets the same answer. Then rescan with the same Nessus policy. Plugin 10249 is a remote check and needs no host credentials, but the scanner must still reach the SMTP port on that address.
What can break and how to roll back
- Mail flow itself. Delivery between servers uses MAIL FROM, RCPT TO and DATA, so disabling VRFY and EXPN does not stop inbound or outbound mail.
- Internal tooling. RFC 5321 notes that both commands remain useful inside an administrative domain, for example for internal audits. Look for monitoring checks or scripts that validate addresses with VRFY, and list owners who debug aliases with EXPN. Sendmail logs each refused command with a [rejected] tag when LogLevel is above 5, which helps find callers.
- Sendmail goaway side effects. needmailhelo rejects clients that send MAIL without HELO or EHLO first, and noverb disables VERB. Old scripts that speak raw SMTP can trip on the first; the explicit flag list above avoids both.
- A system that truly needs VRFY. Allow it only from that host, as in the Exim example, and record the exception 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 ‘disable_vrfy_command = no’) and postfix reload. On Sendmail, copy the .pre-vrfy files back over sendmail.mc and sendmail.cf and restart. On Exim, restore the previous configuration and restart.
Common false positive reasons
- A uniform answer is not disclosure. If your comparison shows the same reply for real and invented names, save both transcripts and dispute the finding with that evidence instead of changing a working server.
- Another listener. Check the port in the plugin output. A submission port, a second Postfix instance or a master.cf service with its own -o override may still allow VRFY.
- Something else answers on that address. A mail gateway, spam filter appliance, load balancer or NAT rule may own the scanned IP, so the MTA you fixed is not the one replying. More patterns: common causes of vulnerability scanner false positives.
- Change not live. sendmail.cf was not regenerated, a daemon was not reloaded or restarted, or a template-generated Exim configuration overwrote the edit.
FAQ
Does disabling VRFY and EXPN stop all SMTP user enumeration?
No. RCPT TO probing still works against any server that rejects unknown recipients during the session, which most do on purpose. This fix removes the easiest lookup, not every one.
Why does Sendmail still answer VRFY with a 2xx code?
RFC 5321 requires a 252 reply when a site disables VRFY for security reasons, so the answer cannot be mistaken for verification. Sendmail and Exim follow that rule. Postfix answers 502 instead, and comments in its source acknowledge the difference.
Do I need to change anything for EXPN on Postfix?
No. Postfix has no EXPN command and answers it with 500 5.5.2 Error: command not recognized. Only VRFY needs disabling.
Tracking this finding across many hosts
Plugin 10249 tends to appear on every relay, appliance and application server that runs a local MTA. 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 scanners. Nessus findings can be re-tested one at a time after the change, and host-specific fix scripts drafted by its AI reach Windows and Linux agents only after a person approves them.