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

Bypass RBL checks for certain users

Expand Messages
  • Chris
    Hi all. I ve been asked to skip RBL checks for certain users on the domain. How can I do that without disabling the for everybody else? We re using virtual
    Message 1 of 10 , Dec 3, 2012
    • 0 Attachment
      Hi all.
      I've been asked to skip RBL checks for certain users on the domain. How can I
      do that without disabling the for everybody else?
      We're using virtual mailboxes on mysql.

      Thanks,

      Chris
    • Noel Jones
      ... Before we start, a reminder that SMTP doesn t have a good mechanism for per-recipient policy. If a message has multiple recipients, only one policy policy
      Message 2 of 10 , Dec 3, 2012
      • 0 Attachment
        On 12/3/2012 12:40 PM, Chris wrote:
        > Hi all.
        > I've been asked to skip RBL checks for certain users on the domain. How can I
        > do that without disabling the for everybody else?
        > We're using virtual mailboxes on mysql.
        >
        > Thanks,
        >
        > Chris
        >
        >


        Before we start, a reminder that SMTP doesn't have a good mechanism
        for per-recipient policy. If a message has multiple recipients,
        only one policy policy can be used, usually the more restrictive policy.

        There are (in general) two ways to do this. Which you choose
        depends on your needs.

        For a recipient that you want to never reject mail for, such as
        abuse@ or sales@, add them to a whitelist before your UCE
        restrictions. This example assumes all your UCE restrictions are
        under smtpd_recipient_restrictions:
        # main.cf
        smtpd_recipient_restrictions =
        permit_mynetworks
        reject_unauth_destination
        check_recipient_access hash:/etc/postfix/recipient_whitelist
        ... other UCE checks ...

        # recipient_whitelist
        grumpy_cfo@... permit_auth_destination

        ** IMPORTANT ** the check_recipient_access list must come /after/
        reject_unauth_destination to prevent open-relay accidents.
        http://www.postfix.org/SMTPD_ACCESS_README.html#danger



        For finer control, eg. specifying which controls to use for a group
        of users, use smtpd_restriction_classes. Further examples of
        restriction classes can be found in the list archives.
        http://www.postfix.org/postconf.5.html#smtpd_restriction_classes
        http://www.postfix.org/RESTRICTION_CLASS_README.html




        -- Noel Jones
      • /dev/rob0
        ... If you re only using good, safe lists, you re only rejecting mail which probably should be rejected. What is the goal? This is not possible if you re using
        Message 3 of 10 , Dec 3, 2012
        • 0 Attachment
          On Mon, Dec 03, 2012 at 07:40:24PM +0100, Chris wrote:
          > I've been asked to skip RBL checks for certain users on the domain.
          > How can I do that without disabling the for everybody else?

          If you're only using good, safe lists, you're only rejecting mail
          which probably should be rejected. What is the goal?

          This is not possible if you're using postscreen, which you did not
          mention. In that case perhaps the best solution is to more carefully
          choose the DNSBL services you are using. I can recommend both Zen and
          Barracuda's BRBL as safe and effective for mainstream use. (To the
          point: if you're using those and rejecting real mail, you can be
          certain that you're not the only site they are unable to reach; the
          sending site needs to fix the problems that caused the listing.)

          http://www.spamhaus.org/zen/ and
          http://www.barracudacentral.org/rbl

          If you're using unsafe and aggressive lists in smtpd restrictions,
          you can implement what you describe by means of restriction classes.
          It's hard work and does not scale well. I have shown an example of
          this in my Postfix/SQLite howto linked from the web address below.

          http://www.postfix.org/RESTRICTION_CLASS_README.html

          Perhaps a better choice is to write a custom policy service, or to
          tweak an existing one into doing what you need.

          http://www.postfix.org/SMTPD_POLICY_README.html
          http://www.postfix.org/addon.html#policy
          --
          http://rob0.nodns4.us/ -- system administration and consulting
          Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
        • Noel Jones
          ... Nonsense, if the restrictions are done during the RCPT stage, you can reliably reject some recipients while accepting others. But I agree with the rest of
          Message 4 of 10 , Dec 3, 2012
          • 0 Attachment
            On 12/3/2012 1:18 PM, Noel Jones wrote:
            > On 12/3/2012 12:40 PM, Chris wrote:
            >> Hi all.
            >> I've been asked to skip RBL checks for certain users on the domain. How can I
            >> do that without disabling the for everybody else?
            >> We're using virtual mailboxes on mysql.
            >>
            >> Thanks,
            >>
            >> Chris
            >>
            >>
            >
            >
            > Before we start, a reminder that SMTP doesn't have a good mechanism
            > for per-recipient policy. If a message has multiple recipients,
            > only one policy policy can be used, usually the more restrictive policy.


            Nonsense, if the restrictions are done during the RCPT stage, you
            can reliably reject some recipients while accepting others.

            But I agree with the rest of your post.


            >
            > There are (in general) two ways to do this. Which you choose
            > depends on your needs.
            >
            > For a recipient that you want to never reject mail for, such as
            > abuse@ or sales@, add them to a whitelist before your UCE
            > restrictions. This example assumes all your UCE restrictions are
            > under smtpd_recipient_restrictions:
            > # main.cf
            > smtpd_recipient_restrictions =
            > permit_mynetworks
            > reject_unauth_destination
            > check_recipient_access hash:/etc/postfix/recipient_whitelist
            > ... other UCE checks ...
            >
            > # recipient_whitelist
            > grumpy_cfo@... permit_auth_destination
            >
            > ** IMPORTANT ** the check_recipient_access list must come /after/
            > reject_unauth_destination to prevent open-relay accidents.
            > http://www.postfix.org/SMTPD_ACCESS_README.html#danger
            >
            >
            >
            > For finer control, eg. specifying which controls to use for a group
            > of users, use smtpd_restriction_classes. Further examples of
            > restriction classes can be found in the list archives.
            > http://www.postfix.org/postconf.5.html#smtpd_restriction_classes
            > http://www.postfix.org/RESTRICTION_CLASS_README.html
            >
            >
            >
            >
            > -- Noel Jones
            >
          • Chris
            On Mon, 3 Dec 2012 13:26:25 -0600 /dev/rob0 wrote ... I ve looked through the logs and the last couple of days spamcop has blocked most of the
            Message 5 of 10 , Dec 3, 2012
            • 0 Attachment
              On Mon, 3 Dec 2012 13:26:25 -0600 /dev/rob0 <rob0@...> wrote

              > On Mon, Dec 03, 2012 at 07:40:24PM +0100, Chris wrote:
              > > I've been asked to skip RBL checks for certain users on the domain.
              > > How can I do that without disabling the for everybody else?
              >
              > If you're only using good, safe lists, you're only rejecting mail
              > which probably should be rejected. What is the goal?
              >
              > This is not possible if you're using postscreen, which you did not
              > mention. In that case perhaps the best solution is to more carefully
              > choose the DNSBL services you are using. I can recommend both Zen and
              > Barracuda's BRBL as safe and effective for mainstream use. (To the
              > point: if you're using those and rejecting real mail, you can be
              > certain that you're not the only site they are unable to reach; the
              > sending site needs to fix the problems that caused the listing.)
              >
              > http://www.spamhaus.org/zen/ and
              > http://www.barracudacentral.org/rbl
              >
              > If you're using unsafe and aggressive lists in smtpd restrictions,
              > you can implement what you describe by means of restriction classes.
              > It's hard work and does not scale well. I have shown an example of
              > this in my Postfix/SQLite howto linked from the web address below.
              >
              > http://www.postfix.org/RESTRICTION_CLASS_README.html
              >
              > Perhaps a better choice is to write a custom policy service, or to
              > tweak an existing one into doing what you need.
              >
              > http://www.postfix.org/SMTPD_POLICY_README.html
              > http://www.postfix.org/addon.html#policy
              > --
              > http://rob0.nodns4.us/ -- system administration and consulting
              > Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

              I've looked through the logs and the last couple of days spamcop has blocked
              most of the legitimate mail the users have been complaining about.
              We're currently checking against those lists:

              smtpd_client_restrictions =
              permit_mynetworks,
              permit_sasl_authenticated,
              check_recipient_access hash:/etc/postfix/cidr_bypass,
              check_client_access cidr:/etc/postfix/cidr_checks,
              check_client_access cidr:/etc/postfix/cidr_asia,
              check_client_access pcre:/etc/postfix/fqrdns.regexp,
              reject_rbl_client bl.mailspike.net,
              reject_rbl_client bl.spamcop.net,
              reject_rbl_client dyna.spamrats.com,
              reject_rbl_client noptr.spamrats.com,
              reject_rbl_client spam.spamrats.com,
              reject_rbl_client zen.spamhaus.org,
              permit

              As far as I'm concerned, when a user starts nagging about this rejected message
              or that, I'll let him bypass the checks and deal with the spam himself. That is
              until he comes back crawling and begging for help :)

              I've looked into the classes definition. Where does the parameter go? Before
              'permit_mynetworks'?

              Chris
            • /dev/rob0
              ... snip ... Ah, so there is your answer. No, I d never use Spamcop for outright rejection. I don t even believe that Spamcop recommends such use. It s useful
              Message 6 of 10 , Dec 3, 2012
              • 0 Attachment
                On Mon, Dec 03, 2012 at 09:51:34PM +0100, Chris wrote:
                > On Mon, 3 Dec 2012 13:26:25 -0600 /dev/rob0 <rob0@...> wrote
                > > On Mon, Dec 03, 2012 at 07:40:24PM +0100, Chris wrote:
                > > > I've been asked to skip RBL checks for certain users on
                > > > the domain. How can I do that without disabling the for
                > > > everybody else?
                > >
                > > If you're only using good, safe lists, you're only rejecting
                > > mail which probably should be rejected. What is the goal?
                snip

                > I've looked through the logs and the last couple of days spamcop
                > has blocked most of the legitimate mail the users have been
                > complaining about. We're currently checking against those lists:

                Ah, so there is your answer. No, I'd never use Spamcop for outright
                rejection. I don't even believe that Spamcop recommends such use.
                It's useful in a scoring system, such as postscreen, and I do use it
                there.

                > smtpd_client_restrictions =
                > permit_mynetworks,
                > permit_sasl_authenticated,
                > check_recipient_access hash:/etc/postfix/cidr_bypass,
                > check_client_access cidr:/etc/postfix/cidr_checks,
                > check_client_access cidr:/etc/postfix/cidr_asia,
                > check_client_access pcre:/etc/postfix/fqrdns.regexp,
                > reject_rbl_client bl.mailspike.net,

                I'm not familiar with this. If you are, and you are okay with their
                listing and delisting policies, fine. Otherwise, don't use a DNSBL
                unless you are familiar with their policies and the way it is run.

                > reject_rbl_client bl.spamcop.net,

                I would definitely take this out.

                > reject_rbl_client dyna.spamrats.com,
                > reject_rbl_client noptr.spamrats.com,
                > reject_rbl_client spam.spamrats.com,

                I'm not familiar with these lists either. Cute name. :)

                > reject_rbl_client zen.spamhaus.org,
                > permit
                >
                > As far as I'm concerned, when a user starts nagging about this
                > rejected message or that, I'll let him bypass the checks and deal
                > with the spam himself. That is until he comes back crawling and
                > begging for help :)

                Well, I still try to keep the spam out of my server. I don't want to
                help spammers in any way.

                > I've looked into the classes definition. Where does the parameter
                > go? Before 'permit_mynetworks'?

                I'm not sure what parameter you are talking about. If you are
                interested in restriction classes, do take the time to read the
                "Postfix Per-Client/User/etc. Access Control" document, a/k/a
                RESTRICTION_CLASS_README.html . It probably has the answer to your
                question.
                --
                http://rob0.nodns4.us/ -- system administration and consulting
                Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
              • Chris
                On Mon, 3 Dec 2012 15:41:45 -0600 /dev/rob0 wrote ... Thanks. I m already using a hash db to map users that opted out of greylisting in
                Message 7 of 10 , Dec 3, 2012
                • 0 Attachment
                  On Mon, 3 Dec 2012 15:41:45 -0600 /dev/rob0 <rob0@...> wrote

                  > On Mon, Dec 03, 2012 at 09:51:34PM +0100, Chris wrote:
                  > > On Mon, 3 Dec 2012 13:26:25 -0600 /dev/rob0 <rob0@...> wrote
                  > > > On Mon, Dec 03, 2012 at 07:40:24PM +0100, Chris wrote:
                  > > > > I've been asked to skip RBL checks for certain users on
                  > > > > the domain. How can I do that without disabling the for
                  > > > > everybody else?
                  > > >
                  > > > If you're only using good, safe lists, you're only rejecting
                  > > > mail which probably should be rejected. What is the goal?
                  > snip
                  >
                  > > I've looked through the logs and the last couple of days spamcop
                  > > has blocked most of the legitimate mail the users have been
                  > > complaining about. We're currently checking against those lists:
                  >
                  > Ah, so there is your answer. No, I'd never use Spamcop for outright
                  > rejection. I don't even believe that Spamcop recommends such use.
                  > It's useful in a scoring system, such as postscreen, and I do use it
                  > there.
                  >
                  > > smtpd_client_restrictions =
                  > > permit_mynetworks,
                  > > permit_sasl_authenticated,
                  > > check_recipient_access hash:/etc/postfix/cidr_bypass,
                  > > check_client_access cidr:/etc/postfix/cidr_checks,
                  > > check_client_access cidr:/etc/postfix/cidr_asia,
                  > > check_client_access pcre:/etc/postfix/fqrdns.regexp,
                  > > reject_rbl_client bl.mailspike.net,
                  >
                  > I'm not familiar with this. If you are, and you are okay with their
                  > listing and delisting policies, fine. Otherwise, don't use a DNSBL
                  > unless you are familiar with their policies and the way it is run.
                  >
                  > > reject_rbl_client bl.spamcop.net,
                  >
                  > I would definitely take this out.
                  >
                  > > reject_rbl_client dyna.spamrats.com,
                  > > reject_rbl_client noptr.spamrats.com,
                  > > reject_rbl_client spam.spamrats.com,
                  >
                  > I'm not familiar with these lists either. Cute name. :)
                  >
                  > > reject_rbl_client zen.spamhaus.org,
                  > > permit
                  > >
                  > > As far as I'm concerned, when a user starts nagging about this
                  > > rejected message or that, I'll let him bypass the checks and deal
                  > > with the spam himself. That is until he comes back crawling and
                  > > begging for help :)
                  >
                  > Well, I still try to keep the spam out of my server. I don't want to
                  > help spammers in any way.
                  >
                  > > I've looked into the classes definition. Where does the parameter
                  > > go? Before 'permit_mynetworks'?
                  >
                  > I'm not sure what parameter you are talking about. If you are
                  > interested in restriction classes, do take the time to read the
                  > "Postfix Per-Client/User/etc. Access Control" document, a/k/a
                  > RESTRICTION_CLASS_README.html . It probably has the answer to your
                  > question.
                  > --

                  Thanks.
                  I'm already using a hash db to map users that opted out of greylisting in
                  smtpd_recipient_restrictions. Map's in the form of

                  user@... OK

                  Can I re-use the same list in the position Neil suggested?
                • Stan Hoeppner
                  ... Correct. From: http://www.spamcop.net/fom-serve/cache/291.html We recommend that when using any spam filtering method, users be given access to the
                  Message 8 of 10 , Dec 3, 2012
                  • 0 Attachment
                    On 12/3/2012 3:41 PM, /dev/rob0 wrote:

                    > Ah, so there is your answer. No, I'd never use Spamcop for outright
                    > rejection. I don't even believe that Spamcop recommends such use.

                    Correct. From: http://www.spamcop.net/fom-serve/cache/291.html

                    "We recommend that when using any spam filtering method, users be given
                    access to the filtered mail - don't block the mail as documented here,
                    but store it in a separate mailbox. Or tag it and provide users
                    documentation so that they can filter based on the tags in their own
                    MUA. We provide this information only for administrators who cannot use
                    a more subtle approach for whatever reason."

                    Not all DNSBLs are created equal, and this is intentional, otherwise
                    we'd have 100s of mirrors of one DNSBL instead of 100s of unique DNSBLs.
                    Zen and BRBL have proven to be pretty safe for outright rejection.
                    Others such as Spamcop, various SORBS lists, Five-ten, some UCE-Protect
                    lists, etc, have proven to be unsafe for outright blocking and should
                    only be used in scoring systems.

                    FWIW Spamassassin by default queries 5 DNSBLs and two RHSBLs:

                    http://wiki.apache.org/spamassassin/DnsBlocklists

                    So if you're using SA, it's probably best to use Zen and BRBL in
                    postscreen or smtpd to cut down the load on SA, and let SA handle the
                    remainder of the DNSBL workload.

                    --
                    Stan
                  • Benny Pedersen
                    ... make one restriction class pr recipient and make a recipient check with result of the restriction class ... it would be nice with a custom policy server
                    Message 9 of 10 , Dec 5, 2012
                    • 0 Attachment
                      Chris skrev den 03-12-2012 19:40:

                      > I've been asked to skip RBL checks for certain users on the domain.
                      > How can I
                      > do that without disabling the for everybody else?

                      make one restriction class pr recipient

                      and make a recipient check with result of the restriction class

                      > We're using virtual mailboxes on mysql.

                      it would be nice with a custom policy server with this in mind, but so
                      far its could be simple with postfwd without restriction classes in
                      main.cf
                    • Benny Pedersen
                      ... nope, OK is accept all recipient, so it just accept not really what you want to disable greylist, to make it restriction class use classname as result in
                      Message 10 of 10 , Dec 5, 2012
                      • 0 Attachment
                        Chris skrev den 03-12-2012 23:52:

                        > I'm already using a hash db to map users that opted out of
                        > greylisting in
                        > smtpd_recipient_restrictions. Map's in the form of
                        >
                        > user@... OK
                        >
                        > Can I re-use the same list in the position Neil suggested?

                        nope, OK is accept all recipient, so it just accept not really what you
                        want to disable greylist, to make it restriction class use classname as
                        result in place of OK

                        eg: user@... NOGREYLIST

                        and NOGREYLIST is just an empty restriction class name in main.cf

                        then remove other restrictions in main.cf over to other classnames and
                        then pr user let them have it, for default you can make one class
                        default for all users

                        eq: . DEFAULT

                        with postfwd its more simple
                      Your message has been successfully submitted and would be delivered to recipients shortly.