On 2012-06-28 email builder wrote: >> 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. >> 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]. > 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. > Also, it looks like any bounces or anything else that the main SMTP > server needs to send back go through the relay if I specify it in > either the "relayhost" setting or if I put it in the transport table > with: > > * smtp:relay.example.com > > Is there a difference between that and relayhost? Which is better? > Do both methods force postfix to send anything outgoing (bounces OR > outgoing user email OR anything else) through that given host? If I understand "man 5 transport" correctly, both settings should do the same. I would prefer $relayhost for better readability, though. >> And assuming I can run postscreen on the relay and not need to do >> much connection, client and RBL filtering on the main MTAs (except >> address related since the relay won't have access to local >> addresses). > > I still need to learn about this more, I don't know how much of my > recipient/client/helo (etc.) restrictions I can put on the relay and > how the main SMTP server will handle those restrictions that the relay > can't handle when it is being relayed to indirectly. All of your restrictions should be implemented on the frontend server, and the backend server should accept mail only from trusted locations. [1] http://www.postfix.org/postconf.5.html#reject_unverified_recipient Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
