RE: Mail Data termination

["Murray S. Kucherawy" <msk@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: owner-ietf-smtp@xxxxxxxxxxxx [mailto:owner-ietf-smtp@xxxxxxxxxxxx] On Behalf Of Hector Santos
> Sent: Thursday, August 18, 2011 12:32 PM
> To: ietf-smtp@xxxxxxx
> 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.