On Sat, Jul 20, 2013 at 05:18:58PM -0400, Wietse Venema wrote: > /dev/rob0: > > The doubt in my mind about this is for mail truly destined to > > our hosted domains. It resolves to an Internet (not an internal) > > IP address which is in the MX instance's proxy_interfaces > > setting. We're in a DC and behind NAT, with that Internet IP > > address being NATed to this host. > > > > They don't have "hairpin NAT" set up, whereby if I try to connect > > to this NATed IP address it would go to the router and come back > > to me. I'm fine with that, actually; while that would solve the > > instant problem, it could be bad in other ways. > > An MTA should never connect to its own MTA address and port.
Thanks for the reply. So how can I deliver mail from our users to our hosted domains? It's not connecting to its own port. The MSA has 587, the MX has 25. [127.0.0.1]:25 is my own IP address (from the POV of the MSA) but not my port. > That is what proxy_interfaces and inet_interfaces are for. It should be no problem to use an additional RFC 1918 address and set inet_interfaces. I guess that's the solution to this. The MSA can have 172.16.5.87 for example, and the MX can have 172.16.0.25 (both being in the same /16, that is.) I'm thinking the MSA would *not* set proxy_interfaces unless a different NATed IP address is used. And two external IP addresses should not be needed. The MX instance is the one which should be concerned with looping. > When Postfix is properly configured it will understand that > [my.ip.address] is the MTA itself. > > Postfix requires that a NAT performs the following translations: > > - With inbound traffic, translate the public MTA destination IP > address into the private MTA destination IP address. > > - With outbound traffic, translate the private MTA source IP address > into the public MTA source IP address. > > No other translations. In particular, no translations of the remote > MTA IP address or port. > > In addition, proxy_interfaces needs to specfy the external MTA IP > address. Right, I have that set for the MX instance, but again, can't see why it would matter for the MSA. Just let it send on, because the MX instance will get it and deal with it. On some more thought, I'm still seeing a problem here, one which is potentially more serious. If the MSA uses check_recipient_mx_access to translate my.exter.nal.ip to 172.16.0.25 (the MX instance's IP) there could still be a problem with multi-RCPT mail. Suppose: RCPT TO:<user@hosted.example> RCPT TO:<user@moved.example> Hosted.example's MX name resolves to my.exter.nal.ip. Moved.example now has hosting through a different provider. My check_recipient_mx_access hack sends this mail to the MX instance, which lo and behold, thinks it still hosts moved.example mail. So it's looking like the only completely safe solution is an alternate DNS view, so that hosted.example's MX name resolves to 172.16.0.25? Thanks for the reply, enjoy your weekend. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
