wales@UCLA-LOCUS.ARPA (Rich Wales) (09/16/84)
I would like to hear some other people's opinions on the SMTP "EXPN" and
"VRFY" commands. I seriously wonder what, if anything, these commands
are good for. As everyone probably knows, they are not required in the
"minimum" SMTP server implementation, and I can think of very few situ-
ations in which a mailer program would ever need (or want) to use them.
First, my gripes with EXPN.
The problem with using EXPN to expand a remote mailing list is that this
spoils any attempt by the receiving host to direct "undeliverable mail"
messages to someone who can fix the problem.
I think everyone by now agrees that problems relating to an invalid
address on a mailing list should be reported to whoever is responsible
for maintaining the mailing list -- NOT to the person who sent a message
to the list. But there is no provision in the EXPN command for the
server to pass this information back to the requesting host.
Hence, any host which used EXPN in order to send directly to everyone on
a remote mailing list would defeat any attempt by the remote host to
direct error messages to the right place (by substituting a new "return
path" as the list was expanded).
Admittedly, mailing lists could be flagged in some way so that an EXPN
on the name would return only one line (namely, the address of the list)
-- but if you do this, what's the point in having EXPN at all?
Now, the problems with VRFY.
I have seen only one ARPANET host whose mailer routinely uses VRFY
(namely, MIT-MULTICS). Even MIT-MULTICS appears to use VRFY only when
relaying mail originating on MAILNET. The scenario seems to be as fol-
lows (based on an examination of the various system logs kept by our
SMTP server):
(1) MIT-MULTICS connects to our SMTP server and issue a VRFY -- which is
rejected with a 502 ("command not implemented") reply code.
(2) MIT-MULTICS, upon having its VRFY command rebuffed in this manner,
does a QUIT and closes the connection.
(3) Almost immediately thereafter, MIT-MULTICS connects to our SMTP
server again and, without trying another VRFY, sends mail to the
user named in the previous session's unsuccessful VRFY.
I sent a message to Postmaster@MIT-MULTICS a little while ago asking
about this strange behavior, but never received a reply. I also re-
cently added code to our SMTP server to implement VRFY (for local user
names and mailing lists only), and I'm waiting to see what happens if
MIT-MULTICS says VRFY to us and gets a real answer back -- but, so far,
there have been no takers.
The idea of doing a VRFY on a user name before trying to send mail to
that name disturbs me. RFC821's description of VRFY is vague enough to
make it unreliable as a means for validating an address before mailing
to it. This is particularly true when non-local user names are involved
(if someone wants to send to "podunk!fred@UCLA-LOCUS.ARPA", there is no
way we can validate a command like "VRFY podunk!fred"). In any case,
I thought that validation of a recipient address -- if done by the SMTP
server at all -- belonged in the processing of the RCPT command.
The only scenario I can currently think of where a mailer program might
want to use VRFY is if a RCPT command is rejected and the mailer wants
to get as much info as possible to send back to the user. For example,
assume I call up the PODUNK.ARPA SMTP server and try to send mail to
"fred@PODUNK.ARPA":
220 PODUNK.ARPA SMTP server ready
helo UCLA-LOCUS.ARPA
250 PODUNK.ARPA (hi there, UCLA-LOCUS.ARPA)
mail from:<john@UCLA-LOCUS.ARPA>
250 OK
rcpt to:<fred@PODUNK.ARPA>
550 Sorry, no one named <fred@PODUNK.ARPA> here
At this point, I could do a VRFY and see if I get anything interesting:
vrfy fred
553-Ambiguous user name; try one of:
553-Fred Jones <jones@PODUNK.ARPA>
553 Fred Smith <smith@PODUNK.ARPA>
quit
221 PODUNK.ARPA SMTP server says bye-bye
Now, when I send the obligatory "rejection notice" back to the message
sender, I can include the reply to the VRFY in the message -- perhaps
like this:
Date: Sat, 15 Sep 84 14:20:10 PDT
From: UCLA-LOCUS Mail System <Postmaster@UCLA-LOCUS.ARPA>
To: John Jones <john@UCLA-LOCUS.ARPA>
Subject: Undeliverable mail to <fred@PODUNK.ARPA>
===== transcript of mailer session follows =====
rcpt to:<fred@PODUNK.ARPA>
550 Sorry, no one named <fred@PODUNK.ARPA> here
vrfy fred
553-Ambiguous user name; try one of:
553-Fred Jones <jones@PODUNK.ARPA>
553 Fred Smith <smith@PODUNK.ARPA>
===== unsent message follows =====
. . .
Other than this, I really can't think of a good use for VRFY.
-- Richsmb@ulysses.UUCP (Steven Bellovin) (09/16/84)
Except for the problem of failed mail in a list expansion -- on which matter I agree with Rich Wales -- EXPN struck me as a good idea for handling mail to multiple lists, or to a person and a list. As is, Rich is going to receive two copies of this letter -- one direct, and one via the list expansion. A sufficiently smart mailer could use EXPN to discover that Rich is on the list, and not send him a separate copy. (We'll ignore the fact that this particular note is going via uucp to an SMTP host; it wouldn't really change anything if it weren't.) --Steve Bellovin AT&T Bell Laboratories ulysses!smb@berkeley.arpa smb.ulysses.btl@csnet-relay (should work, but probably doesn't) smb.research.btl@csnet-relay (works more often)
Craig.Everhart@CMU-CS-A.ARPA (09/17/84)
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
Hornig@SCRC-STONY-BROOK.ARPA (Charles Hornig) (09/17/84)
Date: Sat, 15 Sep 84 14:39:52 PDT
From: Rich Wales <wales@UCLA-LOCUS.ARPA>
I would like to hear some other people's opinions on the SMTP "EXPN" and
"VRFY" commands. I seriously wonder what, if anything, these commands
are good for. As everyone probably knows, they are not required in the
"minimum" SMTP server implementation, and I can think of very few situ-
ations in which a mailer program would ever need (or want) to use them.
First, my gripes with EXPN.
We (Symbolics) use EXPN solely to support our user-level "Show Mailing
List" command. The actual sending of mail does not use it.
Now, the problems with VRFY.
I have seen only one ARPANET host whose mailer routinely uses VRFY
(namely, MIT-MULTICS). Even MIT-MULTICS appears to use VRFY only when
relaying mail originating on MAILNET. The scenario seems to be as fol-
lows (based on an examination of the various system logs kept by our
SMTP server):
(1) MIT-MULTICS connects to our SMTP server and issue a VRFY -- which is
rejected with a 502 ("command not implemented") reply code.
(2) MIT-MULTICS, upon having its VRFY command rebuffed in this manner,
does a QUIT and closes the connection.
(3) Almost immediately thereafter, MIT-MULTICS connects to our SMTP
server again and, without trying another VRFY, sends mail to the
user named in the previous session's unsuccessful VRFY.
I sent a message to Postmaster@MIT-MULTICS a little while ago asking
about this strange behavior, but never received a reply. I also re-
cently added code to our SMTP server to implement VRFY (for local user
names and mailing lists only), and I'm waiting to see what happens if
MIT-MULTICS says VRFY to us and gets a real answer back -- but, so far,
there have been no takers.
Multics systems send a VRFY when they are acting as a mail relay and
receive a RCPT for a non-local recipient. The idea is to make a best
effort to get the appropriate error back to the sender syncronously. If
the VRFY command is not completed successfully (as was the case above)
the mail is accepted anyway for forwarding.don.provan@CMU-CS-A.ARPA (09/17/84)
i've always assumed that VRFY would be used only in reaction to a user's request. in other words, a user would say "verify jones@cmu-10a" and the program would run out and check on the existence of such a user. there are any number of reasons a person may want to check an address in such a way. for me, it's usually because i can't remember whether jones has his mailbox on cmu-10a or cmu-10b. VRFY allows me to check this without actually sending mail. i assume EXPN is for similar purposes. it's not intended to be used to deliver mail to the list. it allows a user to find out who's on the list. i didn't have anything to do with designing this protocol, so i'm guessing when i say "intended", but it certainly seems like the more obvious use of optional commands. i'd also like to point out that i talk big, but none of my software uses or supports these two commands in any way.
WMartin@SIMTEL20.ARPA (William G. Martin) (09/18/84)
The recent discussion of the EXPN and VRFY commands included a couple mentions of using EXPN to implement a command that would let a user discover who is on a remote mailing list. I had never heard of such a command before, but, now that I know it is possible, I want it! As a contact point at my Activity for message-system problems and advice, I have often been asked by various users who send mail to a remote mailing list how to find out the actual recipients of such mail. For lists with regular maintainers and "list-Request" addresses, it is often possible to either write the request address or locate and read the actual file of addresses via FTPing to the distribution host. (This was easy on MIT-based distributions, but not possible on BRL-based distributions, where anonymous FTP login is not allowed.) For other lists, where the maintainer is not known, it is difficult. So, if a simple, user-executable command exists that I can tell a secretary to use to find out who is on the "DMIS-Chiefs@BRL" list, I need to know it! I need such a command for our 4.2 BSD UNIX main host (ALMSA-1), which runs mmdf mail. I'd also like to find it on this TOPS-20 host from which I am sending this message. Is it there, already existing, and I just don't know what the command is? Or do I have to get the command implementation from somewhere and have our operating systems people install it? Or is this only implemented by a couple people out there and it isn't really available at all? And does this discussion, in which most people say that their host ignores the "EXPN" command anyhow, mean that, even if I located and installed the user-command to perform this function, it wouldn't work in most cases anyway? (Caught up to the heights of joy, and then cruelly dashed on the rocks of despair...) Will Martin USArmy AMC ALMSA, St. Louis, MO -------
MRC@SU-SCORE.ARPA (Mark Crispin) (09/18/84)
The distributed version of the TOPS-20 SMTP server (MAISER) supports
both the VRFY and the EXPN commands. For local mailing list expansion
lookups, you can run the MMailbox program (or XMailbox for very old systems).
It would not be too difficult to write a network "remote mailing list
query" program for TOPS-20 or for that manner any operating system. I'd be
surprised if it took a junior programmer more than 15 minutes to do it. I've
always been lazy and TELNET'd to the SMTP server.
-------cak@Purdue.ARPA (Christopher A Kent) (09/21/84)
From: William G. Martin <WMartin@SIMTEL20> Subject: Re: What are SMTP commands "EXPN" and "VRFY" good for? The recent discussion of the EXPN and VRFY commands included a couple mentions of using EXPN to implement a command that would let a user discover who is on a remote mailing list. I had never heard of such a command before, but, now that I know it is possible, I want it! My implementation of the finger protocol for Unix has this feature; if you finger a mailing list on a remote site, the server will expand it and finger all the individual members (recursively following lists, of course). As a separate issure, I'd like to see this kind of behaviour more formally described with a new finger protocol spec (there are a number of problems with the current one). Anyone interested in collaborating? chris ----------