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

Re: outbound email destination based on sender's domain

Expand Messages
  • Barney Desmond
    ... Assuming your setup is generally sane, this shouldn t cause you any grief. You *can* bind the postfix smtp client to a given src address, but that s only
    Message 1 of 8 , Mar 2, 2009
    View Source
    • 0 Attachment
      2009/3/3 Iad Scoot <iad.scoot@...>:
      > Still working on this - something that I didn't mention (sorry, should have)
      > was that the Postfix gateway is multi-homed and that the other edge Postfix
      > systems (and the internal mail servers) are each on different subnets.
      >
      > Example:
      > a.com: internal mail server 192.168.200.1, edge proxy 192.168.201.1
      > b.com: internal mail server 192.168.210.1, edge proxy 192.168.211.1
      > c.com: internal mail server 192.168.220.1, edge proxy 192.168.221.1
      >
      > ...and so on. The gateway system has a NIC for each pair of systems and the
      > traffic is forwarded through a router from the internal server to the
      > gateway and then either back to one of the other internal servers or out to
      > the edge proxy that matches the sender's domain from the internal mail
      > server.
      >
      > How does this new info affect the previous solution that you provided?

      Assuming your setup is generally sane, this shouldn't cause you any
      grief. You *can* bind the postfix smtp client to a given src address,
      but that's only useful when you're single-homed and want to use one
      particular address of many (for policy/firewall/whatever reasons).
      This doesn't apply to you, so that's fine.

      Another thing people sometimes want is (the currently non-existent)
      sender-dependent src-address. This is usually because they're trying
      to optimise their mass-mailings of questionable legitimacy. This also
      doesn't apply to you, which is fine.

      Left to its own devices, Postfix will let the network stack figure out
      how to get the packets to the destination properly. As long as your
      routing is all working, the details you've provided won't change
      anything (as far as I know).
    • Iad Scoot
      Hi again, Question, even though this proxy is supposed to simply forward the remote traffic based on the sender_relay file, is it supposed to do DNS lookups on
      Message 2 of 8 , Mar 5, 2009
      View Source
      • 0 Attachment
        Hi again,
         
        Question, even though this proxy is supposed to simply forward the remote traffic based on the sender_relay file, is it supposed to do DNS lookups on the destination domain? Having some issues with DNS resolution - server is sending DNS queries but no reply comes back. Firewall rules permit such traffic so stumped on that but does this box have to do DNS?
         
         
        Thanks...

        On Mon, Mar 2, 2009 at 10:00 PM, Iad Scoot <iad.scoot@...> wrote:
        Hey,
         
        Thanks again for the reply - it seems to be routing the traffic correctly (at least as far as the maillog shows) but I'm having an ISA/Exchange timeout issue on the receiving end of the traffic path. I can see the traffic leave the sending mail server, pass through the ISA server for the source network, be received and processed on the proxy (over the correct subnet), and then be routed to the receiving network on the correct subnet (for the receiving network). However, the connection is timing out and the receiving ISA server reports an "Attempted Connection Failure" on the traffic that arrives at the receiving ISA server. The proxy reports that the "server dropped connection before sending the initial SMTP greeting".
         
        Again, guessing that it's an ISA issue or a problem with the Exchange server talking to this particular Postfix server but at least the concept appears sound so hopefully I'll get it figured out tomorrow.
         
        Thanks again - will post more when successful (I hope)...

        On Mon, Mar 2, 2009 at 5:12 PM, Barney Desmond <barneydesmond@...> wrote:
        2009/3/3 Iad Scoot <iad.scoot@...>:
        > Still working on this - something that I didn't mention (sorry, should have)
        > was that the Postfix gateway is multi-homed and that the other edge Postfix
        > systems (and the internal mail servers) are each on different subnets.
        >
        > Example:
        > a.com: internal mail server 192.168.200.1, edge proxy 192.168.201.1
        > b.com: internal mail server 192.168.210.1, edge proxy 192.168.211.1
        > c.com: internal mail server 192.168.220.1, edge proxy 192.168.221.1
        >
        > ...and so on. The gateway system has a NIC for each pair of systems and the
        > traffic is forwarded through a router from the internal server to the
        > gateway and then either back to one of the other internal servers or out to
        > the edge proxy that matches the sender's domain from the internal mail
        > server.
        >
        > How does this new info affect the previous solution that you provided?

        Assuming your setup is generally sane, this shouldn't cause you any
        grief. You *can* bind the postfix smtp client to a given src address,
        but that's only useful when you're single-homed and want to use one
        particular address of many (for policy/firewall/whatever reasons).
        This doesn't apply to you, so that's fine.

        Another thing people sometimes want is (the currently non-existent)
        sender-dependent src-address. This is usually because they're trying
        to optimise their mass-mailings of questionable legitimacy. This also
        doesn't apply to you, which is fine.

        Left to its own devices, Postfix will let the network stack figure out
        how to get the packets to the destination properly. As long as your
        routing is all working, the details you've provided won't change
        anything (as far as I know).


      Your message has been successfully submitted and would be delivered to recipients shortly.