On Tue, Jan 4, 2011 at 11:14, Victor Duchovni <victor.ducho...@morganstanley.com> wrote: > On Tue, Jan 04, 2011 at 10:53:56AM -0500, Phil Howard wrote:
>> 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. At this point I'm looking at this in terms of "can the needed feature be added". The implementation of the test itself, and the implementation of how the test is connected into the rest of the system matter. The test itself dictates the behavior. How it's connected in can (and was my guess that it does) limit the possibilities of adding a like test. In other words, for the test itself to be changed (as a new kind of test) to do what I need, it would either need random access to the message file (which cannot happen here if the message is not yet stored as a file), or has separated headers. For example an implementation of the surrounding infrastructure that separated the headers and store them, alone, in a temporary file or even a temporary buffer, and processed the remainder of the message as a text line stream, could modify the headers on the side. My assumption (guess) is that Postfix doesn't do this. But a description of the test itself doesn't confirm that because the simpler test can still be done in all the variety of possible environments. >> 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 ... Rejecting is not an option, per local policy, for any message based on its contents. The only case where we can do a reject is more easily done as an access rule in the firewall (e.g. for a DoS attack). > 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. Separation of headers and body for the purpose of modifying message content would be helpful. A "PREPEND_TO_HEADERS" action would then be useful if that can be done. A "Received" header gets prepended. But that is easily doable before any other content processing is done. But at this point I'm going to spend my time either trying to find another way to do this, or find a way to not need to do this (e.g. do more tests in Amavis or Spamassassin, depending on what capabilities exist there, which I am still getting into). In the past, I've always done anti-spam actions by blacklists or whitelists, and rejecting everything that comes from anywhere spam comes from. But this is a new case where such rejection is not an option. The plan is if it looks like a virus or spam, it goes into a virus or spam subfolder. Blacklists are probably not in the plan. Whitelists might be as a means to bypass spam checking. -- sHiFt HaPpEnS!
