Suggestions on how to implement whitelist w/postfix
Matthias Leisi
Hash: SHA1
I started a project for a collaborative whitelist (see [1]) and would
like to ask for suggestions on how whitelists can / should / may be
implemented in Postfix.
I'm aware of the problems inherent with DNS-based whitelists (especially
unavailability); therefor one format I currently export is a Postfix
cidr_table (see [2]). Unfortunately, that approach does not profit from
the "fine grained" data, eg different "trust scores" and categories.
How could this be done more flexibly? I could imagine that entries with
a "hi" or "med" score would eg bypass a spamfilter completely - but how
would this most elegantly be implemented?
Any suggestions? (The export format can be changed to whatever seems
helpful.)
Thanks,
- -- Matthias
[1] http://www.dnswl.org/
[2] http://www.dnswl.org/data/postfix-dnswl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFFWe5xxbHw2nyi/okRAgUBAJ9UzH5bfLj8hE7/8eTtXmRl1SVaIQCdHUcZ
sS8AI2ecZG4cQ03p62GY2iA=
=9XT4
-----END PGP SIGNATURE-----
Matthias Leisi
Hash: SHA1
Hi Martin,
Martin Schmitt wrote:
>> [2] http://www.dnswl.org/data/postfix-dnswl
>
> what you really seem to mean here is "check_client_access". It should
> also be noted that either the RHS of the CIDR table must be
> "reject_unauth_destination" instead of "OK" or that
> "reject_unauth_destination" must be listed before this check. Otherwise,
> Postfix will become an open relay for the whitelisted clients. I assume
> that this is not what you're trying to accomplish.
You assume correctly. Updated and thanks.
> Also, Postfix has no method at all for working with the scores. If you
> really want to pursue this whitelist method, integrating it into
> something like policyd-weight or Spamassassin might be a somewhat more
> promising approach.
True, that's why I listed Spamassassin-specific information in [1].
However I believe that piping messages through some policy/spam filter
of which you *know* that you don't want them scored is somewhat
redundant, a waste of CPU cycles and a certain danger (eg if the
policy/scoring decisions goes mad).
So, what I basically would like to do is:
In postfix-dnswl? ------> yes ------> deliver
|
no
|
+------> policyd/amavis/... ------> deliver
Any idea?
- -- Matthias
[1] http://www.dnswl.org/tech.shtml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFFWf2TxbHw2nyi/okRAqZDAJ9wAwvsdBgv9VhVnZs0qUYGAwwCuQCgrJxI
ObUhzkYgUN+mr/sRpZrrtrM=
=eKbQ
-----END PGP SIGNATURE-----
Noel Jones
> > Also, Postfix has no method at all for working with the
> scores. If you
> > really want to pursue this whitelist method,
> integrating it into
> > something like policyd-weight or Spamassassin might be
> a somewhat more
> > promising approach.
>
>True, that's why I listed Spamassassin-specific
>information in [1].
>However I believe that piping messages through some
>policy/spam filter
>of which you *know* that you don't want them scored is somewhat
>redundant, a waste of CPU cycles and a certain danger (eg
>if the
>policy/scoring decisions goes mad).
>
>So, what I basically would like to do is:
>
> In postfix-dnswl? ------> yes ------> deliver
> |
> no
> |
> +------> policyd/amavis/... ------> deliver
>
>Any idea?
The usual safe way to whitelist a client is to arrange for
your lookup to return a result of "permit_auth_destination".
This will bypass further checks on the client only if the
mail is destined for a domain for which you are responsible
without the danger of creating an open relay.
--
Noel Jones
Robert Felber
> > really want to pursue this whitelist method, integrating it into
> > something like policyd-weight or Spamassassin might be a somewhat more
> > promising approach.
>
> True, that's why I listed Spamassassin-specific information in [1].
> However I believe that piping messages through some policy/spam filter
> of which you *know* that you don't want them scored is somewhat
> redundant, a waste of CPU cycles and a certain danger (eg if the
> policy/scoring decisions goes mad).
For policy servers you don't need to pipe messages. You just pipe
the initial SMTP commants HELO, MAIL FROM, RCPT TO.
For the sake of avoiding scoring clients again policyd-weight has a
fluctuating cache. I.e. Entries are purged if the were looked up too often,
or lived too long in the cache.
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
mouss
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I started a project for a collaborative whitelist (see [1]) and would
> like to ask for suggestions on how whitelists can / should / may be
> implemented in Postfix.
>
> I'm aware of the problems inherent with DNS-based whitelists (especially
> unavailability); therefor one format I currently export is a Postfix
> cidr_table (see [2]). Unfortunately, that approach does not profit from
> the "fine grained" data, eg different "trust scores" and categories.
>
> How could this be done more flexibly? I could imagine that entries with
> a "hi" or "med" score would eg bypass a spamfilter completely - but how
> would this most elegantly be implemented?
>
> Any suggestions? (The export format can be changed to whatever seems
> helpful.)
>
Example:
smtpd_restriction_classes =
policy_good
policy_bad
policy_ugly
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
check_client_access cidr:$dir/client_acl
policy_good =
FILTER dummy:
policy_bad =
reject
policy_ugly =
check_service ...
client_acl:
192.0.2.0/24 policy_good
10.1.20.0/16 policy_ugly
...
setup as many classes as you want, with whatever checks you want in each.
You may use mysql or postgres instead if that makes the table update easier.
Matthias Leisi
Hash: SHA1
>> [How to use dnswl.org data in Postfix]
>>
>> Any suggestions? (The export format can be changed to whatever seems
>> helpful.)
>
> Example:
>
> smtpd_restriction_classes =
Thank you all for your help. I have adapted the descriptions and export
formats to allow two different features (which can also be combined):
* PREPEND a header for later filtering
* permit_auth_destination to override blacklistings
The description at [1] also points to a script which (amongst retrieving
etc) allows to replace 'permit_auth_destination' by eg 'FILTER
local:$myhostname' for bypassing a spamfilter.
The PREPEND list contains '0.0.0.0/0 PREPEND'entry at the very bottom to
ensure a default of 'Not whitelisted' for non-listed IP ranges.
If you want to give the dnswl.org data a try yourself - please by my
guest :)
- -- Matthias
[1] http://www.dnswl.org/tech.shtml
PS: With the Mnenhy extension, Thunderbird now also shows me a nice
headerline indicating whether a mail had been whitelisted or not. Kind
of cool :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFFWlwsxbHw2nyi/okRAotZAJ9KANgxQiGYNVXOvZZOyYaHK/c4AgCgqVtk
7BluR9835GGtXbLfvtDQnbk=
=OPU4
-----END PGP SIGNATURE-----