[Top] [All Lists]

The purpose of QUIT

2011-08-28 15:15:48

In the 1982, but still currently the official SMTP standard, STD10 (RFC821) has QUIT as a SHOULD. In the 2000 document RFC2821 and the newer (2009) RFC5321, it was made into a MUST.

I would like to hear what was the (DRUMS) thinking towards making it a MUST.

Other than the general robustness and gracefulness it provides a client/server handshake, it plays no rule in the mail delivery or cancellation. Clients and servers can drop with any mail harm. I can only see one technical reason for that will benefit the SERVER or CLIENT and thats dealing with a socket port TIME_WAIT TCP state. In short, he who closes first, will move the port in TIME_WAIT and unless the port is prepared for reusability, it can not be used again into TIME_WAIT expires.

Under STD10, it helped for a faster throughput because the client can just send, get the 250 and immediately drop. Since the client dropped, the server-side port is not in TIME_WAIT and it better scale the server in regards to available ports. However, the client may be in a disadvantage in regards to scaling available ports.

Under RFC5321, with QUIT, we are not really sure who benefits depending on the software on both ends waiting for closure by the other side. So if the client issues a QUIT, it can wait for the SERVER to close the socket. Or the Server sees the QUIT and waits for the client to close the socket. Both sides will need to add a sanity timeout check to close the socket if the either end doesn't close it first - a state machine contention conflict.

Now when we throw in the idea of intentional delays, "Online Hold for New mail" or Connection Sharing, it adds a new purpose for the server to wait for a QUIT.

Neither ideas are documented in RFC5321 and maybe in the classic IETF wisdom of leaving things open ended, it was left unmentioned and just say NO SIDE SHOULD NOT DROP the connection until QUIT is negotiated.

However, it does seem after all these years that there are many repercussions, ambiguity, clearly ways to deal with abusers, loosely followed parts of the SMTP spec, higher complexity for scale designs between an old era and new era all centered around this basic issue of timeouts, delays, socket closure and QUIT that it may be time to document the reasons why the QUIT requirement is desirable or at least better define its purpose.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>