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

Re: 454 instead 5xx status for "Relay access denied"

Expand Messages
  • Reindl Harald
    ... ah, i remembered correct it was set by postfix upgrade-configuration at the bottom of main.cf , maybe the safety net should be the same as postconf
    Message 1 of 10 , Apr 28, 2013
    • 0 Attachment
      Am 28.04.2013 14:41, schrieb Wietse Venema:
      > Reindl Harald:
      >> 454: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
      >> 554: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
      >>
      >> was the default changed from 2.10-devel to 2.10 final?
      >
      > defer_unauth_destination etc.. is the default safety net for
      > sites that haven't set smtpd_relay_restrictions

      ah, i remembered correct it was set by "postfix upgrade-configuration"
      at the bottom of "main.cf", maybe the "safety net" should be the
      same as "postconf -d" which is "reject_unauth_destination"?
    • Stan Hoeppner
      ... What practical difference do you see between these two reject codes? The client in this transaction is almost certainly not an MTA. It s most likely
      Message 2 of 10 , Apr 28, 2013
      • 0 Attachment
        On 4/28/2013 9:52 AM, Reindl Harald wrote:
        >
        > Am 28.04.2013 14:41, schrieb Wietse Venema:
        >> Reindl Harald:
        >>> 454: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
        >>> 554: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
        >>>
        >>> was the default changed from 2.10-devel to 2.10 final?
        >>
        >> defer_unauth_destination etc.. is the default safety net for
        >> sites that haven't set smtpd_relay_restrictions
        >
        > ah, i remembered correct it was set by "postfix upgrade-configuration"
        > at the bottom of "main.cf", maybe the "safety net" should be the
        > same as "postconf -d" which is "reject_unauth_destination"?

        What practical difference do you see between these two reject codes?
        The client in this transaction is almost certainly not an MTA. It's
        most likely rat/malware, which typically either:

        A. Don't pay attention to reply codes at all
        B. Log any rejection and the IP into a "don't try again" list

        And BTW, reject_unknown_reverse_client_hostname would have rejected much
        earlier. This IP returns NXDOMAIN. Why aren't you using
        reject_unknown_reverse_client_hostname?

        --
        Stan
      • Viktor Dukhovni
        ... There is an important difference, which is why the defer variant is used as a safety net, and the use-case is precisely when the client is an MTA. --
        Message 3 of 10 , Apr 28, 2013
        • 0 Attachment
          On Sun, Apr 28, 2013 at 06:52:09PM -0500, Stan Hoeppner wrote:

          > >> defer_unauth_destination etc.. is the default safety net for
          > >> sites that haven't set smtpd_relay_restrictions
          > >
          > > ah, i remembered correct it was set by "postfix upgrade-configuration"
          > > at the bottom of "main.cf", maybe the "safety net" should be the
          > > same as "postconf -d" which is "reject_unauth_destination"?
          >
          > What practical difference do you see between these two reject codes?
          > The client in this transaction is almost certainly not an MTA. It's
          > most likely rat/malware, which typically either:

          There is an important difference, which is why the defer variant
          is used as a safety net, and the use-case is precisely when the
          client is an MTA.

          --
          Viktor.
        • Stan Hoeppner
          ... Apparently I didn t make my point clear, which is that a hard fail isn t necessary here, and that a temp fail is preferable to cover all client types. I
          Message 4 of 10 , Apr 28, 2013
          • 0 Attachment
            On 4/28/2013 7:33 PM, Viktor Dukhovni wrote:
            > On Sun, Apr 28, 2013 at 06:52:09PM -0500, Stan Hoeppner wrote:
            >
            >>>> defer_unauth_destination etc.. is the default safety net for
            >>>> sites that haven't set smtpd_relay_restrictions
            >>>
            >>> ah, i remembered correct it was set by "postfix upgrade-configuration"
            >>> at the bottom of "main.cf", maybe the "safety net" should be the
            >>> same as "postconf -d" which is "reject_unauth_destination"?
            >>
            >> What practical difference do you see between these two reject codes?
            >> The client in this transaction is almost certainly not an MTA. It's
            >> most likely rat/malware, which typically either:
            >
            > There is an important difference, which is why the defer variant
            > is used as a safety net, and the use-case is precisely when the
            > client is an MTA.

            Apparently I didn't make my point clear, which is that a hard fail isn't
            necessary here, and that a temp fail is preferable to cover all client
            types. I think Reindl was advocating a hard fail. I was countering his
            argument.

            And again, he could have prevented this discussion entirely with a
            simple, safe, effective, client restriction, that up until now I assumed
            *everyone* uses.

            --
            Stan
          • Viktor Dukhovni
            ... Well, the hard fail is typically a good idea once one is sure the restrictions contain all the required permits. Some sites may depend on
            Message 5 of 10 , Apr 28, 2013
            • 0 Attachment
              On Sun, Apr 28, 2013 at 11:10:10PM -0500, Stan Hoeppner wrote:

              > > There is an important difference, which is why the defer variant
              > > is used as a safety net, and the use-case is precisely when the
              > > client is an MTA.
              >
              > Apparently I didn't make my point clear, which is that a hard fail isn't
              > necessary here, and that a temp fail is preferable to cover all client
              > types. I think Reindl was advocating a hard fail. I was countering his
              > argument.

              Well, the hard fail is typically a good idea once one is sure the
              restrictions contain all the required permits. Some sites may
              depend on check_client_access or check_recipient_access table
              lookups to handle cases more complex than permit_mynetworks or
              permit_auth_destination.

              The point of the safety net is to give the site some time to notice
              before lots of mail bounces.

              If you're advocating leaving the defer safety net on all the time,
              in the case of relay permissions this is arguably not entirely
              unreasonable. One could argue that legitimate MTAs that queue and
              retry mail deliveries are not easily fooled into using some other
              MTA as an unauthorized relay, and that the relay restrictions should
              not reject mail for which the receiving MTA is an MX host.

              So in that sense, this particular safety net may also be usable on
              a long-term basis. The main problem case is with ISP MTAs that
              support relaying by authorized clients, when a client is misconfigured
              to continue to use the original MTA after switching ISPs or after
              a password reset... Then the client may keep trying to send
              repeatedly.

              A soft fail is in this case a feature from the perspective of the
              misconfigured client, but may increase load at the ISP if the client
              generates enough traffic. All in all, perhaps a rather small risk,
              since clients liable to be misconfigured this way are unlikely to
              constitude a substantial fraction of the ISPs mail load.

              --
              Viktor.
            • Reindl Harald
              ... that one is a temporary and the other a permenently error? that i can hardly complain that Apple Inc. is a idiotic company by trying again and again send
              Message 6 of 10 , Apr 29, 2013
              • 0 Attachment
                Am 29.04.2013 01:52, schrieb Stan Hoeppner:
                > On 4/28/2013 9:52 AM, Reindl Harald wrote:
                >> Am 28.04.2013 14:41, schrieb Wietse Venema:
                >>> Reindl Harald:
                >>>> 454: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
                >>>> 554: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
                >>>>
                >>>> was the default changed from 2.10-devel to 2.10 final?
                >>>
                >>> defer_unauth_destination etc.. is the default safety net for
                >>> sites that haven't set smtpd_relay_restrictions
                >>
                >> ah, i remembered correct it was set by "postfix upgrade-configuration"
                >> at the bottom of "main.cf", maybe the "safety net" should be the
                >> same as "postconf -d" which is "reject_unauth_destination"?
                >
                > What practical difference do you see between these two reject codes?
                > The client in this transaction is almost certainly not an MTA. It's
                > most likely rat/malware, which typically either:

                that one is a temporary and the other a permenently error?
                that i can hardly complain that Apple Inc. is a idiotic company
                by trying again and again send mails from iPhones without
                SMTP-Auth even after a hard-error when i randomly answer
                with a soft error?

                > And BTW, reject_unknown_reverse_client_hostname would have rejected much
                > earlier. This IP returns NXDOMAIN. Why aren't you using
                > reject_unknown_reverse_client_hostname?

                because it does not matter on a machine which is not MX for any single domain
              • Reindl Harald
                ... uhm as i said: * the machine is not MX for any single domain * the machine must not accept any unauthenticated message * and so any aerror is NOT tenporary
                Message 7 of 10 , Apr 29, 2013
                • 0 Attachment
                  Am 29.04.2013 06:10, schrieb Stan Hoeppner:
                  > On 4/28/2013 7:33 PM, Viktor Dukhovni wrote:
                  >> There is an important difference, which is why the defer variant
                  >> is used as a safety net, and the use-case is precisely when the
                  >> client is an MTA.
                  >
                  > Apparently I didn't make my point clear, which is that a hard fail isn't
                  > necessary here, and that a temp fail is preferable to cover all client
                  > types. I think Reindl was advocating a hard fail. I was countering his
                  > argument

                  uhm as i said:

                  * the machine is not MX for any single domain
                  * the machine must not accept any unauthenticated message
                  * and so any aerror is NOT tenporary until smtp auth is used
                Your message has been successfully submitted and would be delivered to recipients shortly.