From: Craig Sanders (no email)
Date: Tue Oct 01 2002 - 22:09:31 EDT
On Tue, Oct 01, 2002 at 03:40:30PM +0400, Michael Tokarev wrote:
> Craig Sanders wrote:
> >On Fri, Sep 27, 2002 at 12:35:25AM +0400, Michael Tokarev wrote:
> >
> >>4. It's unclear what to do with multiple content_filters.
> >>This very issue currently exists as well and it may be
> >>very confused: when one defines *different* content_filters
> >>in different places (global parameter, smtpd maps, header/body
> >>checks, whatever).
> >
> >
> >it occurs to me that perhaps the best thing to do here is for postfix to
> >support just ONE global content-filter, and for that content-filter to
> >be a wrapper which is "smart" enough to make decisions about which other
> >content-filter(s) to call.
>
> Yes - this is how I see it too. The problem however is that queue file
> may contain multiple filter records (example: one from global content_filter
> parameter, it is placed on top of qfile, and another from header_checks,
> it is placed at the end of qfile). The question was about what to do
> with those multiple records, and which one to use (currently, postfix
> uses LAST one).
i'm not sure i see the problem. maybe i'm missing something here.
if you take it outside of postfix, then (as far as postfix is concerned)
there aren't multiple records, there's just one. all postfix needs is a
fairly simple facility for getting an external process (pipe, daemon,
whatever) to inspect and/or filter a message. postfix doesn't need to
know and shouldn't know what the filter does or how or why, it should
only care what the *final result* from the content-filter is - "OK",
"DUNNO", "REJECT", or "FILTER".
"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.
> >(btw, for the reinjection it would be nice if there was some way to
> >connect the new queue-id to the old queue-id, to make it easier to
> >trace what happened to any given message in the logs)
>
> That will be difficult at least. And in fact, this whole issue with
> content inspector is "inspired" by this -- inability to connect two
> "different" emails/qids that are in fact the same message.
yes. the only way i can think of to do it is a kludge using a temporary
header to store the old queue-id. e.g.
- the filter adds a header "X-Postfix-Old-QUEUE-ID" to the message
- there is a new postfix main.cf config verb called "read_old_queue_id"
(default = off) which instructs smtpd to look for that header,
log it with the new queue-id, and strip the header from the message.
- the message is transformed and then re-injected back into a postfix
smtpd running on another port with "-o content-filter=" and
"-o read_old_queue_id".
btw, my main reason for wanting content-inspection as well as
content-filtering is because a) i don't actually need to transform
messages and b) i want to reject messages, not bounce them (i.e. i don't
want undeliverable spam bounces in my mail queue). for me, the logging
issue is secondary....but still important.
> >it could read maps like the following (for recipient and/or for
> >sender) to know which content filters/inspectors to apply and in
> >which order:
>
> >[...]
>
> Oh well... ;) Let's done this outside postfix just as you proposed,
> ok? ;)
yep. that was just an off-the-top-of-my-head example of what the
content-filter (*not* postfix) could do.
> This way, "main" content filter logic will be very simple, [...]
yes, that's the crucial point. postfix's interface to content-filters
should be extremely simple. any complexity should be external to
postfix, in the CF itself....they can be as simple or as complex as
required.
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
|
|
|