Loading ...
Sorry, an error occurred while loading the content.

Re: postmulti behind NAT

Expand Messages
  • Jeroen Geilman
    ... Why would you not allow submission to deliver to the hosted domains ? You can simply add the maps to the existing ones you use (if any). -- J.
    Message 1 of 8 , Jul 22, 2013
    • 0 Attachment
      On 07/21/2013 12:23 AM, /dev/rob0 wrote:
      > 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.)

      Why would you not allow submission to deliver to the hosted domains ?
      You can simply add the maps to the existing ones you use (if any).

      --
      J.
    • /dev/rob0
      ... The point is that we can never be sure that we actually do host any given domain. Suppose a customer buys a year of hosting, and after 9 months gets some
      Message 2 of 8 , Jul 22, 2013
      • 0 Attachment
        On Mon, Jul 22, 2013 at 08:51:37PM +0200, Jeroen Geilman wrote:
        > Why would you not allow submission to deliver to the hosted
        > domains ? You can simply add the maps to the existing ones
        > you use (if any).

        The point is that we can never be sure that we actually do host any
        given domain. Suppose a customer buys a year of hosting, and after 9
        months gets some other hosting deal. They change the DNS to point
        away from us, without telling us.

        During that last quarter, where should that mail go? I'm not so
        worried about a foolish ex-customer like that as I am about other
        customers, who might need to send mail to that ex-customer.
        --
        http://rob0.nodns4.us/ -- system administration and consulting
        Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
      • Ulrich Zehl
        ... May I ask what badness you expect from that? My first thought was to suggest setting up the NAT rules yourself (using iptables or whatever your OS offers).
        Message 3 of 8 , Jul 22, 2013
        • 0 Attachment
          On Sat, Jul 20, 2013 at 03:45:35PM -0500, /dev/rob0 wrote:
          > 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.

          May I ask what badness you expect from that? My first thought was to
          suggest setting up the NAT rules yourself (using iptables or whatever your
          OS offers). If they're restricted to match only TCP to <externalIP>:25, I
          don't see much potential for problems (but of course, I may be missing
          something).

          Ulrich
        • /dev/rob0
          ... You re right, probably none. People who do hairpin NAT wrong (not restricting by interface) can create open relays when the router IP address is in
          Message 4 of 8 , Jul 23, 2013
          • 0 Attachment
            On Tue, Jul 23, 2013 at 07:54:38AM +0200, Ulrich Zehl wrote:
            > On Sat, Jul 20, 2013 at 03:45:35PM -0500, /dev/rob0 wrote:
            > > 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.
            >
            > May I ask what badness you expect from that?

            You're right, probably none. People who do "hairpin NAT" wrong (not
            restricting by interface) can create open relays when the router IP
            address is in $mynetworks. Even if not an open relay, it destroys
            your strongest antispam tools by obscuring the client IP address.

            In this case the NAT should only be done for packets from the MSA
            instance to the MX instance, so the usual problem of the wrong IP
            address being logged would not matter: the router IP *is* the MSA.

            > My first thought was to suggest setting up the NAT rules yourself
            > (using iptables or whatever your OS offers). If they're restricted
            > to match only TCP to <externalIP>:25, I don't see much potential
            > for problems (but of course, I may be missing something).

            My ultimate solution was as per the discussion with Wietse: an
            alternate DNS view of the MX instance hostname. I accomplished it
            using dnsmasq and an entry in /etc/hosts, quick and easy. Any
            additional names which might be used for this address must be added
            to hosts as well.

            I should close up this thread by saying that in this case all my
            puzzling was pointless. :) This site uses an external filtering
            service as relayhost. MSA sends everything to relayhost, the
            relayhost delivers.

            Still, it's not entirely useless, because I learned something, and
            these folks might not always want to be at the mercy of their
            filtering service provider. If/when they decide to switch to send
            direct-to-MX, it already works.
            --
            http://rob0.nodns4.us/ -- system administration and consulting
            Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
          Your message has been successfully submitted and would be delivered to recipients shortly.