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

restriction classes

Expand Messages
  • Will Yardley
    I m wondering if someone can help me make sure I get the order right for some recipient classes. I had hoped to just phase these out in favor of a more unified
    Message 1 of 6 , Jul 22, 2014
      I'm wondering if someone can help me make sure I get the order right for
      some recipient classes. I had hoped to just phase these out in favor of
      a more unified system

      The *intent* was to have the recommended class behave the same as a user
      without the attribute set to 'recommended'.

      Right now, the config (which was written by someone else, a long, long
      time ago) looks something like this, which I realize doesn't accomplish
      its original goal:

      Postfix 2.3.3 on RHEL 5 (upgrading to 2.6.6 very soon)

      smtpd_recipient_restrictions =
      [...]
      reject_rbl_client foo.example.org=127.0.0.4,
      reject_unknown_recipient_domain,
      reject_non_fqdn_recipient,
      permit_mynetworks,
      reject_unauth_destination,
      [...]
      check_recipient_access ldap:acct_class_ldap,

      [slightly simplified]

      smtpd_restriction_classes = minimum, modest, recommended, strict

      minimum = permit

      modest = reject_rbl_client foo.example.org,
      permit

      recommended = reject_non_fqdn_sender,
      reject_rbl_client foo.example.org
      reject_rhsbl_client rhsbl.example.com
      reject_rhsbl_sender rhsbl.example.com
      permit

      strict = reject_non_fqdn_sender,
      reject_non_fqdn_helo_hostname,
      reject_unknown_reverse_client_hostname,
      reject_rbl_client foo.example.org
      reject_rbl_client bar.example.com
      reject_rhsbl_client rhsbl.example.com
      reject_rhsbl_sender rhsbl.example.com
      permit

      The main problem I see here is that a) certain checks are made
      redundant, and b) 'minimal' and 'modest' still have some of the
      "recommended" checks included.


      My thought was that maybe I should do something like this instead:

      reject_non_fqdn_recipient,
      permit_mynetworks,
      reject_unauth_destination,
      reject_unknown_recipient_domain,
      check_recipient_access ldap:acct_class_ldap,
      # "recommended", i.e., default stuff here
      reject_non_fqdn_sender,
      reject_rbl_client foo.example.org
      reject_rhsbl_client rhsbl.example.com
      reject_rhsbl_sender rhsbl.example.com
      [...]

      and then have
      recommended =

      [to avoid redundant checks]

      Will this work, and are there any fatal flaws in my ordering?
    • Noel Jones
      ... Don t worry too much about redundant or repeated checks in different classes. The impact is negligible. ... Be careful about rejecting mail from your own
      Message 2 of 6 , Jul 23, 2014
        On 7/22/2014 7:34 PM, Will Yardley wrote:
        > I'm wondering if someone can help me make sure I get the order right for
        > some recipient classes. I had hoped to just phase these out in favor of
        > a more unified system
        >
        > The *intent* was to have the recommended class behave the same as a user
        > without the attribute set to 'recommended'.
        >
        > Right now, the config (which was written by someone else, a long, long
        > time ago) looks something like this, which I realize doesn't accomplish
        > its original goal:
        >
        > Postfix 2.3.3 on RHEL 5 (upgrading to 2.6.6 very soon)
        >
        > smtpd_recipient_restrictions =
        > [...]
        > reject_rbl_client foo.example.org=127.0.0.4,
        > reject_unknown_recipient_domain,
        > reject_non_fqdn_recipient,
        > permit_mynetworks,
        > reject_unauth_destination,
        > [...]
        > check_recipient_access ldap:acct_class_ldap,
        >
        > [slightly simplified]
        >
        > smtpd_restriction_classes = minimum, modest, recommended, strict
        >
        > minimum = permit
        >
        > modest = reject_rbl_client foo.example.org,
        > permit
        >
        > recommended = reject_non_fqdn_sender,
        > reject_rbl_client foo.example.org
        > reject_rhsbl_client rhsbl.example.com
        > reject_rhsbl_sender rhsbl.example.com
        > permit
        >
        > strict = reject_non_fqdn_sender,
        > reject_non_fqdn_helo_hostname,
        > reject_unknown_reverse_client_hostname,
        > reject_rbl_client foo.example.org
        > reject_rbl_client bar.example.com
        > reject_rhsbl_client rhsbl.example.com
        > reject_rhsbl_sender rhsbl.example.com
        > permit
        >
        > The main problem I see here is that a) certain checks are made
        > redundant, and b) 'minimal' and 'modest' still have some of the
        > "recommended" checks included.

        Don't worry too much about redundant or repeated checks in different
        classes. The impact is negligible.

        >
        >
        > My thought was that maybe I should do something like this instead:
        >
        > reject_non_fqdn_recipient,

        Be careful about rejecting mail from your own users/networks. Some
        desktop mail clients misbehave when the mail is rejected, either
        sending confusing messages to the user or continually retrying.

        > permit_mynetworks,
        > reject_unauth_destination,

        OK.

        > reject_unknown_recipient_domain,

        After reject_unauth_destination, the only domain left is yours. So
        this rule either won't do anything, or will reject your own mail if
        the local DNS hiccups. Probably best to remove it.

        Some folks like to use this rule before permit_mynetworks to prevent
        local users from sending to unknown domains. That's OK, but see my
        earlier comment about rejecting user mail.


        > check_recipient_access ldap:acct_class_ldap,
        > # "recommended", i.e., default stuff here
        > reject_non_fqdn_sender,
        > reject_rbl_client foo.example.org
        > reject_rhsbl_client rhsbl.example.com
        > reject_rhsbl_sender rhsbl.example.com
        > [...]
        >
        > and then have
        > recommended =

        Yes, that should work as expected.

        >
        > [to avoid redundant checks]
        >
        > Will this work, and are there any fatal flaws in my ordering?
        >



        -- Noel Jones
      • Will Yardley
        Thanks so much for the helpful response - just wanted to make sure I was heading in the right direction, and this was exactly what I needed. ... I had omitted
        Message 3 of 6 , Jul 24, 2014
          Thanks so much for the helpful response - just wanted to make sure I was
          heading in the right direction, and this was exactly what I needed.

          On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:

          > > My thought was that maybe I should do something like this instead:
          > >
          > > reject_non_fqdn_recipient,
          >
          > Be careful about rejecting mail from your own users/networks. Some
          > desktop mail clients misbehave when the mail is rejected, either
          > sending confusing messages to the user or continually retrying.

          I had omitted some of the full restrictions for terseness and clarity,
          but there is a 'permit_sasl_authenticated' early in the restrictions.
          End-users are supposed to use smtp-auth, though we don't require it
          outright, so my guess is that this is why the setting hasn't caused any
          problems.

          > After reject_unauth_destination, the only domain left is yours. So
          > this rule either won't do anything, or will reject your own mail if
          > the local DNS hiccups. Probably best to remove it.

          That makes sense; I'll leave reject_unknown_recipient_domain and
          reject_non_fqdn_recipient after permit_sasl_authenticated, but before
          permit_mynetworks and reject_unauth_destination.

          w
        • Will Yardley
          ... This seemed to work as expected in my tests on 2.6.x. However, on 2.3.3, I get: postfix/smtpd[5673]: fatal: restriction class `recommended needs a
          Message 4 of 6 , Jul 24, 2014
            On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:
            > > and then have
            > > recommended =
            >
            > Yes, that should work as expected.

            This seemed to work as expected in my tests on 2.6.x. However, on 2.3.3,
            I get:

            postfix/smtpd[5673]: fatal: restriction class `recommended' needs a definition
          • Noel Jones
            ... ah, I wasn t sure what an empty restriction class would do. Anyway, fix it with a no-op: recommended = static:dunno -- Noel Jones
            Message 5 of 6 , Jul 25, 2014
              On 7/24/2014 10:58 PM, Will Yardley wrote:
              > On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:
              >>> and then have
              >>> recommended =
              >>
              >> Yes, that should work as expected.
              >
              > This seemed to work as expected in my tests on 2.6.x. However, on 2.3.3,
              > I get:
              >
              > postfix/smtpd[5673]: fatal: restriction class `recommended' needs a definition
              >

              ah, I wasn't sure what an empty restriction class would do.

              Anyway, fix it with a no-op:
              recommended = static:dunno



              -- Noel Jones
            • Viktor Dukhovni
              ... Better: recommended = check_client_access static:dunno A bare table triggers an implicit check_mumble_access depending on the SMTP context, but this is not
              Message 6 of 6 , Jul 25, 2014
                On Fri, Jul 25, 2014 at 11:50:22AM -0500, Noel Jones wrote:
                > On 7/24/2014 10:58 PM, Will Yardley wrote:
                > > On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:
                > >>> and then have
                > >>> recommended =
                > >>
                > >> Yes, that should work as expected.
                > >
                > > This seemed to work as expected in my tests on 2.6.x. However, on 2.3.3,
                > > I get:
                > >
                > > postfix/smtpd[5673]: fatal: restriction class `recommended' needs a definition
                > >
                >
                > ah, I wasn't sure what an empty restriction class would do.
                >
                > Anyway, fix it with a no-op:
                > recommended = static:dunno

                Better:

                recommended =
                check_client_access static:dunno

                A bare table triggers an implicit check_mumble_access depending on
                the SMTP context, but this is not always possible, and should not
                be (ab)used.

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