Re: [apps-discuss] [EAI] RFC5336 and VRFY/EXPN (was: Re: apps-team review of draft-ietf-eai-rfc5336bis)

[John C Klensin <[e-mail]>]

--On Monday, December 27, 2010 12:00 AM -0500 Al Costanzo
<[e-mail]> wrote:

>...
> Ned,
> 
> If my memory servers me, (and it may not),
> 
> There were good reasons why VRFY supported this.  I dont know
> if any are valid anymore but one idea was that you could send
> the persons name, not the email address, to find out if that
> person had an email address on that system.

and what that address was, of course.

This was heavily used for a while with both VRFY and, separately
with finger, to get from name to email address.  The advantage
of the VRFY approach was that it would permit a user to enter an
address that might look like "John [e-mail]" at which
point the MUA would send 
   VRFY John Klensin
to the mail server at example.com, get back an address, and then
open a mail session.

Of course, Ned's observations about lousy support (with which I
agree) notwithstanding, the variation of 
   VRFY "John\ Klensin"
would have been fully 821-compliant.  I vaguely remember one MUA
that would send the first (escape-less) version and then send
the second if the reply from the first was "no 'John; here" or
"syntax error" rather than "no 'John Klensin' here".  The
heuristic is pretty trivial.

That use of VRFY became less popular as MUAs became more
separate from first-hop full service MTA (aka submission
servers) because that sort of use of VRFY pretty much requires
at least some SMTP capability (including domain name lookups,
coping with MXs, etc.) in the MUAs, ability to use port 25
connections from just about anywhere, etc.   I don't know
whether the usage is gone entirely, but it is certainly a lot
less common than it appeared to be many years ago.

> Was this not the reason Ned to allow blanks (whitespace) and
> unquoted strings?  If you remove this from the spec, this
> functionality would be lost, I don't really see a reason to
> lose something that works.

Especially if the clock could be turned back, one could allow
only the single form

  VRFY "John Klensin"

just getting rid of the bare, unquoted, backslash escape that
was permitted by 821 but that 5321 already excludes.

>>> RFC 5321, Section 4.1.4, explicitly
>>> permits sending VRFY or EXPN without first having EHLO in the
>>> session.  So there is another implicit requirement in all of
>>> this that should almost certainly be made explicit.
 
> I do not remember VRFY command requiring the EHELO, there are
> a number of mailing list verifiers that do not send the EHELO
> first.

It never has been a requirement although sending EHLO (or HELO)
first has always been harmless.  Either 5321 or 2821 simply made
it very clear that there was no such requirement.

> Verifiers, since they do not actually send email,
> usually dont send the EHELO first. (our application does) and
> I think requiring the EHELO first as part of a handshake it
> the proper way to do this.

That is one issue on the side of "new command".  If one now
decides to require EHLO first, then all existing uses of VRFY
without it (which conform perfectly well to 5321 and all of its
predecessors) become invalid,  That is pretty uncomfortable to
me.  By contrast, if one creates the new command, then, if the
response to EHLO includes some sort of EXTENDED-VRFY capability
(see below),  one could have:

	-- VRFY without EHLO as requesting the 5321 behavior
	(with or without non-conforming extensions or
	flexibility and with responses limited to ASCII).
	
	-- EHLO, then VRFY as requesting the 5321 behavior,
	identical to that above.  
	
	-- EHLO, then New-VRFY as requiring a strict Atom or
	Quoted-string optionally followed by a parameter list.

Note that, if the non-conforming client behavior we know is out
there is used, then 
    VRFY Costanzo 8BITREPLIES-OK
or equivalent could be interpreted by the server as either of
    VRFY "Constanzo\ 8BITREPLIES-OK"
or as coming with a parameter, or as a syntax error, in either
VRFY case.   Not really a good idea, IMO, and at least one
reason we have not permitted the use of extended parameters with
older SMTP commands with EHLO and capability permission.

Note too that the last paragraph of RFC 5321 Section 3.5.1 is,
in part and while not explicit, a caution against treating the
standard syntax too literally or narrowly. 

We could, in principle, do a completely new command without
involving the extension mechanism at all, thereby allowing
sending it before or without EHLO, but that strikes me as a
really scary idea.

> Only my humble opinon.

Only mine also -- I really don't have my mind made up about this
and am just trying to get the various arguments in front of the
WG.

     john

p.s. I agree with what I take to be at least a corollary to
Ned's remarks: having EAI create special-purpose commands that
are not very narrowly tied to i18n issues would be a bad idea.
If there is any perceived need for a new command, we ought to
define in a separate I-D, as (impossible keyword is deliberate
to clarify that this is not a proposal)
   NewVRFY String *(SP esmtp-param)
with String given only the 5321 interpretation, not the 821 one,
and then process that command through the SMTP list, etc.

If that appeals to anyone, I might generate a strawman just to
facilitate the discussion.