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.
--
Viktor.
