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.
The server's envelope is unchanged by VRFY.
VRFY jones 250 email@example.com VRFY smith 250 Locksmith <firstname.lastname@example.org>Klensin requires that any 250 response to VRFY have one of the above formats. However, many other formats are used in practice.
I recommend always accepting VRFY with code 252 and generic text:
VRFY <email@example.com> 252 send some mail, i'll try my bestRejecting VRFY is dangerous, since a few clients do VRFY before RCPT and do not send mail if VRFY is rejected.
There is a VRFY extension that promises support for the VRFY verb. Many servers support VRFY but don't announce the VRFY extension. Clients don't pay attention to the VRFY extension; they simply try the VRFY request.
If the server accepts the request (required code 250), its response text shows each subscriber to the mailing list, one per line, in a server-defined format.
The server's envelope is unchanged by EXPN.
The concept of a ``mailing list'' is defined by the server. Some servers treat a local user as a ``mailing list'' with one subscriber, so that EXPN subsumes VRFY. Others do not.
I do not recommend implementing EXPN. RFC 1123 says that EXPN is useful for ``diagnosing inadvertent mail loops.'' This is obsolete; modern mailing lists stop loops automatically. The primary use of EXPN today is by spammers collecting addresses.
There is an EXPN extension that promises support for the EXPN verb. Many servers support EXPN but don't announce the EXPN extension. Clients don't pay attention to the EXPN extension; they simply try the EXPN request.