[Top] [All Lists]

Re: The purpose of QUIT

2011-08-29 16:27:19

Keith Moore wrote:
On Aug 28, 2011, at 3:59 PM, Hector Santos wrote:

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

I don't remember much of the DRUMS discussion.  But it may be helpful
to remember that SMTP is not inherently tied to TCP, and SMTP has been implemented over X.25, DECnet, and I'm sure some other protocols. An explicit QUIT is useful in the cases where the underlying transport doesn't have a clean "close" operation.

This has always been an infrastructure issue, especially under X.25 where costly upgrades from PADS to "Smart" PADS was required to allow interactive applications to work better. The smart pads were able to auto negotiated the channel/line settings and that also included how vendors developed their virtual comm I/O drivers, proper cabling was always important, etc.

So it always was a file/data transfer protocol issue having an "EOD" concept because "drops" were a reality. For SMTP, that was covered with its EOD response.

Anyway, reading DRUMS rev0 to RFC2821, you can see how it evolved during 1995-2000 - the struggles and conflicts emerging. TURN was deprecated with reflected the dual roles concepts of client/server protocols, and less need for hubs to hold mail (I see a security reason, but this was already becoming an old concept). You can see how "Queuing Strategies" evolved to "Retries Strategies" but continued to mixed two related but different functionalities and you can see there was a debate regarding QUIT. D.J. Bernstein had this to say:

   Most implementors agree that QUIT is useless, and support a
   transition to a world without QUIT. Some servers pester their
   system administrators when they don't see QUIT; I recommend that
   they change this behavior. Someday clients will no longer send
   QUIT. Eventually servers will no longer need to support QUIT.

The prediction was not true with RFC22821 compliant clients always issuing QUIT. But I worry that it can be true once the higher consumption of idle time is realized more with the growth of large volume emailer like FaceBook and Google and others continue to grow.

Anyway, I read other notes about the pervasiveness of Sendmail so I believe that the main push for QUIT was to make sure the the SERVER does not drop the line and allow the client to drive the server for holding for mail. I believe if this purpose was explicitly stated, then there would of been consensus problem with many, like D.J. that would of fought harder for a no QUIT or perhaps, it could of provided people an "Ah HA, I see now why it is needed" too.

That is where I think we are at today. We need to spell it out why a QUIT requirement is needed - to assist clients to hold for mail. This will help the larger emailers and receivers to better prepare for it. Otherwise, I can see more implementators simply taking matters into their own hand. I don't like the idea of offering a smaller idle time to pull the rug from under the feet of the clients that don't do the holding efficiently.

I even think that the "Retries Strategies" section should be split into two:

    Queuing Strategies
    Retries Strategies

They are really two different ideas, related but fundamentally different.

and the we need to add more text in "Receiver Strategies."


Hector Santos

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