I'm sorry if I am passionate about this. But this explains what I
have been seeing this year.
This past year, I have been seeing an unexplained increase in the
average time of SMTP sessions to around 4.5, 5 or more and we spend a
lot of time adding timing profiles to see where the SMTP processing
was chewing these greater SMTP times. I thought it as just stupid
clients that didn't have robust logic to wait on signals before they
issued QUIT. No, it seems to be these CS clients and I don't like it.
This explains why FACEBOOK waits exactly 5 minutes for each
transaction it sends. I have not seen it a Facebook transaction that
has two or more transactions but I guess that depends on the frequency
of comments. This is terrible!
http://www.winserver.com/public/spamstats.wct
August 7.7 mins
July 4.7 mins
June 4.0 mins
May 8.3 mins
etc. going back 1 year to 2010
August 14 secs
July 12 secs
Geez, enough said - Sendmail CS logic is a problem. It adds all kinds
of internet and networking pressures, receiver server availability,
scalability problems - a problem across the board, and the greater
this practiced is implementation, the worst the problem is going to
get, perhaps to the extend the SERVER will take action across these CS
clients.
There are robust ways to solve the "Same Destination Server"
redundancy issues - the CS way is a one-sided selfish method that
creates new problems for receivers.
Client/Server idle times were meant for clients to wait on server
responses, not to sit there idle doing nothing within its next job to
come in!
Murray S. Kucherawy wrote:
-----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: Thursday, August 18, 2011 12:32 PM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: Re: Mail Data termination
First, a server may have Receiver Loading Limits and a client with a
tenacity to take up more CPU time than it needs can get it flagged. To
use CS for the purpose to reduce its redundancy without considering
the load it places on receivers is a very selfish engineering
consideration. Chewing up a channel unnecessarily for 5 minutes
disallowing other clients connection access increases system available
and scalability problems.
Second, it uses a dangerous presumption that a server is FIXED on
using 5 minutes for idle times. 5 minutes is a SHOULD, not a MUST and
for a client to DEPEND on a SERVER using 5 minutes is short-sighted
engineering.
The five-minute timeout is a SHOULD. If you're resource constrained, I would
argue that issuing a 221 to the most idle open connection and closing it down
so the resources can be re-used is just fine.
I don't think the practice of connection caching is particularly selfish when
compared to the cost of having the connection torn down and then re-established
with some frequency, when it's generally much cheaper for both the sender and
the receiver to just leave it open.
This should be done using an SMTP extension where a server can expose
server timeouts perhaps and willingness to allow a client to sit idle
redundantly and repeatedly.
Or it can simply impose an idle time that's more strict than what 4.5.3.2.7 of
RFC5321 says, understanding that one needs to be pretty careful about doing so.
--
Sincerely
Hector Santos
http://www.santronics.com