🚀 go-pugleaf

    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.