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

[Ned Freed <[e-mail]>]

> In addition, one must have a session for which mail transactions
> are permitted (i.e., EHLO must have been sent) in order to use
> any parameters at all.

You certainly need to send an EHLO and process the result to find out what
extensions are allowed - guessing what combination of extensions will work most
certainly is not a sound operational policy. And implementations are certainly
free to only offer the extensions that have been returned in an EHLO repsonse.

That said, I don't see an actual requirement in section 2.2 stating that EHLO
must be issued before any parameters can be used. (Maybe it's somewhere else,
but a cursory search didn't find it.) Our MTA certainly doesn't enforce this
and AFAIK neither does sendmail, PostFix, Apache James, or qmail. (Exim, OTOH,
appears to.)

> 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.

There certainly should be a note saying that you need to issue an EHLO
and check the response before attaching any parameters to VRFY/EXPN. I don't
think a requirement that parameters not be accepted before an EHLO
has been issued is needed.

> (I think
> this is the topic about handshaking that Dave and Shawn have
> been circling around, but I'm not sure).

It's part of it, I think.

> > However, this brings up
> > another     issue, which is that a server that supports this
> > extension needs a way     to tell a client that doesn't that
> > it cannot return a proper response     to VRFY/EXPN without
> > that parameter being specified. A new SMTP error     status is
> > needed, but the document only defines an extended status
> > for this purpose; it doesn't specify a regular status code to
> > use.

> If we go down this path, the WG clearly needs to reexamine
> whether such a code is necessary.  I think you have made a
> persuasive case, but I can't speak for the WG.

It doesn't have to be a new code. OTOH, it needs to be a code that EXPN/VRFY
don't return for other purposes, and I think if you look at the list of
available codes a new code is needed.

> Indeed, this has all gotten sufficiently complex that I think
> perhaps the WG should reexamine its decision to handle the "VRFY
> and EXPN with possible non-ASCII responses" situation by
> parameterizing those commands rather than introducing new
> commands, say VRF8 and EXP8.  IIR, the WG did consider that
> alternative (long ago) and conclude that adding a parameter was
> the more straightforward option. But, perhaps, given the
> various complexities that have emerged, that was not the right
> decision.

I considered suggesting new commands, but given the need to specify
syntax for the new commands I don't see this as any simplier
specification-wise. In terms of implementation, a new command is actually
a somewhat more complex - the code changes are less localized, and I suspect
other implementations will be comparable in this regard.

But the minute you need some other variant on EXPN and VRFY, the alternate
command appraoch becomes the far more complex way to do it. Now, we haven't had
a specification come along that needed additional EXPN/VRFY parameters before
this one, but these things have a way of showing up once you open the door and
get people thinking about them. So I'm strongly inclined to stick with the
parameter approach.

> With other commands, such as MAIL and RCPT, we've
> already got a history of parameters and the base (821/5321)
> syntax is very clearly delimited.  By contrast, I certainly
> remember seeing VRFY followed by unquoted strings with blanks in
> them in the wild (e.g., arrangements like
>     VRFY Ned Freed
> ) and some servers tolerating them in the name of robustness or
> in memory of 821, which had
>     VRFY <SP> <string> <CRLF>
>     <string> ::= <char> | <char> <string>
>     <char> ::= <c> | "\" <x>
>     <c> ::= any one of the 128 ASCII characters,
>         but not any <special> or <SP>
>     <x> ::= any one of the 128 ASCII characters
>        (no exceptions)
> which makes
>     VRFY Dave\ Crocker
> perfectly valid.    I don't know if similar examples still occur
> and with what frequency, but...

OTOH, a lot of servers back in the days prior to RFC 2821 didn't support the
821 thing of allowing literal spances with a \ and no enclosing quotes. So this
never could be said to have interoperated. And I think the time has come to
abandon it (although I note that if you really want to continue supporting it,
the added parameter doesn't prevent you from doing so).

				Ned