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.)
[
multipart_signed_part 1K ] This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B09560CB91BF793C57ED63F Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
# To use this data with Postfix use the following # configuration in your main.cf: # # smtpd_recipient_restrictions =3D ... # check_sender_access cidr:/etc/postfix/postfix-dnswl
Matthias,
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.
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.
> 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
> > 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.
On Tue, Nov 14, 2006 at 06:32:03PM +0100, Matthias Leisi wrote: > > 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.
> 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.)
>> 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 :)
|
