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

Compromised Passwords

Expand Messages
  • Homer Wilson Smith
    Dear Gentle Folk, What is the state of the art in dealing with users whose SASL password has been compromised? Running CentOS, and latest postfix. When a
    Message 1 of 15 , Mar 4, 2014
      Dear Gentle Folk,

      What is the state of the art in dealing with users whose SASL password
      has been compromised?

      Running CentOS, and latest postfix.

      When a password gets compromised, spam starts to pour out of the
      server from endless numbers of IP's, to endless numbers of addresses.

      Rate limiting is interesting but doesn't really stop the spam.

      Counting client=[IP] addresses until a threshold is reached
      is highly effective, but then what? Change their password?

      Thanks in advance.

      Homer

      ------------------------------------------------------------------------
      Homer Wilson Smith Clean Air, Clear Water, Art Matrix - Lightlink
      (607) 277-0959 A Green Earth, and Peace, Internet, Ithaca NY
      homer@... Is that too much to ask? http://www.lightlink.com
    • Florian Pritz
      ... Use postfwd or similar to rate-limit to say 100 mails/recipients per 6 hours. If the limit is triggered look at the logs and if it looks like spammers
      Message 2 of 15 , Mar 4, 2014
        On 04.03.2014 23:38, Homer Wilson Smith wrote:
        > Rate limiting is interesting but doesn't really stop the spam.

        Use postfwd or similar to rate-limit to say 100 mails/recipients per 6
        hours. If the limit is triggered look at the logs and if it looks like
        spammers disable the account and tell the user how to get it back.

        If you have lots of those cases educate your users about spyware or
        password sharing.
      • Venkat
        ... We are using policyd to manage quotas on e-mail send outs. You can also use a log monitor like swatch to alert you if an account exceeds quota. At this
        Message 3 of 15 , Mar 4, 2014


             When a password gets compromised, spam starts to pour out of the
          server from endless numbers of IP's, to endless numbers of addresses.

             Rate limiting is interesting but doesn't really stop the spam.

             Counting client=[IP] addresses until a threshold is reached
          is highly effective, but then what?  Change their password?


          We are using policyd to manage quotas on e-mail send outs. You can also
          use a log monitor like swatch to alert you if an account exceeds quota. At this
          point the account can be disabled till the user changes their password. Also,
          policyd supports things like rejecting or holding e-mails if the quota is exceeded so
          spam does not go out anymore. You can also script automatic disabling of accounts
          based on quota violations. We find that blacklisting usually only happens when a very
          large number of spam escapes, so rate limiting per account (e-mail address) is quite
          effective.
        • LuKreme
          ... are there specific advantages/disadvantages with policed or postfw? They look like they can do much the same thing, so is there a reason other than
          Message 4 of 15 , Mar 4, 2014
            On 04 Mar 2014, at 15:47 , Florian Pritz <bluewind@...> wrote:
            > Use postfwd

            On 04 Mar 2014, at 20:24 , Venkat <mvenkatsub@...> wrote:
            > We are using policyd

            are there specific advantages/disadvantages with policed or postfw? They look like they can do much the same thing, so is there a reason other than preference to choose one over the other?

            Are there other options to consider?

            Does either of these integrate with dovecot better or worse (I wouldn't think that would be relevant, but maybe)?

            --
            One by one the bulbs burned out, like long lives come to their expected
            ends.
          • Rodolfo González González
            ... I m constantly facing the same problem (passwords comprimised, accounts abused). May you be so gentle to share your policyd configuration? It would be
            Message 5 of 15 , Mar 4, 2014
              El 04/03/2014 09:24 p.m., Venkat escribió:
              >> When a password gets compromised, spam starts to pour out of the
              >> server from endless numbers of IP's, to endless numbers of addresses.
              >>
              >> Rate limiting is interesting but doesn't really stop the spam.
              >>
              >> Counting client=[IP] addresses until a threshold is reached
              >> is highly effective, but then what? Change their password?
              >>
              > We are using policyd to manage quotas on e-mail send outs.


              I'm constantly facing the same problem (passwords comprimised, accounts
              abused). May you be so gentle to share your policyd configuration? It
              would be really helpful. Thank you in advanced.
            • tobi
              ... from my experience the only thing that really stops the spam Maybe it s anoying for the account owner but it works most reliable. Counting IPs might help
              Message 6 of 15 , Mar 5, 2014
                Am 04.03.2014 23:38, schrieb Homer Wilson Smith:
                > Change their password?
                from my experience the only thing that really stops the spam
                Maybe it's anoying for the account owner but it works most reliable.
                Counting IPs might help also but what if the spammer uses the same src
                ip for its garbage? Your server would be on blacklists and all clients
                are affected.
                So imho it's really better to change passwords, that case only one user
                is affected.
                Have a published abuse contact and react on complains promptly also helps.
                To make it harder for the spammers to get login credentials we use
                fail2ban which monitors maillogs for failed logins and blocks IPs after
                X numbers of failed logins. The ban time we keep just some minutes, but
                thats enough for most of the bruteforcers to go to another server
              • Blake Hudson
                ... Just to confirm what others have said. Yes. Monitor activity for abusive/suspicious behavior and take action to stop it as soon as it s discovered. If you
                Message 7 of 15 , Mar 5, 2014
                  Homer Wilson Smith wrote the following on 3/4/2014 4:38 PM:
                  >
                  > Dear Gentle Folk,
                  >
                  > What is the state of the art in dealing with users whose SASL password
                  > has been compromised?
                  >
                  > Running CentOS, and latest postfix.
                  >
                  > When a password gets compromised, spam starts to pour out of the
                  > server from endless numbers of IP's, to endless numbers of addresses.
                  >
                  > Rate limiting is interesting but doesn't really stop the spam.
                  >
                  > Counting client=[IP] addresses until a threshold is reached
                  > is highly effective, but then what? Change their password?
                  >
                  > Thanks in advance.
                  >
                  > Homer
                  >

                  Just to confirm what others have said. Yes. Monitor activity for
                  abusive/suspicious behavior and take action to stop it as soon as it's
                  discovered. If you can automate it, even better.

                  While one could use a policy server, we chose to use an out of band
                  monitoring solution that used the postfix logs. We track emails sent and
                  then geolocate by IP of the client. If a single customer is
                  simultaneously (or very quickly) spending time in several countries or
                  continents then we know there's a problem. This has had a very low false
                  positive hit rate and does a good job of catching most of the abuse we
                  see coming from our customer accounts. We use other thresholds based on
                  volume to catch spam sent from one or two IP addresses. Like another
                  poster, we also use fail2ban, anvil, and have minimum password
                  requirements to help create a layered solution to slow or prevent abuse
                  in an automatic fashion.

                  We typically change the password on accounts flagged for abuse and then
                  contact the customer to inform them of the problem and recommend they
                  take action to secure their systems and change their passwords on any
                  other accounts that may have shared similar credentials.

                  --Blake
                • Venkat
                  ... I sent you an email with our configuration/notes. If anyone else is interested, let me know. cheers, VM
                  Message 8 of 15 , Mar 5, 2014

                    I'm constantly facing the same problem (passwords comprimised, accounts abused). May you be so gentle to share your policyd configuration? It would be really helpful. Thank you in advanced.

                    I sent you an email with our configuration/notes. If anyone else is interested, let me know.

                    cheers,

                    VM
                  • lconrad@...
                    ... We run a dedicated outbound mx, omx1, which runs postfwd tht does sender rate limiting, at 3 levels of quantity. This box s my_networks contains only the
                    Message 9 of 15 , Mar 5, 2014
                      On Wednesday 05/03/2014 at 9:25 am, Blake Hudson wrote:
                      >
                      > Homer Wilson Smith wrote the following on 3/4/2014 4:38 PM:
                      >>
                      >>
                      >> Dear Gentle Folk,
                      >>
                      >> What is the state of the art in dealing with users whose SASL
                      >> password
                      >> has been compromised?
                      >>
                      >> Running CentOS, and latest postfix.
                      >>
                      >> When a password gets compromised, spam starts to pour out of
                      >> the
                      >> server from endless numbers of IP's, to endless numbers of addresses.
                      >>
                      >> Rate limiting is interesting but doesn't really stop the spam.
                      >>
                      >> Counting client=[IP] addresses until a threshold is reached
                      >> is highly effective, but then what? Change their password?
                      >>
                      >> Thanks in advance.
                      >>
                      >> Homer
                      >>
                      >
                      > Just to confirm what others have said. Yes. Monitor activity for
                      > abusive/suspicious behavior and take action to stop it as soon as it's
                      > discovered. If you can automate it, even better.
                      >
                      > While one could use a policy server, we chose to use an out of band
                      > monitoring solution that used the postfix logs. We track emails sent
                      > and then geolocate by IP of the client. If a single customer is
                      > simultaneously (or very quickly) spending time in several countries or
                      > continents then we know there's a problem. This has had a very low
                      > false positive hit rate and does a good job of catching most of the
                      > abuse we see coming from our customer accounts. We use other
                      > thresholds based on volume to catch spam sent from one or two IP
                      > addresses. Like another poster, we also use fail2ban, anvil, and have
                      > minimum password requirements to help create a layered solution to
                      > slow or prevent abuse in an automatic fashion.
                      >
                      > We typically change the password on accounts flagged for abuse and
                      > then contact the customer to inform them of the problem and recommend
                      > they take action to secure their systems and change their passwords on
                      > any other accounts that may have shared similar credentials.
                      >
                      > --Blake

                      We run a dedicated outbound mx, omx1, which runs postfwd tht does
                      sender rate limiting, at 3 levels of quantity. This box's my_networks
                      contains only the 3 IPs of our 3 mail servers.


                      50 msgs max for everybody not whitelisted for the 50 msg limit.


                      700 msgs max for users we know are legit volume senders send more than
                      50 but less than 700 are legit volume senders


                      a few legit senders send over 700, so they have their own whitelist.


                      2000 msgs max for everybody, since no legit user sends that many. So
                      even if one of the above whitelisted senders gets cracked, the cracker
                      is HOLDed at 2000 msgs.

                      when these limits are hit, postfwd returns a HOLD action to postfix
                      for that sender.

                      Monit is watching the HOLD queue and sends an alert.

                      On the box doing SMTP AUTH submission, we observed how many different
                      IPs legit users submitted from per day. that number was 10 IPs.


                      We run a script every 10 minutes that checks PER THIS HOUR for any
                      SMTP AUTH login that exceeds 10 IPs.


                      That script doesn't react to block that cracked SMTP AUTH user (that's
                      next), but does email an alert with username and number of SMTP AUTH
                      IPs.

                      this two-level checking has, so far, killed our exposure to password
                      cracks.


                      Len



                      >
                    • Paul A
                      What has worked for me. Develop a policy where user must have 8 char min password that is not dictionary based. Linux Pam for example helps with this. Then
                      Message 10 of 15 , Mar 5, 2014
                        What has worked for me.

                        Develop a policy where user must have 8 char min password that is not
                        dictionary based. Linux Pam for example helps with this.

                        Then obtain and run fail2ban against your smtp/pop/imap logs. Most passwords
                        are guessed using dictionary attacks, which fail2ban you can blacklist ips
                        if they get the password wrong X number of times.

                        This will not stop 100% of the spam due to compromised accounts as some
                        accounts are compromised from the users PC but for me it has made a huge
                        improvement, it has cut down on spam generated from my servers by 98%. The
                        other thing to do is subscribe to yahoo/aol/etc spam feedback loops as this
                        will let you know if there is spam from your network and email you at which
                        point you can minimize the issue and fix the problem.


                        I used to have an issue with compromised accounts generating spam but using
                        the combination of things I mentioned above it have almost no issues. I now
                        go several months without any issues and haven't gotten blacklisted in years
                        and this is running 4 smtp servers.

                        p

                        -----Original Message-----
                        From: owner-postfix-users@...
                        [mailto:owner-postfix-users@...] On Behalf Of lconrad@...
                        Sent: Wednesday, March 05, 2014 4:42 PM
                        To: postfix-users@...
                        Subject: Re: Compromised Passwords





                        On Wednesday 05/03/2014 at 9:25 am, Blake Hudson wrote:
                        >
                        > Homer Wilson Smith wrote the following on 3/4/2014 4:38 PM:
                        >>
                        >>
                        >> Dear Gentle Folk,
                        >>
                        >> What is the state of the art in dealing with users whose SASL
                        >> password has been compromised?
                        >>
                        >> Running CentOS, and latest postfix.
                        >>
                        >> When a password gets compromised, spam starts to pour out of
                        >> the server from endless numbers of IP's, to endless numbers of
                        >> addresses.
                        >>
                        >> Rate limiting is interesting but doesn't really stop the spam.
                        >>
                        >> Counting client=[IP] addresses until a threshold is reached is
                        >> highly effective, but then what? Change their password?
                        >>
                        >> Thanks in advance.
                        >>
                        >> Homer
                        >>
                        >
                        > Just to confirm what others have said. Yes. Monitor activity for
                        > abusive/suspicious behavior and take action to stop it as soon as it's
                        > discovered. If you can automate it, even better.
                        >
                        > While one could use a policy server, we chose to use an out of band
                        > monitoring solution that used the postfix logs. We track emails sent
                        > and then geolocate by IP of the client. If a single customer is
                        > simultaneously (or very quickly) spending time in several countries or
                        > continents then we know there's a problem. This has had a very low
                        > false positive hit rate and does a good job of catching most of the
                        > abuse we see coming from our customer accounts. We use other
                        > thresholds based on volume to catch spam sent from one or two IP
                        > addresses. Like another poster, we also use fail2ban, anvil, and have
                        > minimum password requirements to help create a layered solution to
                        > slow or prevent abuse in an automatic fashion.
                        >
                        > We typically change the password on accounts flagged for abuse and
                        > then contact the customer to inform them of the problem and recommend
                        > they take action to secure their systems and change their passwords on
                        > any other accounts that may have shared similar credentials.
                        >
                        > --Blake

                        We run a dedicated outbound mx, omx1, which runs postfwd tht does sender
                        rate limiting, at 3 levels of quantity. This box's my_networks contains
                        only the 3 IPs of our 3 mail servers.


                        50 msgs max for everybody not whitelisted for the 50 msg limit.


                        700 msgs max for users we know are legit volume senders send more than
                        50 but less than 700 are legit volume senders


                        a few legit senders send over 700, so they have their own whitelist.


                        2000 msgs max for everybody, since no legit user sends that many. So
                        even if one of the above whitelisted senders gets cracked, the cracker
                        is HOLDed at 2000 msgs.

                        when these limits are hit, postfwd returns a HOLD action to postfix
                        for that sender.

                        Monit is watching the HOLD queue and sends an alert.

                        On the box doing SMTP AUTH submission, we observed how many different
                        IPs legit users submitted from per day. that number was 10 IPs.


                        We run a script every 10 minutes that checks PER THIS HOUR for any
                        SMTP AUTH login that exceeds 10 IPs.


                        That script doesn't react to block that cracked SMTP AUTH user (that's
                        next), but does email an alert with username and number of SMTP AUTH
                        IPs.

                        this two-level checking has, so far, killed our exposure to password
                        cracks.


                        Len



                        >
                      • Adam Moffett
                        Homer: Two steps eliminated this problem for us: 1) Accounts with more than 6 failed login attempts in a 10 minute period are disabled for 10 minutes. This
                        Message 11 of 15 , Mar 6, 2014
                          Homer:

                          Two steps eliminated this problem for us:

                          1) Accounts with more than 6 failed login attempts in a 10 minute period
                          are disabled for 10 minutes. This makes brute force methods to find
                          passwords almost impossible.

                          2) Limit to 200 outgoing messages per day per user. We'll raise it to
                          any reasonable value for an individual account. I.E.: We'll let you
                          send 1000 per day so you can get your church newsletter out, but we
                          won't remove the limit completely and let you spam (knowingly or not).
                          This minimizes the damage if a password is still compromised.

                          200 is a pretty high limit. Very few people send more than 50 in a day,
                          and almost nobody sends more than 100. We set it at 200 so we wouldn't
                          have to hear from anybody who isn't bulk mailing.

                          >
                          > Dear Gentle Folk,
                          >
                          > What is the state of the art in dealing with users whose SASL password
                          > has been compromised?
                          >
                          > Running CentOS, and latest postfix.
                          >
                          > When a password gets compromised, spam starts to pour out of the
                          > server from endless numbers of IP's, to endless numbers of addresses.
                          >
                          > Rate limiting is interesting but doesn't really stop the spam.
                          >
                          > Counting client=[IP] addresses until a threshold is reached
                          > is highly effective, but then what? Change their password?
                          >
                          > Thanks in advance.
                          >
                          > Homer
                          >
                          > ------------------------------------------------------------------------
                          > Homer Wilson Smith Clean Air, Clear Water, Art Matrix - Lightlink
                          > (607) 277-0959 A Green Earth, and Peace, Internet, Ithaca NY
                          > homer@... Is that too much to ask? http://www.lightlink.com
                          >
                        • DTNX Postmaster
                          ... Perhaps another interesting datapoint; We have basic rate limiting, per hour. High enough so it doesn t impede anyone doing normal work, but low enough to
                          Message 12 of 15 , Mar 6, 2014
                            On 06 Mar 2014, at 18:04, Adam Moffett <adamlists@...> wrote:

                            > Two steps eliminated this problem for us:
                            >
                            > 1) Accounts with more than 6 failed login attempts in a 10 minute period are disabled for 10 minutes. This makes brute force methods to find passwords almost impossible.
                            >
                            > 2) Limit to 200 outgoing messages per day per user. We'll raise it to any reasonable value for an individual account. I.E.: We'll let you send 1000 per day so you can get your church newsletter out, but we won't remove the limit completely and let you spam (knowingly or not). This minimizes the damage if a password is still compromised.
                            >
                            > 200 is a pretty high limit. Very few people send more than 50 in a day, and almost nobody sends more than 100. We set it at 200 so we wouldn't have to hear from anybody who isn't bulk mailing.

                            Perhaps another interesting datapoint;

                            We have basic rate limiting, per hour. High enough so it doesn't impede
                            anyone doing normal work, but low enough to catch anyone doing bulk
                            mailing, and slow them down with a DEFER. This allows their mailing to
                            finish, it'll just take a long time.

                            What we found in terms of most compromises, however, is that they
                            stayed well below our rate limits. Send only a few messages here and
                            there, stay below the radar. The last one, a week or two ago, only
                            probed once or twice a day, and then sent a single message. Which
                            bounced back, user notified us, and so on.

                            Also, not seen any brute-force attempts recently; in the cases we know
                            of it's been user neglicence, such as reuse of simple passwords.

                            Oh, and making services available only over SSL/TLS seems to make a
                            difference, too. Nothing listening on 110/143, 587 with STARTTLS only.

                            Mvg,
                            Joni
                          • lists@rhsoft.net
                            ... that is fine ... i know users hitting the 200 per day regulary frankly they exceed 50 smtp connections per 30 minutes, manually written mails :-)
                            Message 13 of 15 , Mar 6, 2014
                              Am 06.03.2014 18:04, schrieb Adam Moffett:
                              > Two steps eliminated this problem for us:
                              >
                              > 1) Accounts with more than 6 failed login attempts in a 10 minute period are disabled for 10 minutes. This makes
                              > brute force methods to find passwords almost impossible.

                              that is fine

                              > 2) Limit to 200 outgoing messages per day per user. We'll raise it to any reasonable value for an individual
                              > account. I.E.: We'll let you send 1000 per day so you can get your church newsletter out, but we won't remove the
                              > limit completely and let you spam (knowingly or not). This minimizes the damage if a password is still compromised.
                              >
                              > 200 is a pretty high limit. Very few people send more than 50 in a day, and almost nobody sends more than 100. We
                              > set it at 200 so we wouldn't have to hear from anybody who isn't bulk mailing

                              i know users hitting the 200 per day regulary
                              frankly they exceed 50 smtp connections per 30 minutes, manually written mails :-)
                            • Rob Tanner
                              On Mar 4, 2014, at 7:25 PM, Venkat wrote: When a password gets compromised, spam starts to pour out of the
                              Message 14 of 15 , Apr 4 3:50 PM
                                On Mar 4, 2014, at 7:25 PM, Venkat <mvenkatsub@...> wrote:



                                   When a password gets compromised, spam starts to pour out of the
                                server from endless numbers of IP's, to endless numbers of addresses.

                                   Rate limiting is interesting but doesn't really stop the spam.

                                   Counting client=[IP] addresses until a threshold is reached
                                is highly effective, but then what?  Change their password?


                                We are using policyd to manage quotas on e-mail send outs. You can also
                                use a log monitor like swatch to alert you if an account exceeds quota. At this
                                point the account can be disabled till the user changes their password. Also,
                                policyd supports things like rejecting or holding e-mails if the quota is exceeded so
                                spam does not go out anymore. You can also script automatic disabling of accounts
                                based on quota violations. We find that blacklisting usually only happens when a very
                                large number of spam escapes, so rate limiting per account (e-mail address) is quite
                                effective.

                                I’ve got the same problem and I’ve installed policyd on a test server.  Using the GUI the setup is simple enough, but I’ve yet to get it to work.  Not bing sure whether I need to setup restrictions under Quotas or Accounting I’ve tried both and after I’ve sent a bunch of test messages, the one thing I notice is that nothing is being written to the either the accounting_tracking or the quotas_tracking tables.  The policyd log file shows that every message (including those beyond the 5 limit I setup for testing) was processed and the modules both returned a CBP_SKIP which I gather means nothing to do.  Did you have that same problem and if so, how did you get around it.  

                                ~ Rob


                              • Venkat
                                Hello, This is how I configured policyd: For the actual policies, we use the Web GUI to define them. Basically: 1. Create a new policy under Policies --
                                Message 15 of 15 , Apr 4 8:59 PM
                                  Hello,

                                  This is how I configured policyd:

                                  For the actual policies, we use the Web GUI to define them. Basically:

                                  1. Create a new policy under "Policies --> Main" and assign it a priority.
                                  Policies are processed in order and all of them apply.

                                  2. Create a new group under "Policies --> Groups". The name can be
                                  anything e.g. "mygroup".

                                  3. Add members to the Group using the "Action" drop down menu. We use
                                  members defined by domain: e.g. @domain is a group member but you can also
                                  use individual email@domain I think. Add all e-mail domains/addresses you
                                  need.

                                  4. Go back to the policy you created, and set the Members as follows:
                                  Source: %mygroup
                                  Destination: any

                                  If you have any users/domains you don't want included,
                                  create another group e.g. "exclude_group" and set the policy as follows:
                                  Source: !%exclude_group, %mygroup

                                  5. Create a new quota under "Quotas --> Configure".

                                  6. Associate this quota to the policy you created earlier. You can set
                                  various actions if quota is exceeded (e.g. REJECT, HOLD). If you don't want any action,
                                  you'll need to update the quota manually in the Cluebringer sqlite database and set
                                  Action to blank i.e. ' '.

                                  7. You can use Swatch(http://sourceforge.net/projects/swatch/) to monitor
                                  your postfix log file for quota violations.
                                  Here is our swatch config. file:

                                  watchfor /(Sender:.*)quota=.* \(\d\d\d\..*%\)/i
                                           exec "/usr/local/scripts/swatch_warn.pl $1"
                                           threshold track_by=$1, type=limit, count=1, seconds=1800

                                  This will detect if an account has gone over 100% quota and run a perl
                                  script to email us of the violation. The $1 is the e-mail address which
                                  has violated quota.

                                  Hope this helps!

                                  cheers,

                                  VM


                                  On Fri, Apr 4, 2014 at 3:50 PM, Rob Tanner <rtanner@...> wrote:
                                  On Mar 4, 2014, at 7:25 PM, Venkat <mvenkatsub@...> wrote:



                                     When a password gets compromised, spam starts to pour out of the
                                  server from endless numbers of IP's, to endless numbers of addresses.

                                     Rate limiting is interesting but doesn't really stop the spam.

                                     Counting client=[IP] addresses until a threshold is reached
                                  is highly effective, but then what?  Change their password?


                                  We are using policyd to manage quotas on e-mail send outs. You can also
                                  use a log monitor like swatch to alert you if an account exceeds quota. At this
                                  point the account can be disabled till the user changes their password. Also,
                                  policyd supports things like rejecting or holding e-mails if the quota is exceeded so
                                  spam does not go out anymore. You can also script automatic disabling of accounts
                                  based on quota violations. We find that blacklisting usually only happens when a very
                                  large number of spam escapes, so rate limiting per account (e-mail address) is quite
                                  effective.

                                  I’ve got the same problem and I’ve installed policyd on a test server.  Using the GUI the setup is simple enough, but I’ve yet to get it to work.  Not bing sure whether I need to setup restrictions under Quotas or Accounting I’ve tried both and after I’ve sent a bunch of test messages, the one thing I notice is that nothing is being written to the either the accounting_tracking or the quotas_tracking tables.  The policyd log file shows that every message (including those beyond the 5 limit I setup for testing) was processed and the modules both returned a CBP_SKIP which I gather means nothing to do.  Did you have that same problem and if so, how did you get around it.  

                                  ~ Rob



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