My
mistake. It only removes those headers if report_safe is set to 1.
When set to zero, even though the message is spam, the headers remain
intact. I think I knew that, but my brain farted there when I was writing
that email. :)
At any
rate, this is verified by taking a raw message with those headers present, and
*manually* running:
spamassassin.bat < test.msg >
test.out
With
report_safe at 1, test.out does not have the "return-path" or "envelope-to" of
the original. I will note that those headers *do exist* in the email
attachment that report_safe includes in this new message.
So... when report_safe creates this new email
with the original as an attachment, why doesn't it include those all important
headers? Is that normal? Does that work for everyone but somehow my
install is broken? You mentioned that in report_safe 1 or 2 it doesn't
include those, so I'm assuming this is normal.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Byrnand
Sent: Monday, June 09, 2003 7:32 PM
To: Aaron; [EMAIL PROTECTED]At 11:14 9/06/03 -0700, Aaron wrote:I saw that in my own testing.
Here's the work flow:
- Communigate calls a "spamprep" program that adds the proper envelope-to and from headers to the message file itself and deletes the original
- SpamAssassin scans that temp file with the added headers.
- The Communigate script will then take the scanned file and resubmit it by copying to the "submitted" directory (a PIPE submit)
### here's where it gets interesting ###
- If the email is not considered spam, the headers are unaltered and the email gets delivered just as intended
- If the email *IS* considered spam, those envelope-to headers that were so nicely added are stripped away. This is the case whether you use report_safe or not.
No, Spamassassin doesn't do that in report_safe 0 mode, I just tested it to double check by manually adding an Envelope-To: and Envelope-From: header and running it through spamc, and those headers (and others) are all intact, so your problem is elsewhere, most likely with the script that is interfacing spamassassin with communigate.
Without the envelope-to headers, Communigate has no choice but to attempt delivery using the to: and cc: fields of the original message, which as we all know in the case of spam is most likely bogus.
Saying communigate "has no choice" but to do the wrong thing (deliver to to: and cc:) is rediculous. It is *wrong* for a destination mailserver to deliver to the To: and CC: headers of a message, *period*. What it should do is flag some kind of error to the postmaster, rather than spamming the rest of the world with mis-addressed messages.
For that reason, I *MUST* simply discard all messages tagged as spam on my Communigate server, otherwise it would only act as a "spamplifier".
It has been suggested that the scripting used on Communigate is at fault, yet I can say 100% for sure that those envelope-to headers are intact when they are submitted to SpamAssassin for scanning, and ONLY when SA marks it as spam (exceeds the threshold score), it is ONLY then that the envelope-to header mysteriously vanishes, and this is the case whether report_safe is 0 or 1.
And I can say 100% that spamassassin doesn't strip those headers in report_safe 0 mode. Have you tried a manual test ? Take a message as a file, add those headers in (if they aren't already) run it through spamassassin or spamc, and what do you see ?
I think you'll find the script is at fault, and this has already been discussed on the list a few weeks ago by me and others - basically it looks like the sample communigate.sh script is out of date and buggy.
Is there any reason why SA would ignore those envelope-to: headers when rewriting an email tagged as spam?
Nope, not unless you're in report_safe 1 or 2 modes.
I would LOVE to be able to give my users the option of having their spam delivered, but with the headers added so they can filter on their own, but this flaw in SA's execution prevents that.
Is it because those added headers are the very first header lines? Would it help at all if they were further down in the headers or something? Why wouldn't SA just copy all the existing headers anyway?
In report_safe 0 it does.
If anyone is the least bit curious about this, I can provide a sample email with those added headers and you can run it yourself, seeing how, indeed, SA does remove those headers just as I described.
That I'd like to see....
Regards,
Simon
