@lbutlr:
> On 2018-03-15 (09:01 MDT), Viktor Dukhovni <postfix-us...@dukhovni.org> =
> wrote:
> >=20
> > Caching open TLS connections in the smtp(8) delivery agent for
> > reuse by scheduling repeated deliveries to the same delivery
> > agent runs into complex scheduling difficulties. The presence
> > of open connections don't, and should not IMHO alter scheduler
> > priority. Messages should still leave in approximately FIFO
> > order (subject to (n)qmgr's periodic preemption of messages that
> > split into many envelopes).
>
> Isn't the issue a short-term one, where for example, a thousand mails =
> hit the queue and 400 are for gmail.com and the desired behavior is to =
> send those 400 in one connection whilst the others get queued up via a =
> separate process?
>
> This could be done with a queue scheduler that pre-processes the queue =
> when "a lot" of messages get queued for sending and then sorts them =
> based on destination and the destinations that exceed some pre-defined =
> threshold get shunted to a separate process.
>
> That seems like it is doable, if not simple. Heck, it could even only =
> work if the messages were queued in order. Something along the lines of =
> "I'm connected to big.example.com, is the next message to =
> big.example.com? It is? OK, reuse this connection."
Currently, the Postfix scheduler will read all your 1000 recipients
from the queue (the read limit is 20000). Currently, Postfix will
deliver all your 400 to gmail.com AND AT THE SAME TIME deliver 600
to other destinations.
With your proposal, Postfix will deliver 400 to gmail.com (leaving
many Postfix delivery agents unused) and ignore those 600 until the
400 are delivered. That would be a regression.
Wietse
