The purpose of QUIT

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.
--
Sincerely

Hector Santos
http://www.santronics.com