At 22:24 2002-03-12 -0600, Mike Loiterman did say:
So I _shouldn't_ do this?
[snip]
bracing them in that fashion is no different than if they were like you
originally had them. It would still work at least as well as they
originally did (i.e. anything not processed by the original include file
would still be there for the second one).
>Thus, I said, "SPECIFICALLY what those recipes does has a LOT to do
>with how you make changes."
As you described, your SECOND filter set _IS_ filters - you could simply
choose to move it to be executed first and change nothing else about the
filters (assuming the spam perl script is merely adding a
header). LIterally, all you need to do is reverse the order of the two
include operations - no added flags or bracing.
I'm not intimately familiar with Sanitizer: I know it exists, I know what
it does - I don't know under what conditions it might _deliver_ the message
to a trashbox. Excepting filing a message away as infected, I don't see
why it would be consuming the message in any way -- it _should_ be altering
them, and that's PRECISELY why the suggested copy operation won't work as
you might hope it to - it'd alter a COPY, which, as the provided braced
code would have done, would just be discarded, and your spam check would
have operated on an UNALTERED version of the file (i.e. NOT
sanitized/defanged).
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail