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
