>>> Specific questions I had were if I can use the standard DNS "load
>>> balancing" (multiple MX records, same priority, possibly multiple >>> IPs >>> resolving to one A record) setup *behind* a relay server (those MTAs >>> behind the relay only being available via the relay and never >>> directly). >> >> 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. 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 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 >>> Also need to make sure I know how address verification works when >>> ideally the relay doesn't have access to the list of (virtual) > users. >> >> It looks like with relay_recipient_maps empty, all mail just gets sent >> through the relay to the main SMTP server, which is fine. > > No, that ain't fine, because ... > >> 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? >> Am I correct to assume that because the relay server already did the >> SMTP conversation with the client, the main SMTP server can't do any >> real time address checks? This seems less than ideal. > > The main server will do real time address checks. For the transaction > between frontend and backend, that is. However, since SMTP defines a > store-and-forward architecture, mail transactions aren't end-to-end, but > hop-to-hop. OK, so I'll have to ensure that postscreen on the relay can do as much as possible. In this situation, the main/real SMTP server on the backend SHOULD NOT do any of those kinds of checks, because they'd be checking the relay instead of the real sending client. It seems like the real backend SMTP server basically shouldn't be doing any verification at all (maybe just internal anti spam/virus content filtering)??? ..... and certainly should not be bouncing anything that fails its tests (because of backscatter concerns)
