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