Viktor Dukhovni via Postfix-users:
> On Tue, Nov 07, 2023 at 08:14:04AM -0500, Wietse Venema via Postfix-users
> wrote:
>
> > Another option would be to use the DNS resolver (Bind, unbound, etc)
> > support to manipulate zone lookups.
>
> But the OP wants a dedicated transport (for concurrency control and
> scheduling), not a change of destination IP, though in a multi-stage MTA
> setup that IP could point at a dedicated Postfix instance.
I know that, but it was not obvious to me that the OP needs to
support high volume.
It's easy enough to respect an individual provider's concurrency
limits by mapping their customer subdomains to a dedicated transport
with a limited number of delivery agent processes. That approach
may not scale to a large number of providers, but that does not
appear to be the problem at hand.
This mapping would be done after transport_map lookups, and before
the queue manager assigns a recipient to a delivery transport. A
crude implementation would try to map all recipients; a smarter
implementation would know what deliveries require MX lookups.
Postfix deliveries that may be redirectred to a provider-specific
transport based on MX namne:
smtp (i.e. $default_transport)
MX name to to transport map:
# MX name pattern Postfix transport
.mail.protection.outlook.com outlook-com
.google.com google-com
master.cf:
outlook-com .. .. .. .. .. 10 smtp
google-com .. .. .. .. .. 10 smtp
Recipient domains inside [] would not be subject to MX transport
aggregation.
This code path would have to be non-blocking so that the queue
manager is not slowed down by DNS latency. Some short-lived caching
would help.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
