Patrik Rak:
> > I am not that stupid. Just like postscreen(8) handles up a LIMITED
> > number of connections at any point in time, so would prescreen(8)
> > handle only a limited number of delivery requests at any point in
> > time, giving back pressure to qmgr(8).
> >
> > The main benefit is that presecreen(8) parallizes the waiting
> > for DNS lookup, TCP handshake, and server greeting.
>
> That's exactly what I had in mind, too - the thousands I mentioned
> was the (upper) limit of what prescreen could IMO handle. It may
> be lower, but there will definitely some limited number.
>
> My assumption was that it will be bigger than the amount of delivery
> agents available (if it was about the same, it would make little
> point). But then I can't see how you can prevent opening too many
> connections against fast servers, unless you risk opening too
> little connections against the slow servers at the same time?
The qmgr(8) concurrency scheduler limits the concurrency per nexthop.
That does not change when prescreen is inserted between qmgr(8) and
smtp(8) processes.
For each nexthop:
number of qmgr-prescreen connections + number of qmgr-smtp connections
<= concurrency limit
Wietse
