Inverse access restrictions?
Lloyd Zusman
I know how to use smtpd_restriction_classes to cause a policy service
to only be run for a small group of recipients. However, I'm trying
to perform the inverse operation, but I can't figure out how to do it.
Specifically, I want to run a greylisting policy service for most email
that arrives at my server. However, for a specific recipient, I want to
bypass the greylisting service completely.
In the following example, assume that I want us...@mydomain.tld to not
have any mail sent to him to be greylisted, but everyone else (dozens of
users) should indeed have their incoming emails processed through the
greylisting service. I'm stuck at what to put into the "greylist-control"
file:
in main.cf
==========
smtpd_restriction_classes = greylist_policy
greylist_policy = check_policy_service unix:private/mygreylister
smtpd_recipient_restrictions =
...
check_recipient_access hash:/etc/postfix/greylist-control
in greylist-control
===================
us...@mydomain.tld ???WHAT-TO-DO???
???EVERYONE-ELSE??? greylist_policy
I'm thinking that I must be missing something obvious here.
Thanks in advance for any pointers to docs that you might be able to
suggest.
--
Lloyd Zusman
hipp...@potamuses.net
God bless you.
Benny Pedersen
On Wed, April 11, 2007 01:59, Lloyd Zusman wrote:
> I'm thinking that I must be missing something obvious here.
what greylist server ?
if its postgrey then setup recipient pcre list to exclude some users, for
instance postmaster@ and abuse@ is default not greylisted in postgrey, silly
since postfix imho not sending postmaster@ to policy any more, but from that
example in postgrey you might have succes to extend it :-)
if its policyd then make policy table to exclude users not to greylist, dont
whitelist !
3 option is the python i use :-)
> Thanks in advance for any pointers to docs that you might be able to
> suggest.
i use a python policy deamond that solves this problem very nice :-)
--
This message was sent using 100% recycled spam mails.
KaiFürstenberg
smtpd_recipient_restrictions = regexp:/etc/postfix/greylist-control
greylist-control:
/user@domain\.tld/ ???WHAT-TO-DO???
/^.*/ greylist_policy
Kai
Lloyd Zusman
>
> Lloyd Zusman schrieb am 11.04.2007 01:59:
> >
> > in main.cf
> > ==========
> > smtpd_restriction_classes = greylist_policy
> > greylist_policy = check_policy_service unix:private/mygreylister
> > smtpd_recipient_restrictions =
> > ...
> > check_recipient_access hash:/etc/postfix/greylist-control
> >
> > in greylist-control
> > ===================
> > user <at> mydomain.tld ???WHAT-TO-DO???
> > ???EVERYONE-ELSE??? greylist_policy
> >
> > [ ... ]
> >
> Use regexp instead of hash:
> smtpd_recipient_restrictions = regexp:/etc/postfix/greylist-control
>
> greylist-control:
> /user <at> domain\.tld/ ???WHAT-TO-DO???
> /^.*/ greylist_policy
Aha! This is the exact solution I'm looking for. I presume that pcre
will work as well as regexp.
I also appreciate the other suggestions, although like this one the best,
because the "check_recipient_access hash:/etc/postfix/greylist-control"
restriction doesn't have to be the last one. If I map "us...@domain.tld"
to "OK", as was mentioned in another suggestion, then I can't put any
further checks after that which might look at that same message.
I know that my greylist server itself can have whitelisted entries (I'm
using "gps"), but I'm just using greylisting as an example here, as I
also want to make use of these kinds of inverse restrictions for other
cases which may not allow this as part of the restriction implementation,
itself.
Anyway, thanks to you and to all of you for your help.
Wietse Venema
[ Charset UTF-8 unsupported, converting... ]
You can map it to "DUNNO". This terminates the table search, but
allows you to list further checks in smtpd_recipient_restrictions.
Wietse
Lloyd Zusman
>
> Kai Fürstenberg <kai_lists_postfix <at> fuerstenberg.ws> writes:
>
> > [ ... ]
> >
> > Use regexp instead of hash:
> > smtpd_recipient_restrictions = regexp:/etc/postfix/greylist-control
> >
> > greylist-control:
> > /user <at> domain\.tld/ ???WHAT-TO-DO???
> > /^.*/ greylist_policy
>
> Aha! This is the exact solution I'm looking for. I presume that pcre
> will work as well as regexp.
... and to follow up on my own post, I just now realized that if I use
pcre, I can also do this:
greylist-control:
!/user@domain\.tld/ greylist_policy
That gives me inverse access restrictions "right out of the box".
Noel Jones
>Kai Fürstenberg <kai_lists_postfix <at> fuerstenberg.ws> writes:
>
> >
> > >
> > > ==========
> > > smtpd_restriction_classes = greylist_policy
> > > greylist_policy = check_policy_service unix:private/mygreylister
> > > smtpd_recipient_restrictions =
> > > ...
> > > check_recipient_access hash:/etc/postfix/greylist-control
> > >
> > > in greylist-control
> > > ===================
> > > ???EVERYONE-ELSE??? greylist_policy
> > >
> > >
> > Use regexp instead of hash:
> > smtpd_recipient_restrictions = regexp:/etc/postfix/greylist-control
> >
> > greylist-control:
> > /user <at> domain\.tld/ ???WHAT-TO-DO???
> > /^.*/ greylist_policy
>
>Aha! This is the exact solution I'm looking for. I presume that pcre
>will work as well as regexp.
>
>because the "check_recipient_access hash:/etc/postfix/greylist-control"
>restriction doesn't have to be the last one. If I map "us...@domain.tld"
>to "OK", as was mentioned in another suggestion, then I can't put any
>further checks after that which might look at that same message.
Use DUNNO rather than OK to skip that restriction only.
--
Noel Jones
Lloyd Zusman
> smtpd_restriction_classes =
> greylist_policy
>
> smtpd_recipient_restrictions =
> [...]
> greylist_policy
> [...]
>
> greylist_policy =
> check_recipient_access hash:/etc/postfix/greylist_bypass_rcpts
> check_policy_service unix:private/mygreylister
Yes, this is even closer to what I was looking for. I agree with the
kluginess of the /./ regexp. And I presume that I would put something
like this in greylist_bypass_rcpts:
us...@mydomain.tld dunno
Thank you very much.
Noel Jones
>Martin Schmitt <mas <at> scsy.de> writes:
>
> > smtpd_restriction_classes =
> > greylist_policy
> >
> > smtpd_recipient_restrictions =
> > [...]
> > greylist_policy
> > [...]
> >
> > greylist_policy =
> > check_recipient_access hash:/etc/postfix/greylist_bypass_rcpts
> > check_policy_service unix:private/mygreylister
>
>Yes, this is even closer to what I was looking for. I agree with the
>kluginess of the /./ regexp. And I presume that I would put something
>like this in greylist_bypass_rcpts:
>
>us...@mydomain.tld dunno
Nope, dunno won't work like that. Dunno causes postfix to skip that
single restriction, not the class. Using smtpd_restriction_classes
doesn't buy you anything this time.
Use dunno with a regexp/pcre table or use OK and put greylisting in a
different smtpd_*_restrictions section.
In this example, recipients you don't want to greylist would be
listed as OK in no_greylist_recipients
smtpd_sender_restrictions =
permit_mynetworks
permit_sasl_authenticated
check_recipient_access hash:/etc/no_greylist_recipients
check_policy_service unix:whatever...
smtpd_recipient_restrictions =
(other usual restrictions go here)
--
Noel Jones
Noel Jones
>Lloyd Zusman schrieb:
>
> > Yes, this is even closer to what I was looking for. I agree with the
> > kluginess of the /./ regexp. And I presume that I would put something
> > like this in greylist_bypass_rcpts:
> >
> > us...@mydomain.tld dunno
>
>class and to proceed with the rest of smtpd_recipient_restrictions.
No, OK breaks out of the whole smtpd_*_restrictions section you are
in, not just the restriction class.
--
Noel Jones
mouss
> Martin Schmitt <mas <at> scsy.de> writes:
>
>
>> smtpd_restriction_classes =
>> greylist_policy
>>
>> smtpd_recipient_restrictions =
>> [...]
>> greylist_policy
>> [...]
>>
>> greylist_policy =
>> check_recipient_access hash:/etc/postfix/greylist_bypass_rcpts
>> check_policy_service unix:private/mygreylister
>>
>
> Yes, this is even closer to what I was looking for. I agree with the
> kluginess of the /./ regexp. And I presume that I would put something
> like this in greylist_bypass_rcpts:
>
> us...@mydomain.tld dunno
>
no. here you need "OK" to avoid running subsequent checks. This only
works for "late" checks as in the example above. if you want to skip
some checks but not others, and you can't reorder the checks, you'll
need restriction classes and use a restriction class instead of "OK".
Lloyd Zusman
>
> Lloyd Zusman wrote:
> >
> > [ ... ]
> >
> > user <at> mydomain.tld dunno
> >
>
> no. here you need "OK" to avoid running subsequent checks. This only
> works for "late" checks as in the example above. if you want to skip
> some checks but not others, and you can't reorder the checks, you'll
> need restriction classes and use a restriction class instead of "OK".
So would my restriction class perform the "late" checks in that case?
Hmm ... the regexp/pcre solution is starting to look more desirable again,
because in the general case, I do indeed want to perform more checks after
this greylisting check.
mouss
> mouss <mlist.only <at> free.fr> writes:
>
>
>> Lloyd Zusman wrote:
>>
>>> [ ... ]
>>>
>>> user <at> mydomain.tld dunno
>>>
>>>
>> no. here you need "OK" to avoid running subsequent checks. This only
>> works for "late" checks as in the example above. if you want to skip
>> some checks but not others, and you can't reorder the checks, you'll
>> need restriction classes and use a restriction class instead of "OK".
>>
>
> So would my restriction class perform the "late" checks in that case?
>
you need to duplicate the checks in that class. here is a "simplistic"
example:
smtpd_restriction_classes = ... skipped_recipient_checks ...
smtpd_recipient_restrictions =
...
check_recipient_access hash:$dir/skip_checks_1_to_3
do_check_1
do_check_2
do_check_3
do_check_4
do_check_5
skipped_recipients_checks =
do_check_4
do_check_5
permit
$dir/skip_checks_1_to3:
f...@example.com skipped_recipients_checks
The problem here is the duplication. This woudl only be "acceptable" if
you strutcture your restrictions accordingly. something like
smtpd_restriction_classes = policy_weak policy_low policy_medium
policy_high policy_string policy_extreme ...
default_policy = static:policy_medium
smtpd_recipient_restrictions
...
check_recipient_restrictions hash:$dir/per_recipient_policy
check_recipient_access $default_policy
policy_weak =
...
policy_medium =
check_recipient_access static:$policy_weak
...
etc.
> Hmm ... the regexp/pcre solution is starting to look more desirable again,
> because in the general case, I do indeed want to perform more checks after
> this greylisting check.
>
if you can organize your restrictions on a per recipient basis, you can
use the approach mentioned above. if you organize your restrictions per
check, then use the pcre approach.
Lloyd Zusman
>
> [ ... clear and useful explanations snipped ... ]
>
> if you can organize your restrictions on a per recipient basis, you can
> use the approach mentioned above. if you organize your restrictions per
> check, then use the pcre approach.
Yep, all that makes sense. Thank you for the explanations and clarification.