From: Craig Sanders (no email)
Date: Wed Oct 02 2002 - 22:27:09 EDT
NOTE: i'm far from an expert on the postfix source code (my C skills are
little better than read-only and i haven't examined the source in any
depth) so there may be some reason why it is impossible for
content-filters to work as i describe below.
On Wed, Oct 02, 2002 at 09:52:26PM +0400, Michael Tokarev wrote:
> >"OK" is for whitelist entries that the CF approves of. e.g. for a
> >spam-lovers map for recipients who want to eat all their spam.
> >
> >"DUNNO" is if the filter has no reason to reject the message...other
> >rules within postfix may cause a later rejection.
> >
> >"REJECT"'s meaning is obvious.
> >
> >"FILTER" is "I'LL TAKE IT FROM HERE" aka "DISCARD". the filter is going
> >to transform the message and reinject it back to postfix.
> >
> >optionally, there could be a "DISCARD" code...but that would only be
> >useful for postfix's logging as any filter could easily just discard a
> >message rather than re-inject it.
>
> It seems you're looking at this from some strange point of view,
> or I just don't understand you. Please at least avoid using the
> same keywords (OK, DUNNO, REJECT etc) as used in smtpd maps - this
> increases confusion (and indeed there IS some comfusion at either
> my or your side).
dunno if it's strange or not, but it makes sense to me (you can take
that as an admission of strangeness if you like :).
i think we're looking at the problem quite differently, you're working
(largely) within the current model of how content-filters work and i'm
not. yours is a more immediately practical approach, whereas mine is a
"what if".
i personally think that the current model is wrong, and that the
solution is to simplify it. at the moment, content filters are a weird
special case. i think that content-filtering (and especially
content-inspection) should be part of smtpd_*_restrictions.
similarly, RBL checks have been a weird special case up until the latest
snapshot. now they're being "integrated" into postfix as just another
smtpd_*_restriction. IMO, this is the Right Thing to do because it
simplifies them and makes them far more versatile.
body/header checks are also a weird special case. i'd suggest that they
also be integrated in the same way but i believe that a good content
filter/inspector model would make them obsolete. in fact, they could be
implemented (in perl or python or C or whatever) as the default/sample
content-inspector.
if content-filters worked like this, then using the same codes (OK,
DUNNO, REJECT, etc) works because they have the same meaning in the same
context.
the only (IMO, minor) problem with making it an smtpd_*_restriction is
that they only apply to mail received via smtpd. i don't think that's
such a huge problem - at worst, /usr/sbin/sendmail can be replaced with
a wrapper which injects mail into the postfix queue via smtp.
> Look at the current content_filter logic. Note we're NOT talking
> about header/body checks (maybe this is the source of confusion?):
not a source of confusion, i just see content-filters/content-inspectors
as (potentially) a superior replacement for body/header checks.
there are serious limitations on what current body/header checks can do
(e.g. there's no boolean logic such as "reject if /this/ and /that/" or
"reject if /this/ but not /that/"; and no "scoring" ala spamassassin).
to add these features into postfix itself would complicate and bloat
postfix. more to the point, it's a job that's better done externally to
postfix as different people want to do different things - spam blocking
and/or tagging, virus filtering, automatic content encoding (e.g. from
8-bit to quoted-printable), etc etc.
IMO, what postfix should provide is just the interface or framework for
people to create their own modular content-filters/inspectors....or
download one from a postfix contrib site. nothing more.
i hope i've explained my thoughts well enough.
craig
-- craig sanders <> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch - To unsubscribe, send mail to with content (not subject): unsubscribe postfix-users
|
|
|