SMTP – VRFY Normal Response

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.

STMP – Commands for Debugging Addresses

Welcome to the tutorial guide.  The tutorial will provide a user with advice and guidance on commands for debugging addresses. 
SMTP provides commands to verify a user name or obtain the content of a mailing list.  This is done with the VRFY and EXPN commands, which have character string arguments.
For the VRFY command, the string is a user name or a user name and domain (see below).  If a normal (i.e., 250) response is returned, the response may include the full name of the user and must include
the mailbox of the user.  It must be in either of the following forms:

 
      User Name <local-part@domain>
      local-part@domain

When a name that is the argument to VRFY could identify more than one mailbox, the server can either note the ambiguity or identify the alternatives.  In other words, any of the following are legitimate
response to VRFY:

       553 User ambiguous

   or

      553- Ambiguous;  Possibilities are
      553-Shafkat Shahzad <sshahzad@foo.com>
      553-Anjum Shahzad <ashahzad@foo.com>
      553 Derek Smith <dsmith@foo.com>

    or

       553-Ambiguous;  Possibilities
      553- <sshahzad@foo.com>
      553- <ashahzad@foo.com>
      553 <dsmith@foo.com>

Under normal circumstances, a client receiving a 553 reply would be expected to expose the result to the user.  Use of exactly the forms given, and the “user ambiguous” or “ambiguous” keywords, possibly supplemented by extended reply codes will facilitate automated translation into other languages as needed.

Please note that a client that was highly automated or that was operating in another language than English, might choose to try to translate the response, to return some other indication to the user than the literal text of the reply, or to take some automated action such as consulting a directory service for additional information before reporting to the user.

For the EXPN command, the string identifies a mailing list, and the successful (i.e., 250) multiline response can include the full name of the users and must give the mailboxes on the mailing list.

In some hosts the distinction between a mailing list and an alias for a single mailbox is a bit fuzzy, since a common data structure may hold both types of entries, and it is possible to have mailing lists
containing only one mailbox. 

If a request is made to apply VRFY to a mailing list, a positive response can be given if a message so addressed would be delivered to everyone on the list, otherwise an error should be reported (e.g., “550 That is a mailing list, not a user” or “252 Unable to verify members of mailing list”).  If a request is made to expand a user name, the server can return a positive response consisting of a list containing one name, or an error can be reported (e.g., “550 That is a user name, not a mailing list”).

In the case of a successful multiline reply (normal for EXPN) exactly one mailbox is to be specified on each line of the reply.  The case of an ambiguous request is discussed above.

 “User name” is a fuzzy term and has been used deliberately.  An implementation of the VRFY or EXPN commands must include at least recognition of local mailboxes as “user names”.  However, since
current Internet practice often results in a single host handling mail for multiple domains, hosts, especially hosts that provide this functionality, should accept the “local-part@domain” form as a “user name”; hosts can also choose to recognize other strings as “user names”.

The case of expanding a mailbox list requires a multiline reply, such as:

      C: EXPN Example-People
      S: 250-Rohail Khan <Rkhan@isi.edu>
      S: 250-Malik Riaz <Mriaz@physics.foo-u.edu>
      S: 250 Sheikh S Alam <SSAlam@specific.generic.com>

   or

      C: EXPN Executive-Washroom-List
      S: 550 Access Denied to You.
The character string arguments of the VRFY and EXPN commands cannot be further restricted due to the variety of implementations of the user name and mailbox list concepts.  On some systems it may be
appropriate for the argument of the EXPN command to be a file name for a file containing a mailing list, but again there are a variety of file naming conventions in the Internet.  Similarly, historical variations in what is returned by these commands are such that the response should be interpreted very carefully, if at all, and should generally only be used for diagnostic purposes.

If you followed this tutorial guide then you would have learnt about Commands for Debugging Addresses.