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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 20, 2002 7:25 PM > To: [EMAIL PROTECTED] > 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 > > [EMAIL PROTECTED] changed: > > What |Removed |Added > -------------------------------------------------------------- > -------------- > Status|NEW |RESOLVED > Resolution| |INVALID > > > > ------- Additional Comments From [EMAIL PROTECTED] > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
