On 2012-06-28 email builder wrote: >>> Well, it looks like I could do >>> >>> relay_domains = example.com >>> >>> transport table: example.com relay:other.com >>> >>> I have to use "other.com" in the transport because I need to use >>> DNS-based "load balancing" of multiple SMTP servers on the backend, >>> but the relay is listed as the primary MX for example.com (my >>> understanding is that I can't do this: >>> >>> example.com relay:internal.smtp.example.com >>> >>> because mail would loop, right? So will using another (essentially >>> junk) domain work for this? >> >> As long as internal.smtp.example.com IS the final destination for >> example.com and the relaying server is NOT the final destination for >> example.com, the mail should not loop. > > I'm not sure whether or not you understood me or if we are in > agreement.
There is a third option. > smtp.example.com is will be the relay server, which is the primary > MX. However, multiple SMTP servers behind it need to be DNS-load > balanced. So if I do this, mail should loop because the current > (relay) server is, as far as DNS MX records are concerned, the correct > destination server: > > example.com relay:internal.smtp.example.com You're confusing DNS and MTA configuration. MX records tell the world where to send mail for example.com. However, the MX record does NOT magically make an MTA running on that host the final destination for example.com SMTP-wise. An MTA becomes the final destination for example.com when the domain is configured in either $mydestination, $virtual_alias_domains or $virtual_mailbox_domains. It is NOT the final destination for any domain configured in $relay_domains. There's also nothing wrong with suppressing MX lookups. You don't need MX records for load-balancing mail sent to backend servers. Example: ----8<---- $ORIGIN example.com @ IN MX 10 external1 @ IN MX 10 external2 external1 IN A 10.42.23.11 external2 IN A 10.42.23.12 internal IN A 10.42.23.101 internal IN A 10.42.23.102 ---->8---- The above snippet defines two MX records external1.example.com and external2.example.com. These are the hosts that the world should send mail for example.com to. Since both records are defined with the same preference, inbound mail will be (DNS-)load-balanced over the two servers. Both servers run Postfix with $relay_domains = example.com and a transport map example.com relay:[internal.example.com] This will cause the two frontend servers to relay all mail for example.com to internal.example.com. No MX lookup is required for this, because you already know (and control) the destination host. And resolution of the A record internal.example.com will automatically load-balance the delivery, because the A record is configured with more than one address (round-robin DNS). Finally, the two backend servers 10.42.23.101 and 10.42.23.102 also run Postfix, but with a configuration like $mydestination = example.com $relay_domains = or $virtual_mailbox_domains = example.com $relay_domains = making them the final destination for SMTP delivery. > I can't use brackets [] to disable MX lookups since I need the DNS > load balancing. Thus I thought to use a different junk domain name > > example.com relay:other.tld As explained above: you don't need MX lookups for DNS load-balancing in the backend. [...] >>> But when the main SMTP server gets mail to invalid recipients, how >>> does it reject it? >> >> It doesn't reject it. Instead it generates bounces, which - in case >> of spam - will hit innocent bystanders whose addresses were spoofed. >> >> Do not accept mail that you know you can't deliver. Either use >> $relay_recipient_maps (building the list and pushing it to the >> frontend server can be implemented with a simple script), use LDAP >> lookups (in case your recipients are listed in an LDAP directory), or >> use the reject_unverified_recipient restriction [1]. > > So either way, the relay server ends up with a list of valid > destination addresses right? Looks like there's just no other correct > way to do it. Right? There may be other ways, but I'm not aware of any. Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky