http://bugzilla.spamassassin.org/show_bug.cgi?id=3605
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Future |3.0.2
------- Additional Comments From [EMAIL PROTECTED] 2004-10-26 11:36 -------
I suggest we fix this for 3.0.2. It's becoming a very big FAQ, and, while it
makes for some elegance in the code, it's entirely nonintuitive behaviour.
also: the paranoia about a spammer adding their own X-Spam-Created-Header:
header seems a bit OTT. what's the danger here?
- spammer sends spam
- SA marks it as spam, message gets filed to user's "spam" folder
- user eventually, for some reason, decides to "spamassassin -d" the message
- output may be != original spam
1. that doesn't help the spammer get past SA in any way.
2. we can avoid this by removing X-Spam-Created-Header headers at rewrite time,
same as we should be doing with X-Spam-Prev headers.
3. we're *not* doing that with X-Spam-Prev headers *anyway*, so it appears it
really hasn't been a big deal so far and we shouldn't be worrying so much about
it in this case ;)
oh, and on the a/b thing: I'm for (b) -- 'we should rewrite all of the headers
-- add the Subject if necessary, fix non-RFC compliant Content-Type headers,
etc, etc. basically make the output from SA less likely to cause issues
"downstream".' I wouldn't want to see a deliberately corrupted message cause
MUA crashes, compromises, exploits etc. when we might be able to easily avoid
it.
in fact, earlier versions of SA (iirc) used to defang "Return-Receipt-To" and
similar headers, but 3.0.0 doesn't any more.... which probably is not a good
thing.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
