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

["Al Costanzo" <[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.

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.

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

Only my humble opinon.

-Al Costanzo





----- Original Message ----- 
From: "Ned Freed" <[e-mail]>
To: "John C Klensin" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Ned Freed" 
<[e-mail]>; <[e-mail]>; 
<[e-mail]>
Sent: Sunday, December 26, 2010 5:53 PM
Subject: Re: [apps-discuss] [EAI] RFC5336 and VRFY/EXPN (was: Re: apps-team 
review of draft-ietf-eai-rfc5336bis)


>> 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
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>