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

Re: Exceptions to reject_rbl_client *AND* SASL authentication enforcement

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.