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

check_policy_service does not work as expected: protocol_state=RCPT, even under smtpd_client_restrictions

Expand Messages
  • mig
    Hello, I wrote a policy server (that do RBL checks and dynamically disable slow RBL servers). I supposed the right place is the smptd_client_restrictions:
    Message 1 of 8 , Mar 28, 2009
    • 0 Attachment
      Hello,

      I wrote a policy server (that do RBL checks and dynamically disable slow RBL
      servers). I supposed the right place is the smptd_client_restrictions:

      smtpd_client_restrictions =
      check_policy_service unix:/opt/mailfilter/client_restrictions
      smtpd_helo_required = yes
      smtpd_recipient_restrictions =
      reject_invalid_hostname,
      reject_unauth_pipelining,
      reject_non_fqdn_sender,
      reject_unknown_sender_domain,
      reject_non_fqdn_recipient,
      reject_unknown_recipient_domain,
      permit_sasl_authenticated,
      permit_mynetworks

      Unfortunatelly it doesn't work as expected. The policy is not executed when a
      client connects, but on each RCPT TO. It behaves the same way as if the
      policy was under the smtpd_recipient_restrictions. In my case, it means that
      the RBL checks will be done again for each RCPT TO...

      I tried to put the check_policy_service under different restrictions
      (smtpd_helo_restrictions, smtpd_sender_restrictions), but with the same
      result - it worked, but as if it was in the RCPT state.
      smtpd_data_restrictions is the only state where it works well, so the
      protocol_state=DATA.

      Is this a bug or a feature?

      Thank you for help,
      Jan Molic
    • Wietse Venema
      ... See http://www.postfix.org/SMTPD_ACCESS_README.html. Wietse
      Message 2 of 8 , Mar 28, 2009
      • 0 Attachment
        mig:
        > Hello,
        >
        > I wrote a policy server (that do RBL checks and dynamically disable slow RBL
        > servers). I supposed the right place is the smptd_client_restrictions:
        >
        > smtpd_client_restrictions =
        > check_policy_service unix:/opt/mailfilter/client_restrictions
        > smtpd_helo_required = yes
        > smtpd_recipient_restrictions =
        > reject_invalid_hostname,
        > reject_unauth_pipelining,
        > reject_non_fqdn_sender,
        > reject_unknown_sender_domain,
        > reject_non_fqdn_recipient,
        > reject_unknown_recipient_domain,
        > permit_sasl_authenticated,
        > permit_mynetworks
        >
        > Unfortunatelly it doesn't work as expected. The policy is not executed when a
        > client connects, but on each RCPT TO.

        See http://www.postfix.org/SMTPD_ACCESS_README.html.

        Wietse

        > It behaves the same way as if the
        > policy was under the smtpd_recipient_restrictions. In my case, it means that
        > the RBL checks will be done again for each RCPT TO...
        >
        > I tried to put the check_policy_service under different restrictions
        > (smtpd_helo_restrictions, smtpd_sender_restrictions), but with the same
        > result - it worked, but as if it was in the RCPT state.
        > smtpd_data_restrictions is the only state where it works well, so the
        > protocol_state=DATA.
        >
        > Is this a bug or a feature?
        >
        > Thank you for help,
        > Jan Molic
        >
        >
        >
        >
      • Ralf Hildebrandt
        ... postconf |grep delay_reject -- Ralf Hildebrandt Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
        Message 3 of 8 , Mar 28, 2009
        • 0 Attachment
          * mig <mig@...>:
          > Hello,
          >
          > I wrote a policy server (that do RBL checks and dynamically disable slow RBL
          > servers). I supposed the right place is the smptd_client_restrictions:
          >
          > smtpd_client_restrictions =
          > check_policy_service unix:/opt/mailfilter/client_restrictions
          > smtpd_helo_required = yes
          > smtpd_recipient_restrictions =
          > reject_invalid_hostname,
          > reject_unauth_pipelining,
          > reject_non_fqdn_sender,
          > reject_unknown_sender_domain,
          > reject_non_fqdn_recipient,
          > reject_unknown_recipient_domain,
          > permit_sasl_authenticated,
          > permit_mynetworks
          >
          > Unfortunatelly it doesn't work as expected. The policy is not executed when a
          > client connects, but on each RCPT TO.

          postconf |grep delay_reject

          --
          Ralf Hildebrandt
          Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
          http://www.computerbeschimpfung.de
          Postfix: Something like a wisened old man sitting on the porch outside
          the postoffice. Looks at everyone who passes by with deep suspicion,
          but turns out to be friendly and helpful once he realises you're not
          there to rob the place.
        • Sahil Tandon
          ... By default, smtpd_delay_reject = yes, which means smtpd(8) will wait until the RCPT TO stage of the SMTP conversation before evaluating the
          Message 4 of 8 , Mar 28, 2009
          • 0 Attachment
            On Sat, 28 Mar 2009, mig wrote:

            > I wrote a policy server (that do RBL checks and dynamically disable slow RBL
            > servers). I supposed the right place is the smptd_client_restrictions:
            >
            > smtpd_client_restrictions =
            > check_policy_service unix:/opt/mailfilter/client_restrictions
            > smtpd_helo_required = yes
            > smtpd_recipient_restrictions =
            > reject_invalid_hostname,
            > reject_unauth_pipelining,
            > reject_non_fqdn_sender,
            > reject_unknown_sender_domain,
            > reject_non_fqdn_recipient,
            > reject_unknown_recipient_domain,
            > permit_sasl_authenticated,
            > permit_mynetworks
            >
            > Unfortunatelly it doesn't work as expected. The policy is not executed when a
            > client connects, but on each RCPT TO. It behaves the same way as if the
            > policy was under the smtpd_recipient_restrictions. In my case, it means that
            > the RBL checks will be done again for each RCPT TO...
            >
            > I tried to put the check_policy_service under different restrictions
            > (smtpd_helo_restrictions, smtpd_sender_restrictions), but with the same
            > result - it worked, but as if it was in the RCPT state.
            > smtpd_data_restrictions is the only state where it works well, so the
            > protocol_state=DATA.
            >
            > Is this a bug or a feature?

            By default, smtpd_delay_reject = yes, which means smtpd(8) will wait until
            the RCPT TO stage of the SMTP conversation before evaluating the
            $smtpd_client_restrictions, $smtpd_helo_restrictions and
            $smtpd_sender_restrictions. This is a feature documented in postconf(5).

            --
            Sahil Tandon <sahil@...>
          • mig
            Thanks for reply, But I m still a bit confused about the SMTPD_ACCESS_README.html: Restriction lists are still evaluated in the proper order of (client, helo,
            Message 5 of 8 , Mar 28, 2009
            • 0 Attachment
              Thanks for reply,

              But I'm still a bit confused about the SMTPD_ACCESS_README.html:

              "Restriction lists are still evaluated in the proper order of (client, helo,
              etrn) or (client, helo, sender, recipient, data, or end-of-data)
              restrictions."

              I agree, all restriction lists are evaluated on the RCPT TO (because of the
              delayed reject), but not just after the first RCPT TO. It looks they evaluate
              again on each RCPT TO. So this is a feature?

              Do all items behave like this or is it only the check_policy_service? I mean,
              if everything is evaluated again on each RCPT TO, then if I place
              reject_rbl_client into smtpd_client_restrictions, the rbl check will run
              needlessly more times?

              Thank you,
              Jan


              Dne Saturday 28 of March 2009 23:46:18 Sahil Tandon napsal(a):
              > On Sat, 28 Mar 2009, mig wrote:
              > > I wrote a policy server (that do RBL checks and dynamically disable slow
              > > RBL servers). I supposed the right place is the
              > > smptd_client_restrictions:
              > >
              > > smtpd_client_restrictions =
              > > check_policy_service unix:/opt/mailfilter/client_restrictions
              > > smtpd_helo_required = yes
              > > smtpd_recipient_restrictions =
              > > reject_invalid_hostname,
              > > reject_unauth_pipelining,
              > > reject_non_fqdn_sender,
              > > reject_unknown_sender_domain,
              > > reject_non_fqdn_recipient,
              > > reject_unknown_recipient_domain,
              > > permit_sasl_authenticated,
              > > permit_mynetworks
              > >
              > > Unfortunatelly it doesn't work as expected. The policy is not executed
              > > when a client connects, but on each RCPT TO. It behaves the same way as
              > > if the policy was under the smtpd_recipient_restrictions. In my case, it
              > > means that the RBL checks will be done again for each RCPT TO...
              > >
              > > I tried to put the check_policy_service under different restrictions
              > > (smtpd_helo_restrictions, smtpd_sender_restrictions), but with the same
              > > result - it worked, but as if it was in the RCPT state.
              > > smtpd_data_restrictions is the only state where it works well, so the
              > > protocol_state=DATA.
              > >
              > > Is this a bug or a feature?
              >
              > By default, smtpd_delay_reject = yes, which means smtpd(8) will wait until
              > the RCPT TO stage of the SMTP conversation before evaluating the
              > $smtpd_client_restrictions, $smtpd_helo_restrictions and
              > $smtpd_sender_restrictions. This is a feature documented in postconf(5).
            • Sahil Tandon
              ... Please, don t top-post. ... Can you provide evidence for this claim? ... No. -- Sahil Tandon
              Message 6 of 8 , Mar 28, 2009
              • 0 Attachment
                On Sun, 29 Mar 2009, mig wrote:

                > Thanks for reply,

                Please, don't top-post.

                > But I'm still a bit confused about the SMTPD_ACCESS_README.html:
                >
                > "Restriction lists are still evaluated in the proper order of (client, helo,
                > etrn) or (client, helo, sender, recipient, data, or end-of-data)
                > restrictions."
                >
                > I agree, all restriction lists are evaluated on the RCPT TO (because of the
                > delayed reject), but not just after the first RCPT TO. It looks they evaluate
                > again on each RCPT TO.

                Can you provide evidence for this claim?

                > Do all items behave like this or is it only the check_policy_service? I mean,
                > if everything is evaluated again on each RCPT TO, then if I place
                > reject_rbl_client into smtpd_client_restrictions, the rbl check will run
                > needlessly more times?

                No.

                --
                Sahil Tandon <sahil@...>
              • Wietse Venema
                mig: [ Charset ISO-8859-1 unsupported, converting... ] ... client/helo/sender_restrictions are evaluated with every recipient. One reason for this is that
                Message 7 of 8 , Mar 28, 2009
                • 0 Attachment
                  mig:
                  [ Charset ISO-8859-1 unsupported, converting... ]
                  > Thanks for reply,
                  >
                  > But I'm still a bit confused about the SMTPD_ACCESS_README.html:
                  >
                  > "Restriction lists are still evaluated in the proper order of (client, helo,
                  > etrn) or (client, helo, sender, recipient, data, or end-of-data)
                  > restrictions."
                  >
                  > I agree, all restriction lists are evaluated on the RCPT TO (because of the
                  > delayed reject), but not just after the first RCPT TO. It looks they evaluate
                  > again on each RCPT TO. So this is a feature?

                  client/helo/sender_restrictions are evaluated with every recipient.
                  One reason for this is that recipient information may be used in
                  smtpd_client_restrictions.

                  > Do all items behave like this or is it only the check_policy_service? I mean,
                  > if everything is evaluated again on each RCPT TO, then if I place
                  > reject_rbl_client into smtpd_client_restrictions, the rbl check will run
                  > needlessly more times?

                  Postfix caches the results of its own RBL lookups. It does not
                  cache policy service results.

                  Wietse
                • Jan P. Kessler
                  ... postfwd does asynchronous dnsbl lookups and allows to disable non-responding lists automatically. it also has an integrated cache for dns results. you may
                  Message 8 of 8 , Apr 2, 2009
                  • 0 Attachment
                    mig schrieb:
                    > I wrote a policy server (that do RBL checks and dynamically disable slow RBL
                    > servers). I supposed the right place is the smptd_client_restrictions:
                    >

                    postfwd does asynchronous dnsbl lookups and allows to disable
                    non-responding lists automatically. it also has an integrated cache for
                    dns results. you may find it at http://www.postfwd.org
                  Your message has been successfully submitted and would be delivered to recipients shortly.