On Tue, Jan 04, 2011 at 10:53:56AM -0500, Phil Howard wrote:
> And that is part of my thinking.
All the features that you can use are documented. The internals
that you can use to *reason* about the behaviour of the system
when things go wrong are less easily described.
> There MAY have been some
> "constructive" way to use different elements of Postfix that could
> have achieved the same effect, which might be obvious only to those
> who have the deep understanding (I am not one of those). The fact
> that PREPEND only inserts at that point where the triggering line is,
> is the limiting factor. In header checks, that's OK for inserting a
> header, although one does not have control where that insert happens
> (normally I'd want to insert any new header at the top, although for
> my current need, that won't matter).
The feature behaves exactly as documented, as are all the built-in
content inspection features:
http://www.postfix.org/BUILTIN_FILTER_README.html
> I'm assuming the header checks and body checks is implemented as some
> code that sees a stream, rather than the whole message (especially
> when doing body checks), so I'm guessing it would be non-trivial to
> add a new action in a future version that would do a "prepend to the
> top of headers".
You don't need to guess.
http://www.postfix.org/BUILTIN_FILTER_README.html#limitations
Header/body checks cannot filter on a combination of message
headers or body lines. Header/body checks examine content one
message header at a time, or one message body line at a time,
and cannot carry a decision over to the next message header or
body line.
> So I'm thinking about an alternative where I do a
> routine prepend of some very bizarre text (since it now inside the
> message body), that would be very unlikely to ever be in any message,
> and follow that with an external filter by inserting my own code
> between Postfix and Amavis (unless there is some means inside Amavis
> to hook in to do this) to store the message to a temporary file while
> looking for that bizarre text, and if found add the header when the
> message is sent on to Amavis (which later sends it back to Postfix).
Just do the original inspection in that filter, where you get the option
to base64-decode the content, parse the HTML, ...
My body checks are basically limited to:
/^Below is the result of your feedback form./ REJECT ...
Perhaps it should be possible to prepend a header in body-checks, this
is within the architectural capabilities of the current queue-file
format, which accomodates similar after-the-fact edits via milters.
There would probably need to be a duplicate elimination table, so that
each "PREPEND_HEADER" action in body_checks prepends at most one instance
of any given header.
No detailed design has been proposed to fill this need.
--
Viktor.
