Loren Wilton wrote:
> [...]
> SpamCop likes the original emails forwarded to them, so they can
> parse the headers and figure out where the evil beast came from,
then
> send it on to the abuse department of the ISP.
>
> Spamassassin of course likes to wrap old spam in its own
newspapers
> before throwing it out. This kinda conflicts wiith being able
to
> dispose of the spam thru SpamCop.
Some choices that come to mind:
1. You can have spamassassin leave the original more-or-less
intact by specifying:
report_safe 0
to local.cf, and possibly remove_header if you don't want the
X-Spam headers either.
2. Use the default of report_safe 1 (the wrapping) and
forward/resend the ATTACHED message. There have been several
messages on how to do this with various clients, and the details
depend on what you use. With the report_safe 0, the original is
more-or-less untouched, so that should work.
3. Push the message through:
spamassassin --remove-markup
To more-or-less restore it to the original state.
> I like the Spamcop headers on things so I can see what they are.
But
> I'd also like to get the original message, with maybe one added
> header, something like "X-SpamAssassin-Detected-Spam: 10.7", and
not
> all the fishwrapping, so I could filter the original spam into a
> bucket, or maybe auto-forward it to SpamCop.
I'm kicking around something like this, but for different reasons.
I want to run each message through several spam and virus checking
engines for testing purposes. I'd like to pass the original,
unmodified (as-received) version through several checkers (clamav,
spamassassin, bogofilter, spamoracle), then save a modified
version with headers from ALL of these in my spam box for review
and comparison. During this process, it would be easy enough to
just save a copy of the unmodified version off, then look it up by
message-id etc.
Has anyone developed any good rules for such "parallel testing"
with procmail or external scripts?
Thanks,
- Bob
