Thanks, yes I read the documentation several times. Thats why I
thought a tutorial would help as the documentation describes all the
pieces, but doesn't put together the puzzle. I think I'm getting this
together now, let me run this by you.
Assume that you accept/process mail for a set of customers, each
customer has one or more domains and one or more users. Each user has
one or more email addresses at the domains owned by the customer.
The default scenario is to greylist everything, i.e. opt-in. Each
customer can have a whitelist and a blacklist which would be the
default for all their domains. They can provide whitelists and
blacklists on a per domain basis which will override the settings at
the customer level. A subset of the email addresses within a domain
can have its own whitelist and blacklist which will override the
settings at the domain and customer level.
I believe the following needs to be done:
1. create a group per user, members are their email addresses
2. create a group per customer, members are the users
3. create an opt-in and an opt-out policy per customer, with the
customers/users based on their opt-in/opt-out choices
4. create a greylisting entry for opt-in and opt-out linked to the
policies above.
I'm not sure where to put the domain defaults (i.e. catch-all for
domains) Say I want the default for a domain is opt-in, but some
addresses within the domain want to opt-out.
As for pure whitelist/blacklist, I believe I need to create a group of
addresses/domains per user (one for user_whitelist and one for
user_blacklist) and add a policy for each specifying the users group of
email addresses as the destination with the user_whitelist group as the
source (or user_blacklist group as the source in the case of a
blacklist). And this should just go under Access Control.
Does this sound about right? If not, please correct me...
Tobias J Kreidl wrote:
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
|
