How many simultaneous connections does SendMail allow/open when relaying new (and deferred) messages to a common downstream MTA?

Question

I have several Sendmail servers which relay a lot (hundreds of thousands) of journaled emails to a downstream archive repository via SMTP. All of these emails have the same recipient domain (lets call it "fooarchiveproviderdomain.com"). On my side, I have a simple route set in /etc/mail/mailertable for the archive domain:

fooarchiveproviderdomain.com    esmtp:[1.1.1.1]:[2.2.2.2]

Lately, I've been noticing that the primary downstream MTA (1.1.1.1 in my example above) will get overloaded and sometimes not send back a banner greeting in a timely manner. On my side, Sendmail will throw an error in maillog like:

timeout waiting for input from [1.1.1.1] during client greeting

After the timeout, I see the system sending to the backup route (2.2.2.2 in my example above) and immediately getting accepted.

I'm reasonably certain that this is related to load since these timeouts occur more during peak business hours. That being said, I want to understand how many connections my server is initiating when processing new emails and previously queued messages, all intended for the same domain.

I think that sendmail retries queued messages in single file right? So if I have, say, 10000 emails deferred messages... the queuerunner won't initiate 10000 simultaneous connections... it'll just issue one?

I also think that new incoming messages that arrive in separate SMTP sessions get handled separately right? So if, say, a sendmail box gets 15 separate new messages, each will be handled by a separate sendmail child daemon which will initiate it's own separate SMTP connections to the downstream MTA?

Is there a means to restrict simultaneous downstream connections without impacting the amount of incoming connections my server can handle?

Answer 1

You may

1) selectively skip "at once" delivery attempts using dsmtp mailer
(they produce "one message per one smtp session" deliveries) .

mailertable entry:

fooarchiveproviderdomain.com    dsmtp:[1.1.1.1]:[2.2.2.2]

2) Use FEATURE(queuegroup) to select custom queue group for deliveries to fooarchiveproviderdomain.com

3) choose from multitude of options how to fine tune deliveries from the queue groups e.g. via queue group parameters R=2 (two parallel runners = two SMTP session per queue group run) and I=12m (process messages in queue group every 12 minutes)

You may lower delays without "at once" delivery attempts using persistent queue runners.
https://www.safaribooksonline.com/library/view/sendmail-cookbook/0596004710/ch09s06.html

Comment: changing HOW the messages are sent by "journaling app" is another option.