Ansgar, thank you for your patience:
>>>> 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. No, this I understand. I based my claim above on the understanding that this is what happens with a transport such as this: example.com relay:internal.smtp.example.com * mail for example.com arrives at the relay because it is the highest priority MX record for example.com * the relay is told by its configuration (see above) that internal.smtp.example.com is the next hop for mail to example.com * so the relay looks up the MX for mail going to example.com addresses via internal.smtp.example.com and finds again that the MX for example.com is itself, creating the loop I am probably misunderstanding something (like, maybe I can set the MX for internal.smtp.example.com differently and it will be looked up instead of just example.com? or maybe internal.smtp.example.com being the next hop overrides any MX lookup ???) > 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). OK, I didn't think of that - DNS load balancing with multiple A records instead of multiple MX records (for the internal hosts). I was stuck on how it's usually done for multiple public-facing hosts. Thanks for clarifying that tip for me. I think there has been some discussion that some mail servers like to have multiple MX records and some prefer multiple A records, thus a safe solution (for public facing MTAs) is to use both. In this case, are we assured that Postfix will always spread the load round robin style to multiple A records? If that's true, this seems like the best solution >>>> 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. OK. To be clear, if one were to keep the recipient list out of the hands of the relay server, the only reasonable thing to do in that scenario is to silently discard all bounces from the internal MTA, right? This avoids backscatter but no one would get the helpful bounces in the case of address typos, user being over quota, etc. Is that right? Probably no one does something like that. The only other solution I can see is to use something like Nginx to just proxy the SMTP conversation through the relay to the internal MTA. I haven't tried this before, but if Nginx can perform fast enough and can also be DNS load balanced in connecting to internal MTAs, would it work? If the relay is not near the internal MTAs, will network latency make this a dubious choice? As I understand it, the advantage to that setup would be that the internal MTAs could be configured as if they were public facing themselves. Yes? Thanks again for being so helpful as I learn
