Murray S. Kucherawy wrote:
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.
It has nothing to do with any system being constrained but one that
can cause them to have new constraints, a higher TCO and need to scale
up or out in order to satisfy what is guarantee to become new loading
profile.
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.
Whats going to happen is that implementors discovery might begin will
change the timeout after a transaction is completed to 1 minute and
zap CS clients out! I already have this Penciled in after seeing this
was causing the increase SMTP session times from what was seconds to
multiple minutes - TERRIBLE!
We spent a lot time and energy to optimized systems and the times out
were designed to accommodate client/server handshaking processing and
networking delay needs. It was not designed to allow a client to hold
hostage communication channels chewing up CPU time and system
availability needs.
No matter what limit is set on total receivers, if the modus operandi
is the CS design, you will reach limit exhaustion far quicker. This
can cause a higher potential for initial outbound failures on clients
sending out mail, delays transactions, etc, etc.
--
Sincerely
Hector Santos
http://www.santronics.com