Re: [apps-discuss] [EAI] RFC5336 and VRFY/EXPN

[Alexey Melnikov <[e-mail]>]

[With my MTA server developer hat on, not speaking as an AD]

Ned Freed wrote:

>>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.
>
Isode M-Switch doesn't enforce this either.

>(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.
>  
>
+1. Maybe the client has cached EHLO response from a previous connection.

>>(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.
>  
>
+1.

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