On Tue, Mar 26, 2024 at 05:22:52PM +0000, Colin McKinnon wrote:
> > What kind of "load balancing"? Why won't MX records do? For uneven
> > weights, you can even use SRV records:
>
> I'm trying to setup load balancing across a cluster of relays for a
> SAAS application. There's several problems I was hoping to solve:
>
> 1) distributing workload
> 2) IP warm up when adding nodes
As you note below, SRV records with suitably chosen weights can handle
this fine. The DNS server serving the SRV zone can return highly
dynamic answers with short TTLs (say 30–60s).
> 3) avoiding dilution effects of spreading the workload (I only send a
> few emails to hotmail, for example)
Not sure what that means.
> 4) separating out very badly performing receiving MTAs
Connection caching takes care of this, because more responsive MTAs
handle more of the load, if the delay is felt during the SMTP mail
transaction.
> 5) adapting workload distribution according to host availability and
> current health (load, free memory etc)
This can be an input into the authoritative server serving the SRV
records, but I am sceptical that this is particularly important for
mail.
> Blindly distributing the traffic at the TCP level works for 1&2 but
> DNS is too slow for 5, while 3 & 4 need information about where the
> email is going.
That's fine, the SRV records can be keyed by destination domain.
> Mostly large block lists (you expect users to actually manage their data?).
Some call that listwashing...
> > That's what sender_dependent_default_transport_maps is for.
>
> Policy server doesn't work in this context.
It does not, and note that while FILTER actions in policy server
responses will trump all other transport decisions, they're "sticky"
for the lifetime of the queued-message, so if it is not delivered
immediately, the same override will be still in place up to days
later, so not at all particularly dynamic once a message sits in the
queue for a while. Here SRV lookup has the advantage of being fresh
for each delivery attempt.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
