On Sat, Sep 30, 2017 at 09:18:44AM -0400, Wietse Venema wrote:
> > When the concurrency limit for "[addr]:port" permits, the queue
> > manager would call smtp(8) again (with the original delivery request
> > and the list of already used addresses, and smtp(8) would attemt
> > delivery to the first address, and if still more recipients remain,
> > refresh the MX host address list, and send back a now 1-longer list
> > of used addresses, and a new next address to try (that is not among
> > those already tried).
> >
> > This would be very complex, I don't expect this to be implemented
> > in the near term.
>
> It could be simple. Suppose there is a 'popular site' counter table
> (the opposite of the 'dead site' list) which is indexed by some
> idea of 'destination' and which is updated in real time as delivery
> agents announce what they are doing. To determine if a next-hop has
> reached its concurrency limit, compare the configured limit for the
> transport with the appropriate 'popular site' count.
Not sure I understand. An SMTP nexthop corresponds to an unknown
(to the queue manager) set of destination MX hosts. Lots of domains
have various google, outlook.com, ... MX hosts, but there's no way
to know this without doing the MX lookup first. How do you propose
to avoid making more than the destination concurrency of connections
to a Gmail or Microsoft, ... MX host?
--
Viktor.
