-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Hector
Santos
Sent: Monday, August 22, 2011 2:23 PM
To: SMTP Interest Group
Subject: Re: productivity?
For those interested, if basic laws of operations research, physics,
science and Thermodynamics isn't good enough, then Believe Sendmail!
http://www.sendmail.org/~ca/email/doc8.12/op-sh-4.html
The ConnectionCacheTimeout ( K) option specifies the maximum time
that any cached connection will be permitted to idle. When the idle
time exceeds this value the connection is closed. *This number should be
small (under ten minutes) to prevent you from grabbing too many resources
from other hosts. The default is five minutes.*
But that's the RFC5321 default anyway. So if you're holding that up as the
Right Way, it would seem you agree no change is actually required.
An SMTP extension that tells a server how many
sockets/threads/processes/whatever to allocate seems like a very convenient
denial-of-service attack to me. It's the same discussion we had with the SIZE
extension way back when. The real use of it would be "no, I can't support that
many new connections from you right now," although you've already established
the one you have, so that's just weird.
I agree with Dave that if there's some useful thing we could document out of
this discussion, we should. But at the moment I'm having trouble seeing what
that might be. It's certainly true that a client that wants to be selfish
could open any number of connections and hold them open, replacing any the
server closes, regardless of what we put in any standards track or BCP
document. So we're only talking about "law-abiding citizens" here, and I don't
think MTAs implementing connection caching have any reckless or malicious
intent behind those designs, but rather are trying to improve the throughput on
both sides, and probably did some testing of the idea before rolling it out.
So far the industry as a whole hasn't found it to be a problem (which to me
means it's possibly even a benefit).
If someone's really keen to do so, some comparisons between running a queue
with connection caching and running the same queue without connection caching,
monitoring both the client and the server for total cost, would be a good place
to start.
And now, if I may borrow from old schoolyard antics: NOT IT!
-MSK