Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP
Path: utzoo!watmath!clyde!burl!hou3c!Craig.Everhart@CMU-CS-A.ARPA
From: Craig.Everhart@CMU-CS-A.ARPA
Newsgroups: net.mail.headers
Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for?
Message-ID: <17Sep84.120838.RD00@CMU-CS-A.ARPA>
Date: Mon, 17-Sep-84 12:08:00 EDT
Article-I.D.: hou3c.837
Posted: Mon Sep 17 12:08:00 1984
Date-Received: Thu, 4-Oct-84 02:46:21 EDT
Sender: ka@hou3c.UUCP (Kenneth Almquist)
Reply-To: Craig.Everhart@CMU-CS-A.ARPA
Lines: 39
To: Header-People@MIT-MC.ARPA
In-Reply-To: "Rich Wales's message of 15 Sep 84 16:39-EST"

I can think of several uses for EXPN and VRFY.  As Rich notices, it's too bad
that EXPN doesn't have more options to handle mailing-list exploders and
the destinations for error replies.  Surely EXPN was conceived without
taking such issues real seriously.

EXPN can be used, as has already been noted, to suppress sending private
copies of messages that are also destined for mailing list delivery.
Of course, the client of a mailer that does such suppression must accept
that he will not necessarily be notified on late or failed delivery.

Then again, even though it goes against our images of what all mailing lists
``should'' be like, there can easily be (small) lists that have no particular
maintainer; they act as simple address exploders rather than as redistributors
that take responsibility for the redistribution.  With such lists (which seem
to be the sort of list for which EXPN in its present form was designed),
EXPN has obvious use both in eliminating duplicate delivery and in reducing
the number of forwarding hops necessary.

I can see several uses for VRFY, also.  Let's suppose that a user agent for
electronic mail wanted its client (a user) to know about misspellings of
names that he typed in, and that it wanted him to know about them right away.
It could connect to the proposed destination host and try to VRFY the addresses
that the user gave.  Then, once the mail was to be delivered, the user agent
might just let a daemon process do that.  (Rationale?  Not easy, until you
think that maybe the user doesn't really care if the mail goes out immediately
or in several minutes; maybe the user wants to do something else right now.)

Another use of VRFY could be as follows.  Suppose a program maintains
distribution lists for people.  Suppose that it has a command to validate the
addressees named in the list; perhaps this is to update the list to account
for new forwarding links or new host names that have been established since
the list entry was made.  What better tool is there than VRFY, which checks
addressees on foreign hosts without actually sending mail?

When a feature is being used, it's a good bet that it's a usable and useful
feature.  However, just because a feature isn't much used yet doesn't mean
that it's not both usable and useful.  Give it time!

		Craig Everhart