A penetration test has been run on one of my servers that runs Exim for mail and they have this complaint:
Description: The Mailserver on this host answers to VRFY and/or EXPN requests. VRFY and EXPN ask the server for information about an address. They are inherently unusable through firewalls, gateways, mail exchangers for part-time hosts, etc. OpenVAS suggests that, if you really want to publish this type of information, you use a mechanism that legitimate users actually know about, such as Finger or HTTP.
Solution: Disable VRFY and/or EXPN on your Mailserver. For postfix add 'disable_vrfy_command=yes' in 'main.cf'. For Sendmail add the option 'O PrivacyOptions=goaway'.
Unfortunately it's Exim and not Sendmail/postfix. Their output shows that running the EXPN command generates the response "550 Administrative prohibition". I tested this with telnet and it is correct.
Is there a way to stop it from replying at all? Thanks in advance
RFC 2505 states:
Both SMTP VRFY and EXPN provide means for a potential spammer to test whether the addresses on his list are valid (VRFY) and even get more addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed to issue these commands. This may be "on/off" or it may use access lists similar to those mentioned previously.
Note that the "VRFY" command is required according to RFC821, 1.
The response can, though, be "252 Argument not checked" to represent "off" or blocked via an access list. This should be the default.
According to the exim documentation here http://www.exim.org/exim-html-current/doc/html/spec_html/ch-smtp_processing.html
"When Exim receives a VRFY or EXPN command on a TCP/IP connection, it runs the ACL specified by acl_smtp_vrfy or acl_smtp_expn (as appropriate) in order to decide whether the command should be accepted or not.
When no ACL is defined for VRFY, or if it rejects without setting an explicit response code, the command is accepted (with a 252 SMTP response code) in order to support awkward clients that do a VRFY before every RCPT".
To me, this suggests always return a 252, rather than turning if off completely.