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

Multiple Targets on transport map

Expand Messages
  • Joey J
    We have 2 gateway servers in multiple locations so that we have redundancy and of course corresponding mx records pointing to both. This handles if GW1 fails,
    Message 1 of 6 , Jun 17, 2014
      We have 2 gateway servers in multiple locations so that we have redundancy and of course corresponding mx records pointing to both.
      This handles if GW1 fails, go to GW2

      Now once at a GW the transport map handles the routing of the messages for domain.com as shown:
      domain.com                   smtp:[1.2.3.4]

      However, lets say that server is at a location/building which has 2 internet connections, (primary) using 1.2.3.4 and (secondary) using 8.9.10.11
      and the primary connection fails.

      My servers will queue the mail since it can't communicate with 1.2.3.4.

      What I would like to do is have our server try to deliver to 1.2.3.4 but if that fails try to deliver to 8.9.10.11 much in the same way as MX records function.

      I'm not seeing a way to accomplish this, any suggestions, or examples?


      --
      Thanks!
      Joey

    • Noel Jones
      ... Transport maps are intended as static routing to override standard MX records, not as a replacement for MX records. As such, postfix has no support for
      Message 2 of 6 , Jun 17, 2014
        On 6/17/2014 8:30 PM, Joey J wrote:
        > We have 2 gateway servers in multiple locations so that we have
        > redundancy and of course corresponding mx records pointing to both.
        > This handles if GW1 fails, go to GW2
        >
        > Now once at a GW the transport map handles the routing of the
        > messages for domain.com <http://domain.com> as shown:
        > domain.com <http://domain.com> smtp:[1.2.3.4]
        >
        > However, lets say that server is at a location/building which has 2
        > internet connections, (primary) using 1.2.3.4 and (secondary) using
        > 8.9.10.11
        > and the primary connection fails.
        >
        > My servers will queue the mail since it can't communicate with 1.2.3.4.
        >
        > What I would like to do is have our server try to deliver to 1.2.3.4
        > but if that fails try to deliver to 8.9.10.11 much in the same way
        > as MX records function.
        >
        > I'm not seeing a way to accomplish this, any suggestions, or examples?
        >
        >
        > --
        > Thanks!
        > Joey
        >


        Transport maps are intended as static routing to override standard
        MX records, not as a replacement for MX records. As such, postfix
        has no support for multiple transport targets nor "weighted"
        transport tables.

        Solutions would include localized or split horizon MX records, or
        use a network routing protocol that will cause the kernel IP stack
        to select the preferred route.



        -- Noel Jones
      • Jose Borges Ferreira
        ... If you wanto to deliver do 1.2.3.4 and , if fails, then try 8.9.10.11 then you can create a dns entry with those IP an MX ex: some_entry.local IN MX 10
        Message 3 of 6 , Jun 17, 2014
          On Wed, Jun 18, 2014 at 2:30 AM, Joey J <jacklistmail@...> wrote:
          > We have 2 gateway servers in multiple locations so that we have redundancy
          > and of course corresponding mx records pointing to both.
          > This handles if GW1 fails, go to GW2
          >
          > Now once at a GW the transport map handles the routing of the messages for
          > domain.com as shown:
          > domain.com smtp:[1.2.3.4]
          >
          > However, lets say that server is at a location/building which has 2 internet
          > connections, (primary) using 1.2.3.4 and (secondary) using 8.9.10.11
          > and the primary connection fails.
          >
          > My servers will queue the mail since it can't communicate with 1.2.3.4.
          >
          > What I would like to do is have our server try to deliver to 1.2.3.4 but if
          > that fails try to deliver to 8.9.10.11 much in the same way as MX records
          > function.
          >
          > I'm not seeing a way to accomplish this, any suggestions, or examples?
          >
          >
          If you wanto to deliver do 1.2.3.4 and , if fails, then try 8.9.10.11
          then you can create a dns entry with those IP an MX

          ex:
          some_entry.local IN MX 10 1.2.3.4
          some_entry.local IN MX 20 8.9.10.11

          then setup transport_maps to:

          domain.com smtp:some_entry.local

          Hope it helps.

          other method is using smtp_fallback_relay

          José Borges Ferreira
        • Michael Orlitzky
          ... Nitpick: the .local TLD is reserved by RFC 6762, .invalid may be a better long-term choice.
          Message 4 of 6 , Jun 18, 2014
            On 06/17/2014 11:58 PM, Jose Borges Ferreira wrote:
            > If you wanto to deliver do 1.2.3.4 and , if fails, then try 8.9.10.11
            > then you can create a dns entry with those IP an MX
            >
            > ex:
            > some_entry.local IN MX 10 1.2.3.4
            > some_entry.local IN MX 20 8.9.10.11
            >
            > then setup transport_maps to:
            >
            > domain.com smtp:some_entry.local
            >

            Nitpick: the ".local" TLD is reserved by RFC 6762, ".invalid" may be a
            better long-term choice.
          • Jim Reid
            ... I ll raise you another nitpick. .invalid is reserved by RFC6761 and in the IANA registry of Special-Use Domain Names, just like .local:
            Message 5 of 6 , Jun 18, 2014
              On 18 Jun 2014, at 15:45, Michael Orlitzky <michael@...> wrote:

              > Nitpick: the ".local" TLD is reserved by RFC 6762, ".invalid" may be a
              > better long-term choice.

              I'll raise you another nitpick. .invalid is reserved by RFC6761 and in the IANA registry of Special-Use Domain Names, just like .local:

              http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

              Either TLD string is probably good enough for the OP. As a general rule I'd avoid using .local for anything since that may have interesting interactions with Bonjour.

              It is highly advisable to only use TLD strings on the above list for internal purposes. If you pluck some other string out of the ether, there's always a risk that someone, somewhere will one day ask ICANN to create that string as yet another new gTLD. This is no different from just using some random chunk of address space that hasn't been assigned to you and hoping it isn't used for real somewhere else.
            • Michael Orlitzky
              ... Indeed, thanks for that. I hadn t seen it before. The problem that arises is that you must choose a reserved name, otherwise you may find one day that your
              Message 6 of 6 , Jun 18, 2014
                On 06/18/2014 11:07 AM, Jim Reid wrote:
                > On 18 Jun 2014, at 15:45, Michael Orlitzky <michael@...>
                > wrote:
                >
                >> Nitpick: the ".local" TLD is reserved by RFC 6762, ".invalid" may
                >> be a better long-term choice.
                >
                > I'll raise you another nitpick. .invalid is reserved by RFC6761 and
                > in the IANA registry of Special-Use Domain Names, just like .local:

                Indeed, thanks for that. I hadn't seen it before.

                The problem that arises is that you must choose a reserved name,
                otherwise you may find one day that your made-up name belongs to
                somebody else. RFC2606 reserved ".test", ".example", ".invalid" and
                ".localhost" but didn't specify how they should be handled. Among those,
                I interpreted ".invalid" to have the closest meaning to "internal only."

                Now, RFC6761 says that resolver libraries SHOULD immediately return a
                negative response for ".invalid" queries. So I'm not sure what we're
                left with. We have encountered problems with ".local" and Apple gizmos
                as you mentioned. And personally I don't think I could stand to see
                ".test" on the end of a hostname for all eternity. But from RFC6761,
                that seems like the best option.
              Your message has been successfully submitted and would be delivered to recipients shortly.