[Top] [All Lists]

Re: Mail Data termination

2011-08-18 22:33:45

On 18 Aug 2011, at 18:22, Murray S. Kucherawy wrote:
-----Original Message-----
From: Tony Finch [mailto:fanf2(_at_)hermes(_dot_)cam(_dot_)ac(_dot_)uk] On 
Behalf Of Tony Finch
Sent: Thursday, August 18, 2011 4:14 AM
To: Murray S. Kucherawy
Cc: ietf-smtp(_at_)imc(_dot_)org
Subject: RE: Mail Data termination

Murray S. Kucherawy <msk(_at_)cloudmark(_dot_)com> wrote:
One of the more ubiquitous MTAs out there has a feature called
"connection caching" where it will keep some fixed number of outbound
SMTP connections around, cycled using an LRU method, in case a new
message arrives that is routed to a recent destination to avoid the cost
of making a new connection and doing the initial SMTP negotiation.

I believe Postfix and Exchange can do this.

And I was referring to Sendmail.

Sendmail is certainly a very interesting animal.  Its sorting mechanisms are 
fairly primitive, which means it has no way to identify when it's safe for any 
given client (whether running part of the spool or invoked just now for 
delivery) to close all sessions it has cached.  So it waits until all jobs are 
done before doing so.  If the administrator wants to get maximum SMTP 
efficiency by having as many messages as possible be sorted by as few clients 
as possible at the expense of parallel deliveries, he might choose to run a 
very small number of delivery clients to run queues, and then the caching could 
last quite a while during which unrelated messages for different hosts drain.  
(If you've ever tried to run a mailing list with Sendmail you've probably seen 
the script that breaks lists up by hostname so this process can be somewhat 

The more SMTP clients there are that do this, the more likely it is that a 
server demanding QUIT before scheduling a delivery attempt will lose mail.

I don't think it's a good idea.

Just checked, Sendmail is sending RSET to check if the connection is still 
running.  Postfix does that too.  So I hope RSET is not similar to QUIT in 
initiating the mail delivery following each transaction.

Here's the details from Postfix:

I can certainly understand the need to finish quickly, but I believe the 
balance is in favour of a small cache time.  If nothing's happening, it's no 
worse than having to need a connection that's just been torn down and must be 


<Prev in Thread] Current Thread [Next in Thread>