Thanks. Your setup is very different than what I'm trying to achieve
though.
Lets take a simple case and say I have users [email protected] and
[email protected]. There are others, say [email protected], but they don't have
any personal preferences entered, so they'll get the defaults for
@xyz.com.
[email protected] has:
whitelist: [email protected], [email protected]
blacklist: [email protected], [email protected]
and [email protected] has:
whitelist: [email protected], [email protected]
blacklist: [email protected]
and there's a default for the domain @xyz.com:
whitelist: @partner.com, @info.net
blacklist: @spammer.com, @killer.com, @def.com
so if a mail comes in from [email protected], it would be passed through to
[email protected], but blocked if sent to [email protected] or [email protected] (since
its in the domain default blacklist).
if a mail comes in from [email protected], it would be passed through
if the recipient was [email protected], but rejected if to [email protected], and
it would be greylisted and eventually passed through to [email protected]
(since its not on the domain white/black lists).
So how would you set up the policy's and groups in the above situation?
Its clear how to do this in V1, which is what I already have and works
fine. Its not clear to me how to do this in V2.
Tobias J Kreidl wrote:
In a nutshell, here's what we have so far:
Name Priority Description Disabled
Default 0 Default System Policy yes
Trusted IPs 0 Trusted/Whitelisted Servers Policy no
Trusted Senders 0 Sender Policy for trusted addresses no
Default Outbound 10 Default Outbound System Policy yes
Default Inbound 10 Default Inbound System Policy yes
Senders 10 NAU Sender Policy no
Default Internal 20 Default Internal System Policy yes
Test 50 Test policy yes
Internal IPs 50 Non-Trusted/Whitelisted Policy no
Non-Internal IPs 100 All Non-Internal IPs no
Non-Internal Senders 100 All non-Internal senders no
We hashoudl have no external senders in this case, so they are all
getting blocked (anti-relay).
For policy groups, we have:
Internal_IPs no
Internal_Senders no
Internal_Trusted_IPs no
Internal_Trusted_Senders no
internal_domains yes
internal_ips yes
The Internal_IPs contains our main nets and subnets, senders is
@your.domain whatever it may be, trusted_IPs is a long list of
"whitelisted" IP addresses of machines allwoed to send without being
checked, trusted_senders are individulas like [email protected] who are
allowed to override. Internal_domains and Internal_pis are currently
not used by us.
For access control, HELO/EHLO checks, SPF checks, and greylisting we
have just the defaults (and are not using any of these other than
blacklisting the local host and local host IP settings (whioch is the
default, I believe).
If you're interested in the quotas part, I can get you further
information, if desired. The quotas part piggy-backs onto th eother
defined policies; we currently have those defined for our internal
addresses and senders, as this would pertain to our internal mail
routing. FOr external ones, we'll have a different list in which we
will allow for exceptions for certain trusted outside mail senders.
All this is set up via the Web GUI. Really, you can do anything pretty
much from V1 in V2, with th eexceptions mentioned before about getting
stats on how many access attempts there really were and an easy way to
get reports out of the DB.
Hope this helps,
--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
|
