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

postmulti behind NAT

Expand Messages
  • /dev/rob0
    I ve been fortunate thus far ;) not to have to set up multiple instances. Now I m on a job with a definite need for it: hosting company with domains which
    Message 1 of 8 , Jul 20, 2013
    • 0 Attachment
      I've been fortunate thus far ;) not to have to set up multiple
      instances. Now I'm on a job with a definite need for it: hosting
      company with domains which might possibly be moved to other providers
      without notice.

      My solution to the problem was to completely separate submission
      (outbound, mostly) from MX mail. The MSA instance will look up each
      and every domain in DNS and will handle it as DNS says. It will not
      be tainted by any database lookups. The resolver in question isn't
      authoritative for any of the hosted domains. And the MSA instance
      listens on port 587 only, while the MX instance is on 25 only.

      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.

      The best I came up with: check_recipient_mx_access, where if the
      external name or IP is found, "REDIRECT smtp:[127.0.0.1]". Two
      issues with this:
      1. Does not account for sendmail(1) submission
      2. Redirects all recipients of multi-recipient mail
      #1 is unknown whether or not it is a problem. #2 is probably minor;
      I'll simply have the MX instance accept and relay them on.

      ISTM the only complete solution to this would be DNS views, giving my
      internal IP address for the external name.

      Does that cover it all? Is my reasoning valid; is there anything I
      missed?
      --
      http://rob0.nodns4.us/ -- system administration and consulting
      Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
    • Wietse Venema
      ... An MTA should never connect to its own MTA address and port. That is what proxy_interfaces and inet_interfaces are for. When Postfix is properly configured
      Message 2 of 8 , Jul 20, 2013
      • 0 Attachment
        /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.
        That is what proxy_interfaces and inet_interfaces are for.
        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.

        Wietse
      • /dev/rob0
        ... 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.
        Message 3 of 8 , Jul 20, 2013
        • 0 Attachment
          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@...>
          RCPT TO:<user@...>

          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:
        • Wietse Venema
          ... You send it to the public IP address just like everyone else. If you are sending mail from the inside of the same NAT, and the NAT cannot handle
          Message 4 of 8 , Jul 20, 2013
          • 0 Attachment
            /dev/rob0:
            > 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

            You send it to the public IP address just like everyone else.

            If you are sending mail from the inside of the same NAT, and the
            NAT cannot handle connections from inside to the public IP address,
            then use a private DNS that hands out private IP address to internal
            clients, and that forwards all other queries to the Internet.

            Wietse
          • 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 5 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 6 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 7 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 8 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.