Third party security scan is showing VRFY is supported. How to fix this?
03/26/2020 7 People found this article helpful 483,950 Views
Description
Third party security scan is showing VRFY is supported. How to fix this?
Resolution
Question:
Third party vulnerability scanners are showing VRFY is enabled in SonicWall. How to disable the same?
Answer:
A VRFY request asks the server to verify an Email address. Its parameter may be an encoded address or a user name in a server-defined format.If the server accepts the request (required code 250, 251, or 252), it may provide information about the address in a server-defined format. 250 typically means that the address is valid, 251 typically means that mail to the address is forwarded, and 252 means that the server doesn't know whether the address is valid.
To comply with RFC standards, every SMTP server should support VRFY command. Please find the portion from RFC 5321 which explains this.
Server implementations SHOULD support both VRFY and EXPN. For
security reasons, implementations MAY provide local installations a
way to disable either or both of these commands through configuration
options or the equivalent (see Section 7.3). When these commands are
supported, they are not required to work across relays when relaying
is supported. Since they were both optional in RFC 821, but VRFY was
made mandatory in RFC 1123[3], if EXPN is supported, it MUST be
listed as a service extension in an EHLO response. VRFY MAY be
listed as a convenience but, since support for it is required, SMTP
clients are not required to check for its presence on the extension
list before using it.
Due to the fact that VRFY is a security risk, it has been put up in this way that server should respond with a 252 code with any message along with it but information such as user email address should not be provided in a response to VRFY query. Please find the portion from RFC 5321 below which explains this.
As discussed in Section 3.5, individual sites may want to disable
either or both of VRFY or EXPN for security reasons (see below). As
a corollary to the above, implementations that permit this MUST NOT
appear to have verified addresses that are not, in fact, verified.
If a site disables these commands for security reasons, the SMTP
server MUST return a 252 response, rather than a code that could be
confused with successful or unsuccessful verification.
Refer Here for more details.
Due to the above reasons SonicWall also supports VRFY command or it will be a violation of RFC standards. For example, if you run VRFY query against your exchange server, we will get below response.
252 2.1.5 Cannot VRFY user
The same way SonicWall provides below response for VRFY query.
252 2.0.0 Mail Facility running (7.4.6.1939) session=201504011808560024121
In both cases user email addresses are not compromised.
Most of the third party vulnerability tests just check whether there is a response for VRFY command, not whether the response provides any kind of information.
Related Articles
Categories
Was This Article Helpful?
YESNO