Viktor Dukhovni:
> On Fri, Sep 29, 2017 at 02:35:14PM -0400, Wietse Venema wrote:
>
> > > I send my emails via different gateways based on my transport file. Many
> > > domains, however, use the same email providers, such as outlook or
> > > gmail. Is there a way to check the MX records before the email is sent
> > > and transport it using a specific gateway?
> >
> > Not yet. The scheduler would have to ask a delivery agent to 'resolve'
> > the next-hop address and then it would have to wait until the
> > delivery agent produces its answer. If multiple MX hostnames resolve
> > to the same IP address, we'd have the question of how to verify
> > server's TLS certificate - all the MX hostnames that resolved to
> > that IP address?
>
> Perhaps the request is to somehow limit destination concurrency by
> destination MX rather than destination domain, more than avoiding
> envelope splitting. This is still difficult because we don't know
> which MX host will actually be used once the mail is handed off.
>
> Also, by the time concurrency limits permit access to a pre-resolved
> destination, lots of time may have passed, and the DNS TTLs long
> expired!
>
> Many domains have a dead primary MX, and working secondaries, how
> would we schedule to avoid overloading the secondary? We'd need
> to change smtp(8) to implement two separate service requests, a
> resolution request and a delivery request.
>
> The modified smtp(8) would do connection re-use ahead of anything
> else, but absent a cached connection, it would just resolve the
> destination and return the envelope to the queue manager to re-queue
> for the first "[addr]:port" on the list and the (initially empty)
> list of addresses already tried.
>
> 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.
Wietse
