On 17 Aug 2011, at 01:20, Hector Santos wrote: > IMTO, no matter how you wish read this, NO QUIT means a cancellation because > otherwise the only other way to end a SMTP session is for the client to close > the socket connection. So what this would indirectly suggest the SMTP specs > implicitly says:
How did you get there from here? > There is two ways for a client to end a SMTP session: > QUIT or DROP THE LINE Which is absolutely true. Both end the session. One does it politely and correctly. The other does it rudely (MUST NOT, it's bad manners) and incorrectly. The intent is to benefit servers, but a server would not be robust to fail in the absence of QUIT. FWIW: Postfix still offers a choice of whether or not to wait for the response to QUIT and the TCP close from the other end before closing itself. The default is do not wait, because Postfix recognises the simple truth that implementations process events in the order they were buffered, which means that the action of responding to QUIT will result in the closure by the server of the connection anyway before any further attempt is made to read from the socket for an end-of-file condition. > and that does not jive with the written words: > > The sender MUST NOT intentionally close the transmission > channel until it sends a QUIT command, > > I can understood your position, very clearly, but in general, I don't think > this is a good way to do robust client/server communications (allowing drops > to signal message transaction completion). It opens the door for unsureness. How did you get here from there? :-) I think you've jumped a conclusion somewhere. Only end-of-data indicates message completion. Closure of the connection would mean the transaction was aborted. Reset would mean transaction was aborted. QUIT would mean transaction was aborted. Any action causing the SMTP interaction to cease - either of QUIT or TCP close, timeout, fail - would mean session was over. What do you do when MAIL is issued following end-of-data - submit the outstanding job, or queue it for QUIT? Neither is correct, of course ... > Keith Moore wrote: >> On Aug 16, 2011, at 7:48 PM, Hector Santos wrote: >>> SM wrote: >>>> At 15:03 16-08-2011, Keith Moore wrote: >>>>> sorry, I misunderstood what was being suggested. if the server gets >>>>> DATA followed by a message (or a message fragment) followed by CRLF.CRLF, >>>>> it should accept the message (or fragment) and deliver it. no matter >>>>> what else follows, or doesn't follow, during the same SMTP session . >>>> Yes. The SMTP server mentioned that it is accepting the message (up to >>>> the end-of-data terminator. Rejecting the message is not an option once >>>> the message has been accepted. >>> Hence the dilemma. It wasn't an valid RFC5322 message and the issue is >>> exasperated when it was DKIM signed and now recorded as a failure. Never >>> mind the fact QUIT (or a new transaction command) is an SMTP requirement >>> before the transaction is considered complete for delivery. >> Where do you get that idea? RFC 2821 doesn't require this. It only >> requires that the server not close the connection until it sees a QUIT. (It >> even says that clients SHOULD send a QUIT, implying that things should still >> work if they don't.) Cheers, Sabahattin _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
