From: Robert Elz <kre@munnari.oz.au>
To: drums@cs.utk.edu
Subject: Re: serious VRFY ambiguity 
Date: Sat, 15 Aug 1998 01:32:23 +1000
Message-Id: <25330.903108743@munnari.OZ.AU>
Sender: kre@munnari.oz.au

Personally, I don't care one way of the other whether VRFY is useful
for debugging - I suspect it is, and have probably (in fact certainly)
used it for that, but I don't consider that the argument that matters.

I want VRFY for operational reasons.

Recently there seems to have been rather a lot of "all SMTP is good for
is transferring mail from a client to a server" sentiment.   The SMTP
protocol (as in 821) did much more than that.   True, much of the extra
that it specified (SEND, SAML, etc) has fallen into disuse (if they ever
were in use), and should certainly now be retired to the venerable status
of ancient relics.   However, their existance shows that SMTP was always
meant for more than for a mail client (sending system) to transfer e-mail
to a mail server (receiving system).   VRFY, and EXPN, are also part of
that "more".

I want to be able to use VRFY from non SMTP clients (that is, clients that
are never, ever, going to issue a MAIL FROM or RCPT TO) to validate e-mail
addresses, and what's more, I think that's an important facility to provide.
It is certainly also clearly the business of the SMTP server to provide that
information, as it has to be responsible for delivering messages to addresses
that VRFY has claimed are acceptable.

Further, I want the SMTP server to go to (if necessary) extraordinary
lengths to obtain an answer as accurately as it is able, and return 252
only when there really is no way to validate the address short of really
sending a message to it (one example of that is when a SMTP server is
willing to do relaying, is handed an address in another domain, and the
server for the other domain is not currently reachable, or is reached
via a protocol stack that has no VRFY equivalent).

I have no objection (if necessary) to restricting the use of VRFY such that
a MAIL FROM or RCPT TO can be considered a sequence error if issued after
a VRFY (nor do I even mind if even a RSET is unable to put things back),
or if VRFY issued after MAIL FROM is a sequence error - that is, the command
sequence I want to work is HELO (or EHLO) VRFY [VRFY ...] QUIT.
That is, if the SMTP server wants to exit the scene, and replace itself
with a dedicated VRFY server, that is able to delve deeper into the system's
e-mail sub-structure, that's fine.

Finally, it is perfectly within the scope of the IETF to mandate that
copnforming implementations must provide various configurability options
(just go look at 1122 and 1123 to see examples of dozens, if not hundreds
of such things).   Whever experience has shown that users need to be
able to configure their systems so as to correctly interoperate with
other systems, correct interoperability requires that suitable configuration
options be present.  Eg: if a http server of mine (or a CGI script run from
it) desires to VRFY a user's e-mail address (as entered on a form), and
the user has no way to make his SMTP server respond to that VRFY request,
then interoperability has suffered.   We don't require that VRFY always be
enabled because of some sites' legitimate concerns with privacy.  Such sites
won't be able to interoperate fully, but that's their choice, it hasn't
been made for them by their mailer vendor without their having any opportunity
to exercise it (that is, not allowing VRFY to be enabled is just as bad
as enabling it by default and not allowing it to be disabled).  It is not
adequate to say "the user can just go get another mailer" as in many
situations that simply isn't practical.

kre