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

[Ned Freed <[e-mail]>]

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

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

You've gotten this exactly backwards. Yes, VRFY and EXPN accept names as
arguments, not addresses. The problem is this specification changes them to
accept addresses as well, which is both unnecessary and out of scope.

> Was this not the reason Ned to allow blanks (whitespace) and unquoted
> strings?

Sure, but it doesn't change the fact that the only changes this WG is supposed
to be making is to add support for UTF-8. Even if it were a good idea to change
the syntax of VRFY or EXPN from what's in RFC 5321  either to accept addresses
or to go back to the syntaxes that were allowed in RFC 821, doing so is not in
scope. If you want to argue about changes in that area, the place for that is
the ietf-smtp list.

> If you remove this from the spec, this functionality would be
> lost, I don't really see a reason to lose something that works.

Please reread my original message. Again, you have this exactly backwards -
currently the EAI specification makes an unnecessary and out of scope syntax
change change from what's in RFC 5321 that goes far beyond supporting utf-8.
Either form of alternative ABNF I proposed returns us to RFC 5321 syntax plus
utf-8.

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

That's exactly what John is saying. The problem is you can't send a new
parameter on VRFY/EXPN and expect it to work until you know it's safe to do so.
And the way to know that is to look at the EHLO response.

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

Which is what is being proposed, and AFAICT is entirely noncontroversial. The
specific issue being discussed is whether or not a server MUST refuse to allow
the extended form if it hasn't gotten an EHLO. I see no point in containing
servers in this fashion.

				Ned