RE: DO NOT REPLY [Bug 15579] - SMTP Handler DATA buffering issu e

["Labib Iskander, Marcus" <ml...@cm4all.com>]

This interpretation is not correct. 
Of course the client violates the smtp protocol specification when not
waiting for the server to respond to a command before sending the next, but
on the other hand the server is required to send exactly one response
following a single command. you can either advocate to interprete the
command sequence as one command, it is an invalid one then. or you and
interprete it as a sequence of commands which is a violation of the rfc.
in the first case it would be natural to send a 500 response.
in the second case you have to differ between knowing that there is more
data in the buffer and not knowing it while beginning to process the first
command which is recognized.
While knowing there is more input, you know that a violation occured and
even though the rfc doesn't say so a failure sounds like the most sensible
reaction.
If you didn't know (whether the input arrives while processing the first
command or you just did not check) you should process that first command. A
very strict server could of course check for no more data having arrived
while processing, before sending the output, but there is no way knowing
that there is nothing on the way while you send your response.
In my opinion the most natural way to handle the problem is to read as much
from the input as you need and never mind whether the next command from the
client has been issued anticipating your response or after arrival of your
response.
Just to speak of conformance.

Cheers,
  Marcus

> -----Original Message-----
> From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: Friday, December 20, 2002 7:25 PM
> To: james-dev@jakarta.apache.org
> Subject: DO NOT REPLY [Bug 15579] - SMTP Handler DATA buffering issue
> 
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15579>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15579
> 
> SMTP Handler DATA buffering issue
> 
> farsight@alum.mit.edu changed:
> 
>            What    |Removed                     |Added
> --------------------------------------------------------------
> --------------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |INVALID
> 
> 
> 
> ------- Additional Comments From farsight@alum.mit.edu  
> 2002-12-20 18:24 -------
> This is not a valid bug.
> 
> SMTP is a request/response protocol.  Feeding it a set of 
> request messages a 
> priori is a violation of the spec.  In this specific case, 
> the message data is 
> being fed in before the 354 reply is issued.  If, for 
> example, the server were 
> to issue a 5xx reply rather than a 354 for whatever reason (resources 
> unavailable, etc.) this would manifestly put the client in 
> violation (client 
> MUST NOT send data if a 354 is not issued).
> 
> --
> To unsubscribe, e-mail:   
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: DO NOT REPLY [Bug 15579] - SMTP Handler DATA buffering issue

["Noel J. Bergman" <no...@devtech.com>]

> In my opinion the most natural way to handle the problem is to read as
much
> from the input as you need and never mind whether the next command from
the
> client has been issued anticipating your response or after arrival of your
> response.

Actually, if you want to look at the issue THAT way, RFC 1985 and 2197
address queuing and pipelining behavior.  I suggest that we revisit this
topic in the light of those RFCs.

ref: http://jakarta.apache.org/~pgoldstein/rfclist.html

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>