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

Re: Backup mx on cable

Expand Messages
  • Stan Hoeppner
    ... You ve said cable twice now, plus once in the subject. Postfix doesn t know what cable is. We don t know what cable is. Do you actually mean to
    Message 1 of 9 , Jul 9, 2013
    View Source
    • 0 Attachment
      On 7/7/2013 4:29 PM, Fred Zinsli wrote:

      > I have primary and secondary MX servers, but my secondary server is on
      > cable. My primary server is on the backbone.
      >
      > How can I configure my primary server to accept connections/mail from the
      > secondary server but still refuse connections/mail from all other cable
      > connections.

      You've said "cable" twice now, plus once in the subject. Postfix
      doesn't know what "cable" is. "We" don't know what "cable" is. Do you
      actually mean to say "dynamic IP address" here? Likewise, when you say
      "backbone" do you simply mean "static IP address"?

      This is a technical mailing list. We can't help you if you don't
      provide technically accurate information. If the backup MX indeed has a
      dynamic IP address then Wietse's suggestion obviously won't work for you
      and a different solution is needed.

      --
      Stan
    • Fred Zinsli
      Thankyou for clarifying my technical ineptitude. But I thought it would have been obvious that I had limited technical knowledge by the content of my message.
      Message 2 of 9 , Jul 9, 2013
      View Source
      • 0 Attachment
        Thankyou for clarifying my technical ineptitude. But I thought it would
        have been obvious that I had limited technical knowledge by the content of
        my message. And rather than flame me, you may have been a little more
        constructive.

        As far as I can make out, postfix can tell the nature of a connection via
        the PTR (rDNS) record information, although this can be modified on
        request. It is that information I was eluding to, as postfix does use that
        information within the relaying_stoplist to prevent just that.

        So given my secondary (backup) MX server is on one off those types of
        connection, how do I allow it to connect to my primary server when it
        returns to service given I have not modified the relaying_stoplist file?

        Now whilst I may have used some incorrect terms. Think about my puny
        little brain, and how technically inept you were when you were getting
        into IT.

        Regards

        Fred



        > On 7/7/2013 4:29 PM, Fred Zinsli wrote:
        >
        >> I have primary and secondary MX servers, but my secondary server is on
        >> cable. My primary server is on the backbone.
        >>
        >> How can I configure my primary server to accept connections/mail from
        >> the
        >> secondary server but still refuse connections/mail from all other cable
        >> connections.
        >
        > You've said "cable" twice now, plus once in the subject. Postfix
        > doesn't know what "cable" is. "We" don't know what "cable" is. Do you
        > actually mean to say "dynamic IP address" here? Likewise, when you say
        > "backbone" do you simply mean "static IP address"?
        >
        > This is a technical mailing list. We can't help you if you don't
        > provide technically accurate information. If the backup MX indeed has a
        > dynamic IP address then Wietse's suggestion obviously won't work for you
        > and a different solution is needed.
        >
        > --
        > Stan
        >
        >
      • Viktor Dukhovni
        ... On the primary MX host, there is no need to adjust relay controls to permit access from secondary MX hosts, after all the mail queued by the secondary is
        Message 3 of 9 , Jul 9, 2013
        View Source
        • 0 Attachment
          On Wed, Jul 10, 2013 at 01:24:10AM +0400, Fred Zinsli wrote:

          > Thankyou for clarifying my technical ineptitude. But I thought it would
          > have been obvious that I had limited technical knowledge by the content of
          > my message. And rather than flame me, you may have been a little more
          > constructive.
          >
          > As far as I can make out, postfix can tell the nature of a connection via
          > the PTR (rDNS) record information, although this can be modified on
          > request. It is that information I was eluding to, as postfix does use that
          > information within the relaying_stoplist to prevent just that.
          >
          > So given my secondary (backup) MX server is on one off those types of
          > connection, how do I allow it to connect to my primary server when it
          > returns to service given I have not modified the relaying_stoplist file?
          >
          > Now whilst I may have used some incorrect terms. Think about my puny
          > little brain, and how technically inept you were when you were getting
          > into IT.

          On the primary MX host, there is no need to adjust relay controls
          to permit access from secondary MX hosts, after all the mail queued
          by the secondary is *inbound* mail.

          All you need to do is not subject the secondary to anti-spam
          controls, since all the anti-spam controls must be done by the host
          that processes the original third-party mail transaction.

          Therefore, all you need is:

          main.cf:
          smtpd_recipient_restrictions =
          permit_mynetworks,
          permit_sasl_authenticated,
          reject_unauth_destination,
          check_client_access cidr:${config_directory}/2mx.cidr,
          ... anti-spam controls if any ...

          2mx.cidr:
          # Actual IP OK comment text so you why later
          192.0.2.1 OK secondary MX smtp.example.net

          Replace 192.0.2.1 and smtp.example.net with the correct data.

          With Postfix 2.10 your anti-relay controls may be separate:

          smtpd_relay_restrictions =
          permit_mynetworks,
          permit_sasl_authenticated,
          reject_unauth_destination

          and if that's the case then the recipient restrictions are for anti-spam
          only, but still need to allow white-listed clients (mynetworks and SASL)
          and thus become:

          smtpd_recipient_restrictions =
          permit_mynetworks,
          permit_sasl_authenticated,
          check_client_access cidr:${config_directory}/2mx.cidr,
          ... anti-spam controls if any ...

          --
          Viktor.
        • Jan P. Kessler
          ... I use TLS client certificates for these purposes* http://www.postfix.org/TLS_README.html * Not for backup to primary mx, but whenever I own both sides of
          Message 4 of 9 , Jul 9, 2013
          View Source
          • 0 Attachment
            > How can I configure my primary server to accept connections/mail from the
            > secondary server but still refuse connections/mail from all other cable
            > connections.

            I use TLS client certificates for these purposes*

            http://www.postfix.org/TLS_README.html

            * Not for backup to primary mx, but whenever I 'own' both sides of the
            connection and one is behind a dynamic ip (soho server sends outgoing
            mail via company relay, ...).
          • Jan P. Kessler
            ... Please note that having a public MX behind a dynamic ip address may lead to situations where someone else gets your mail! I m just thinking about setting
            Message 5 of 9 , Jul 9, 2013
            View Source
            • 0 Attachment
              Am 09.07.2013 23:56, schrieb Jan P. Kessler:
              > > How can I configure my primary server to accept connections/mail from the
              > > secondary server but still refuse connections/mail from all other cable
              > > connections.
              >
              > I use TLS client certificates for these purposes*
              >
              > http://www.postfix.org/TLS_README.html
              >
              > * Not for backup to primary mx, but whenever I 'own' both sides of the
              > connection and one is behind a dynamic ip (soho server sends outgoing
              > mail via company relay, ...).

              Please note that having a public MX behind a dynamic ip address may lead
              to situations where someone else gets your mail!

              I'm just thinking about setting up a honeypot postfix on my cable line
              at home ;).
            • Fred Zinsli
              ... This is something I hadn t considered at all. In order for me to better understand the consequences of my actions are you able to explain to me why that is
              Message 6 of 9 , Jul 9, 2013
              View Source
              • 0 Attachment
                > Am 09.07.2013 23:56, schrieb Jan P. Kessler:
                >> > How can I configure my primary server to accept connections/mail from
                >> the
                >> > secondary server but still refuse connections/mail from all other
                >> cable
                >> > connections.
                >>
                >> I use TLS client certificates for these purposes*
                >>
                >> http://www.postfix.org/TLS_README.html
                >>
                >> * Not for backup to primary mx, but whenever I 'own' both sides of the
                >> connection and one is behind a dynamic ip (soho server sends outgoing
                >> mail via company relay, ...).
                >
                > Please note that having a public MX behind a dynamic ip address may lead
                > to situations where someone else gets your mail!
                >
                > I'm just thinking about setting up a honeypot postfix on my cable line
                > at home ;).
                >
                >

                This is something I hadn't considered at all.
                In order for me to better understand the consequences of my actions are
                you able to explain to me why that is the case, and what situation would
                need to arise for that to happen. Or simply point me to the appropriate
                articles so I can read and investigate this.

                It is looking more and more like I should be leasing another VPS server to
                host my backup DNS and MX.

                Regards

                Fred
              • btb@...
                ... honestly, i simply wouldn t bother with a backup mx. what is the actual problem you re trying to solve by running a backup mx? the contemporary internet
                Message 7 of 9 , Jul 9, 2013
                View Source
                • 0 Attachment
                  On Jul 9, 2013, at 21.56, Fred Zinsli <fred.zinsli@...> wrote:

                  > This is something I hadn't considered at all.
                  > In order for me to better understand the consequences of my actions are
                  > you able to explain to me why that is the case, and what situation would
                  > need to arise for that to happen. Or simply point me to the appropriate
                  > articles so I can read and investigate this.
                  >
                  > It is looking more and more like I should be leasing another VPS server to
                  > host my backup DNS and MX.

                  honestly, i simply wouldn't bother with a backup mx. what is the actual problem you're trying to solve by running a backup mx? the contemporary internet is remarkably well connected - the days in which the truly practical application of a backup mx were back when hosts/sites often spent the majority of their time disconnected from the internet.

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