Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on VRFY response.
When normal (2yz or 551) responses are returned from a VRFY or EXPN request, the reply normally includes the mailbox name, i.e., “<local-part@domain>”, where “domain” is a fully qualified domain name, must appear in the syntax. In circumstances exceptional enough to justify violating the intent of this specification, free-form text may be returned. In order to facilitate parsing by both computers and people, addresses should appear in pointed brackets. When addresses, rather than free-form debugging information are returned.
EXPN and VRFY should return only valid domain addresses that are usable in SMTP RCPT commands. Consequently, if an address implies delivery to a program or other system, the mailbox name used to reach that target must be given. Paths (explicit source routes) should not be returned by VRFY or EXPN.
Please note that 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. When these commands are supported, they are not required to work across relays when relaying is supported. As they were both optional in RFC 821, so they must be listed as service extensions in an EHLO response, if they are supported.
What is VRFY or EXPN Success Response?
It is good to know what is VRFY or EXPN success response. This is provided below:
Please note that a server must not return a 250 code in response to a VRFY or EXPN command unless it has actually verified the address. In particular, a server must not return 250 if all it has done is to verify that the syntax given is valid. In that case, 502 (Command not implemented) or 500 (Syntax error, command unrecognised) should be returned. The implementation (in the sense of actually validating addresses and returning information) of VRFY and EXPN are strongly recommended. This is why the implementations that return 500 or 502 for VRFY are not in full compliance with this specification.
There is a possibility that circumstances may arise where the address appears to be valid but cannot reasonably be verified in real time, particularly when a server is acting as a mail exchanger for another server or domain.
“Apparent validity” in this case would normally involve at least syntax checking and might involve verification that any domains specified were ones to which the host expected to be able to relay mail. In these situations, reply code 252 should be returned.
Semantics and Applications of EXPN
A user should note that EXPN is often very useful in debugging and understanding problems with mailing lists and multiple-target-address aliases. Some systems have attempted to use source expansion of mailing lists as a means of eliminating duplicates. The propagation of aliasing systems with
mail on the Internet, for hosts (typically with MX and CNAME DNS records), for mailboxes (various types of local host aliases), and in various proxying arrangements, has made it nearly impossible for these strategies to work consistently, and mail systems should not attempt them.
If a user followed this tutorial guide then he/she would have learnt about the SMTP VRFY Normal Response and Semantics and application of EXPN.