CentOS 5.x | SendMail 8.14.4

I'm trying to wrap my mind around how Connection Caching works in Sendmail.

I'm experiencing some connection issues with some remote mail hosts that we communicate with frequently and we're seeing errors like:

dsn=4.0.0 stat=Deferred: Connection timed out with <FQDN>

As part of the troubleshooting process, my firewall guy would like to know if my SendMail server is using a stateful connection only.

Initially, I thought it wasn't... but then I recalled the Connection Caching feature. I checked /etc/mail/sendmail.cf and confirmed that the following options are present:

O ConnectionCacheSize=2
O ConnectionCacheTimeout=5m

To me, that means that SendMail will keep up to 2 SMTP connections open (for 5 minutes each) in case more messages need to go there.

My question is: How does SendMail decide which connections are cached? Is this purely on a first send, first cached basis? Or is there a more complicated logic behind the caching mechanism?

  • Are the remote sites virtual machines running Plesk? Does email to them always gets deferred or only sometimes? If sometimes it gets delivered, does it take a different route through another MX? – adamo May 2 '13 at 13:13
  • @adamo the remote sites are predominantly handled by microsoft (hosted exchange, Outlook, etc). I'm not sure if we just happen to send to them more frequently or if there's something specifically problematic between our environment and theirs. In most examples, it's a single MX with different alternating A records. – Mike B May 3 '13 at 17:05

AFAIK In typical sendmail configuration connection cache is not used for initial/first delivery attempt (maybe except when message to too many recipient is splitted into many messages). In such configurations it is used when sendmail retries delivery of queued messages.

IMHO In typical light load email site over 95% of outgoing messages may be delivered by initial "at once" delivery attempt.

IMHO bigger email sites may consider using separate queue groups for topmost outgoing destinations and avoiding initial "at once" delivery attempt (usually it sends one email over one SMTP connections.

  • Persistent queue runners may reduce delays in such "no at once delivery" configurations.
  • custom mailer definitions may skip "at once" delivery attempts (F=e expensive flag) and limit number of messages sent over single smtp connection (m=)

Queue Groups (V8.12 and Above)

  • I'm revisiting this topic as it came up recently again (for a different scenario). So just to be clear, is only used during retry attempts and in those cases, cache slots are filled up on a first-come, first-served basis? – Mike B Sep 18 '14 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.