Centos – Why Is There A Delay In The SendMail SMTP Banner Greeting When Primary DNS Server Is Unavailable

Kyle,

** I'm by no means a sendmail expert **

In your use case, the need for sendmail to accept / queue up the messages asap is key(batch processing?). If you haven't, take a look at sendmail options: QueueLA and RefuseLA - Queue Load Average and Refuse Load Average. If you are really bombarding sendmail your load averages will go through the roof quickly and you'll hit RefuseLA which might be part of your timeout issue. You may want to increase RefuseLA (if you haven't already).

To keep sendmail from doing too much at once (receiving and transmitting) lower your QueueLA. A lower value of QueueLA will put sendmail into queue only mode so sendmail will focus on queuing work and save the transmit / sending work for later. A low QueueLA and high RefuseLA will result in the system queueing up large amounts of mail(disk space) then begin sending it out after the load falls below QueueLA.

For normal sendmail configs it is worth noting that QueueLA should not be much lower than RefuseLA, and possibly it should be very slightly higher.

Delivery mode 'q' is an extreme version of a low QueueLA setting, where you'd have to somehow initiate a delivery command to begin outbound message transfer.

Resource: http://www.brandonhutchinson.com/QueueLA_and_RefuseLA.html

According to this thread, the fallback feature tls_failures was implemented in this patch. Apparently this will use plain text automatically after a certain number of TLS handshake failures.

Note: this patch is integrated in 8.16 (at least available as snapshot)

As of this post, 8.16 is not yet released, so for now you will have to use /etc/mail/access or /etc/mail/access_db as Seth suggested, and be sure to rebuild the .db using makemap hash /etc/mail/access < /etc/mail/access

As for security risks of using tls_failures globally; considering that this is opportunistic TLS to begin with, I think that refraining from using this new option would only help in some really fringe cases where the recipient mailserver is temporarily reconfigured and later corrected.