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

Re: Exceptions to reject_rbl_client *AND* SASL authentication enforcement

Expand Messages
  • Fabio Sangiovanni
    ... Awesome. I totally missed this part of documentation: http://www.postfix.org/access.5.html [...] OTHER ACTIONS restriction... Apply the named UCE
    Message 1 of 8 , Feb 8, 2013
    • 0 Attachment
      Viktor Dukhovni <postfix-users <at> dukhovni.org> writes:

      >
      > Replace "OK" with:
      >
      > /etc/postfix/whitelist_client.cidr:
      > 192.0.2.1/32 permit_sasl_authenticated
      >


      Awesome. I totally missed this part of documentation:

      http://www.postfix.org/access.5.html
      [...]
      OTHER ACTIONS
      restriction...
      Apply the named UCE restriction(s) (permit, reject,
      reject_unauth_destination, and so on).
      [...]

      Thanks a lot for your help!
    • Fabio Sangiovanni
      ... Hi, thanks for your answer. Yes, that would be useful, except for malware that steals your credentials, and that would be otherwise (hopefully) blocked
      Message 2 of 8 , Feb 11, 2013
      • 0 Attachment
        Noel Jones <njones <at> megan.vbhcs.org> writes:

        > Seems like the easiest solution is to put permit_sasl_authenticated
        > BEFORE reject_rbl_client. Then no whitelisting is needed.
        >
        > -- Noel Jones

        Hi, thanks for your answer.
        Yes, that would be useful, except for malware that steals your credentials,
        and that would be otherwise (hopefully) blocked against lists such as
        Spamhaus XBL. Is it correct?
        I prefer Victor's solution for this reason...

        Thanks again,
        Fabio
      • Noel Jones
        ... Your method of manually whitelisting any IP that happens to be spamhaus listed doesn t scale very well. Every time some authorized user travels somewhere,
        Message 3 of 8 , Feb 11, 2013
        • 0 Attachment
          On 2/11/2013 4:00 AM, Fabio Sangiovanni wrote:
          > Noel Jones <njones <at> megan.vbhcs.org> writes:
          >
          >> Seems like the easiest solution is to put permit_sasl_authenticated
          >> BEFORE reject_rbl_client. Then no whitelisting is needed.
          >>
          >> -- Noel Jones
          >
          > Hi, thanks for your answer.
          > Yes, that would be useful, except for malware that steals your credentials,
          > and that would be otherwise (hopefully) blocked against lists such as
          > Spamhaus XBL. Is it correct?
          > I prefer Victor's solution for this reason...
          >
          > Thanks again,
          > Fabio
          >

          Your method of manually whitelisting any IP that happens to be
          spamhaus listed doesn't scale very well. Every time some authorized
          user travels somewhere, stops at a wifi hotspot, or their home IP
          changes, will need to call you to get whitelisted before they can
          send mail. This might be OK if you have only a handful of users and
          neither you nor they mind a phone call every time they can't send mail.

          A more typical solution is to allow authorized users to send mail
          from wherever they happen to be, and use rate limits on postfix via
          postfwd or similar to alert you to a possibly compromised account.



          -- Noel Jones
        • Fabio Sangiovanni
          ... Hi, thanks again for your advice. My use case is slightly different from the one you describe (ip change is not that frequent), so my restrictions should
          Message 4 of 8 , Feb 11, 2013
          • 0 Attachment
            Noel Jones <njones <at> megan.vbhcs.org> writes:

            > Your method of manually whitelisting any IP that happens to be
            > spamhaus listed doesn't scale very well. Every time some authorized
            > user travels somewhere, stops at a wifi hotspot, or their home IP
            > changes, will need to call you to get whitelisted before they can
            > send mail. This might be OK if you have only a handful of users and
            > neither you nor they mind a phone call every time they can't send mail.
            >
            > A more typical solution is to allow authorized users to send mail
            > from wherever they happen to be, and use rate limits on postfix via
            > postfwd or similar to alert you to a possibly compromised account.
            >
            > -- Noel Jones
            >
            >


            Hi, thanks again for your advice. My use case is slightly different from the one
            you describe (ip change is not that frequent), so my restrictions
            should fit well. I'll be prepared to switch to your paradigm as the situation
            changes.

            Bye,
            Fabio
          • Fabio Sangiovanni
            ... Sorry Viktor, I have another question: what happens if a client is whitelisted AND it fails SASL authentication? I suppose that the following directives
            Message 5 of 8 , Feb 11, 2013
            • 0 Attachment
              Viktor Dukhovni <postfix-users <at> dukhovni.org> writes:

              > Replace "OK" with:
              >
              > /etc/postfix/whitelist_client.cidr:
              > 192.0.2.1/32 permit_sasl_authenticated
              >

              Sorry Viktor,

              I have another question: what happens if a client is whitelisted AND it fails
              SASL authentication?
              I suppose that the following directives are evaluated, aren't they?
              So, in such cases, there is a query to the rbl, another (failed) check for
              SASL authentication (if the IP is not listed), and the final reject due to
              reject_unauth_destination.

              So, is it correct to create the file /etc/postfix/whitelist_client.cidr with
              entries like:
              192.0.2.1/32 permit_sasl_authenticated,reject

              The additional reject should prevent further evaluation of restrictions outside
              (and following) the access table.

              Thanks again for your help.

              Fabio
            • Viktor Dukhovni
              ... The whitelist only applies to authenticated users. Unauthenticated users are treated like everyone else. ... You re working too hard, the suggested
              Message 6 of 8 , Feb 11, 2013
              • 0 Attachment
                On Mon, Feb 11, 2013 at 03:19:52PM +0000, Fabio Sangiovanni wrote:

                > I have another question: what happens if a client is whitelisted AND it fails
                > SASL authentication?

                The whitelist only applies to authenticated users. Unauthenticated users
                are treated like everyone else.

                > I suppose that the following directives are evaluated, aren't they?
                > So, in such cases, there is a query to the rbl, another (failed) check for
                > SASL authentication (if the IP is not listed), and the final reject due to
                > reject_unauth_destination.
                >
                > So, is it correct to create the file /etc/postfix/whitelist_client.cidr with
                > entries like:
                > 192.0.2.1/32 permit_sasl_authenticated,reject
                >
                > The additional reject should prevent further evaluation of restrictions outside
                > (and following) the access table.

                You're working too hard, the suggested settings should work just fine.

                --
                Viktor.
              • Fabii Sangiovanni
                ... Would you be so kind to point me to some readings on the matter? The only relevant piece of documentation seems to be RESTRICTION_CLASS_README, but, even
                Message 7 of 8 , Feb 11, 2013
                • 0 Attachment
                  Viktor Dukhovni <postfix-users <at> dukhovni.org> writes:

                  > You're working too hard, the suggested settings should work just fine.

                  Would you be so kind to point me to some readings on the matter? The only
                  relevant piece of documentation seems to be RESTRICTION_CLASS_README, but, even
                  after reading that, it's not clear to me *why* those settings should work
                  equally (that is, with or without the final reject), nor what is the default in
                  a sequnce of restrictions within an access table...
                  I don't want to just set the right configuration once for all, I'm interested in
                  developing a deeper knowledge on the topic. :)

                  As usual, thanks for your time.

                  Fabio
                • Viktor Dukhovni
                  ... You don t want to explicitly blacklist RBL addresses (for unauthenticated users). The addresses may be deleted from the RBL at some point. The proposed
                  Message 8 of 8 , Feb 12, 2013
                  • 0 Attachment
                    On Mon, Feb 11, 2013 at 10:29:38PM +0000, Fabii Sangiovanni wrote:

                    > Viktor Dukhovni <postfix-users <at> dukhovni.org> writes:
                    >
                    > > You're working too hard, the suggested settings should work just fine.
                    >
                    > Would you be so kind to point me to some readings on the matter?

                    You don't want to explicitly blacklist RBL addresses (for unauthenticated
                    users). The addresses may be deleted from the RBL at some point.

                    The proposed solution simply whitelists the address for authenticated
                    users and otherwise treats exactly as any other address.

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