On Thu, Sep 30, 2010 at 11:07:23AM -0700, Claus Assmann wrote:
> On Thu, Sep 30, 2010, Victor Duchovni wrote:
>
> > Do you have a tcpdump capture? From the above it sounds like HELO is
> > sent before the 220 banner. That's a protocol error.
>
> Is it?
>
> 4.3.1 Sequencing Overview
> ...
> One important reply is the connection greeting. Normally, a receiver
> will send a 220 "Service ready" reply when the connection is
> completed. The sender SHOULD wait for this greeting message before
> sending any commands.
>
> So this is "just" a SHOULD, not a MUST, hence not a protocol error
> per se. Any real MTA will obey the SHOULD requirement of course.
And how at that point does the SMTP client not get out sync with the SMTP
server? If it does not wait for 220, it will misread the banner as the
HELO response! Unless you are suggesting that pipelining is implicitly
allowed in that context.
You left out the first part of 4.3.1:
4.3.1. Sequencing Overview
The communication between the sender and receiver is an alternating
dialogue, controlled by the sender. As such, the sender issues a
command and the receiver responds with a reply. Unless other
arrangements are negotiated through service extensions, the sender
MUST wait for this response before sending further commands. One
important reply is the connection greeting. Normally, a receiver
will send a 220 "Service ready" reply when the connection is
completed. The sender SHOULD wait for this greeting message before
sending any commands.
The half-duplex nature of the protocol is clearly stated, and the fact
that exceptions to this are only allowed via service extensions. The
"SHOULD" here is unfortunate. I can see a client sending "QUIT" before
the banner if a timeout elapses, but proceeding to HELO before 220 is
not a reasonable interpretation of 4.3.1.
Of course a client can at any time abandon the connection and send a
premature "QUIT" (if not in the middle of data transfer). So the special
case treatment of 220 in 4.3.1 is a specification bug.
--
Viktor.
