Paul Aviles wrote:
> In a busy server with thousands of outbound connections, is it possible to
> somehow group those connections better by domain? IE, make sendmail realize
> that there are a bunch of messages for domain A and if possible send those
> with one connection to the respective domain?
>
> Regards,
>
> -pa

>From doc/op

4.10. Connection Caching

When processing the queue, sendmail will try to
keep the last few open connections open to avoid
startup and shutdown costs. This only applies to IPC
and LPC connections.

When trying to open a connection the cache is
first searched. If an open connection is found, it is
probed to see if it is still active by sending a RSET
command. It is not an error if this fails; instead,
the connection is closed and reopened.

Two parameters control the connection cache. The
ConnectionCacheSize (k) option defines the number of
simultaneous open connections that will be permitted.
If it is set to zero, connections will be closed as
quickly as possible. The default is one. This should
be set as appropriate for your system size; it will
limit the amount of system resources that sendmail
will use during queue runs. Never set this higher
than 4.

The ConnectionCacheTimeout (K) option specifies
the maximum time that any cached connection will be
permitted to idle. When the idle time exceeds this
value the connection is closed. This number should be
small (under ten minutes) to prevent you from grabbing
too many resources from other hosts. The default is
five minutes.

And also from doc/op

QueueSortOrder=algorithm
[no short name] Sets the algorithm used for
sorting the queue. Only the first character
of the value is used. Legal values are
"host" (to order by the name of the first
host name of the first recipient), "file-
name" (to order by the name of the queue
file name), "time" (to order by the submis-
sion/creation time), "random" (to order ran-
domly), "modification" (to order by the mod-
ification time of the qf file (older entries
first)), "none" (to not order), and "prior-
ity" (to order by message priority). Host
ordering makes better use of the connection
cache, but may tend to process low priority
messages that go to a single host over high
priority messages that go to several hosts;
it probably shouldn't be used on slow net-
work links. Filename and modification time
ordering saves the overhead of reading all
of the queued items before starting the
queue run. Creation (submission) time
ordering is almost always a bad idea, since
it allows large, bulk mail to go out before
smaller, personal mail, but may have appli-
cability on some hosts with very fast con-
nections. Random is useful if several queue
runners are started by hand which try to
drain the same queue since odds are they
will be working on different parts of the
queue at the same time. Priority ordering
is the default.