It certain seems like all these wishes of yours are possible: check out
the documentation at http://policyd.org/tiki-index.php?page=documentation
Above all, one can decide what policies get nested together or if
something matches, to stop right there (see the "Accounting
Configuration" section).There is certainly more flexibility than in
V1 and we're seeing good performance with the limited scope we've had so
far with V2 vs V1.
You can start with a whitelist and a couple of basic policies that can
either filter or limit messages by origin, destination, or
quantity/size. We've been using policyd 1.82 for quite some time now
and have been very happy with it's performance. We get probably a good
million pieces of email a day and run a group of machines that deal
separately with internal and external email routing (and have two
customized versions of policyd, taylored to each specific case). Our
intention with "cluebringer" is to enhance what we already have by
imposing limits on what users can send in addition to machine-based
limits, but we're just at the point where we first want to make sure
things are running as they were under 1.82. Once in production for a
while, we'll experiment with out one non-production server and run tests
on sender limiting. Currently, we're more interested in what we receive
because of unsolicited spam more than anything else, but there are also
cases here we want to restrict how much is sent, as well.
While a tutorial with more detail would be great, it's possible to
figure out much of this by starting with simple cases and examining the
logs as you go. Some of the postfix tools for generating lots of email
are useful for testing, like smtp-source. Someone mentioned putting
togeter a tutorial a while back; I wish we could say more at this point,
but we're still figuring out the basic details in V2 ourselves. Above
all, I'm really interested in tracking who all is way over on a regular
basis (such as hourly) s we can (1) consider blocking te sender
altogether if it's an obvious DoS, and (2) if someone internally starts
sending huge numbers of messages, it could indicate a compromised
account or someone just doing something irresponsible. That's why we'd
really like to be able to get some numbers out of the DB. With policyd
1.82 now, we generate an hourly list that gets mailed out showing all
instances where the limits have been exceeded. I really would like to
see something like that possible in V2.
--Tobias
Brian Kolaci wrote:
The initial configuration is standard/stock.
Based on user preferences, they can opt-in or opt-out individual email
addresses. Domain administrators can opt-in or opt-out whole
domains. The user preference overrides the domain setting, i.e. the
domains could be set to opt-in, and specific email addresses can opt-out.
We also use the blacklist/whitelist a the global, domain and user levels.
So I'd like to know if the new version is capable of that, and if so,
how to configure that.
I guess my questions are similar to yours. We have a sense of global,
client, domain and email address levels that need to be handled
separately. The preference needs to tend toward the more granular
control.
We don't use quotas, so I haven't used that feature. I am interested,
however as I'd like to offer another service that would have quota
limits attached.
Tobias J Kreidl wrote:
I would say it depends a lot on your initial configuration.
We're in the process of finishing up some tests that initially just
duplicate what we have now under 1.X. We have a special, isolated
mailgateway machine that we're using for testing, which helps a lot.
There is no greylisting used in our case and the blacklisting is handled
independently, so that keeps it simpler. We are tied in to amavisd-new,
however.
We entered in all our whitelist parameters, created trusted and
untrusted groups and set up limits. Other than the procedure on how to
do the initial install and configuration, the rest was pretty
straight-forward. The next step wil be to implement user limits.
Two issues have arisen on which I'd like to throw back questions.
First, since all policies are combined, there does not appear to be a
way that a single user on a specific machine can be given a higher limit
if the machine itself already has a lower limit, or will the
individual's setting override the global one?
Second, in policyd 1.X, I wrote a reporting tool that generates messages
telling when quotas have been exceeded, something like this:
# To check for _all_ the limits, one should really use this:
$sql = qq{SELECT * FROM throttle where _count_cur >= _count_max
or _rcpt_cur >= _rcpt_max or _quota_cur >= _quota_max
or _abuse_cur=1};
but in policyd2, there appears to be no tracking of how many attempts
were made for a particular sender, recipient or machine; the DB
apparently only compares the allowed value to the matching group
policy. This makes it very hard to come up with a simple way to query
what instances are over quota and makes it impossible to tell by how
much -- did the user try to send 5 messages over the limit or 500000 ?
I'm asking if anyone has written a reporting tool that can extract at
least what instances are over quota at a given moment. If nothing like
this exists, I'd like to ask the authors to at least consider storing
this information in the table so that an easy comparison can be made
to see if the user or machine is over the limit. When the time
limit has expired, the counter could be zeroed out.
Thoughts on this? Thanks for reading.
Regards,
--Tobias
Brian Kolaci wrote:
Hi,
Are there any tips to migrating from 1.8 to 2.x ?
I currently have scripts that populate the "whitelist_sender" table and
manipulate the policy table to allow domains or specific email users to
opt-in and opt-out of greylisting. So some users should be able to
bypass the policyd greylisting inbound mail to their addresses if they
choose, and there is a list of email addresses that I'd like to just
plain whitelist.
Can this be done using version 2.x? If so, how can I replicate that
functionality?
Thanks,
Brian
_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users
