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:
http://cr.yp.to/smtp/quit.html
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."
--
Sincerely
Hector Santos
http://www.santronics.com