> On Oct 2, 2017, at 7:13 AM, Wietse Venema <wie...@porcupine.org> wrote:
>
>> 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?
>
> If a domain has no 'popularity' stats, apply the concurrency limit
> to the domain name only. Once a domain has a delivery request in
> progress, and there is another request queued for that domain, apply
> the concurrency limit to the domain name and to any popularity stats
> associated with the domain (assume that mail exchanger lookup results
> will be consistent with available popularity stats). Conceptually,
> domain popularity stats are pointers to mail exchanger popularity
> stats. They are updated when the delivery agent sends a hint, and
> automatically decremented when the queue manager to delivery agent
> connection is closed. One in progress, a delivery request is not
> preempted.
This is a best-effort model, which approximates a per-MX concurrency
limit when when the mail stream contains frequent messages to a set
of domains for which the associations with the underlying MX hosts
don't time out between messages. Greylisting also makes this more
complicated, since on a first delivery attempt all the MX hosts will
tempfail. Equal-weight MX hosts will make it difficult to apply the
concurrency limit correctly, since we don't know which MX host will
be chosen by the delivery agent... Perhaps I am making this too
complicated, but I don't yet see how this comes together.
Mind you, if we're not about to start building this any time soon,
the design discussion is perhaps best deferred.
--
Viktor.
