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

454 instead 5xx status for "Relay access denied"

Expand Messages
  • Reindl Harald
    Hi should this not be a permanent error instead temporary? in fact some spammer tried for open relay Apr 28 00:32:49 mail postfix/smtpd[25333]: NOQUEUE:
    Message 1 of 10 , Apr 28, 2013
    • 0 Attachment
      Hi

      should this not be a permanent error instead temporary?
      in fact some spammer tried for open relay

      Apr 28 00:32:49 mail postfix/smtpd[25333]: NOQUEUE: reject: RCPT from unknown[221.5.24.12]: 454 4.7.1
      <acylea2089@...>: Relay access denied; from=<verrwm@...> to=<acylea2089@...>
      proto=ESMTP helo=<oetezh.com>

      FYI: the "permit_sasl_authenticated reject" followed by more restrictions
      in "smtpd_recipient_restrictions" is intentional and this "reject"
      would be removed if the machine has to play MX again
      ___________________________________

      postconf -n | grep code
      unknown_address_reject_code = 550
      unknown_hostname_reject_code = 501
      unknown_local_recipient_reject_code = 550
      unverified_recipient_reject_code = 550
      ___________________________________

      postconf -n | grep smtpd | grep -v tls
      barracuda_smtpd_recipient_restrictions = permit_mynetworks, reject
      smtpd_banner = $myhostname ESMTP
      smtpd_client_connection_rate_limit = 50
      smtpd_client_recipient_rate_limit = 400
      smtpd_discard_ehlo_keywords = silent-discard, etrn, dsn, vrfy
      smtpd_error_sleep_time = ${stress?1}${stress:2}s
      smtpd_hard_error_limit = ${stress?5}${stress:10}
      smtpd_helo_required = yes
      smtpd_peername_lookup = yes
      smtpd_proxy_options = speed_adjust
      smtpd_recipient_limit = 100
      smtpd_recipient_restrictions = permit_mynetworks reject_non_fqdn_recipient reject_non_fqdn_sender
      reject_unlisted_sender reject_authenticated_sender_login_mismatch permit_sasl_authenticated reject
      reject_unauth_destination reject_unknown_sender_domain reject_unknown_recipient_domain reject_invalid_hostname
      reject_unknown_reverse_client_hostname reject_unauth_pipelining reject_rbl_client dnsbl-1.uceprotect.net
      check_policy_service unix:/var/spool/postfix/postgrey/socket check_recipient_access
      proxy:mysql:/etc/postfix/mysql-spamfilter.cf
      smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
      smtpd_sasl_auth_enable = yes
      smtpd_sasl_path = private/auth
      smtpd_sasl_type = dovecot
      smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql-senderaccess.cf
      smtpd_soft_error_limit = ${stress?2}${stress:5}
      ___________________________________
    • Reindl Harald
      ... ouch - fixed 454: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination 554: smtpd_relay_restrictions =
      Message 2 of 10 , Apr 28, 2013
      • 0 Attachment
        Am 28.04.2013 11:47, schrieb Reindl Harald:
        > should this not be a permanent error instead temporary?
        > in fact some spammer tried for open relay
        >
        > Apr 28 00:32:49 mail postfix/smtpd[25333]: NOQUEUE: reject: RCPT from unknown[221.5.24.12]: 454 4.7.1
        > <acylea2089@...>: Relay access denied; from=<verrwm@...> to=<acylea2089@...>
        > proto=ESMTP helo=<oetezh.com>
        >
        > FYI: the "permit_sasl_authenticated reject" followed by more restrictions
        > in "smtpd_recipient_restrictions" is intentional and this "reject"
        > would be removed if the machine has to play MX again

        ouch - fixed

        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?
        i am pretty sure the "defer_unauth_destination" was not invited by me
      • Wietse Venema
        ... defer_unauth_destination etc.. is the default safety net for sites that haven t set smtpd_relay_restrictions. Wietse
        Message 3 of 10 , Apr 28, 2013
        • 0 Attachment
          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.

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