https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6027
Sidney Markowitz <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #1 from Sidney Markowitz <[EMAIL PROTECTED]> 2008-12-05 20:19:59
PST ---
There are a few problems with this bug report.
> when a rule marks a mail as spam, it will add "***SPAM*** "
> to the the front of the subject
SpamAssassin can be configured to modify headers of mail that scores as spam.
It can also be configured to generate a spam report with the original pristine
message as a MIME attachment and with no change to the Subject header. The
latter is preferable. The former is available as an option for people who have
to make do with primitive filtering methods that can only filter on the Subject
header. This problem demonstrates one reason why modifying configuring
SpamAssassin to modify the Subject header is not such a good idea.
> This will cause the BAD_ENC_HEADER to be triggered!
I have only seen that happen when someone takes an email that has been run
through some spam filter (maybe SpamAssassin, maybe not) at one site that has
been configured to add "***SPAM*** " to the Subject and sends the filtered mail
to another site that is running SpamAssassin. For example, I have received mail
that is sent through an ISP that spam filters outgoing mail that way. But when
SpamAssassin is configured to add a "***SPAM*** " prefix it will do it only
after running all the rules and then will not run the rules on that message
again.
If you have an example of a message that does not start out with the
"***SPAM***" prefix and and a SpamAssassin configuration that demonstrates this
bug, please attach it to this bug report.
> Subject: ***SPAM*** =?utf-8?B?Z2hqaiBoaiBoamhqa2w=?=
>
> This will cause the BAD_ENC_HEADER to be triggered!
No, it doesn't, at least not when I test it and not according to a visual
inspection of the rule. The BAD_ENC_HEADER rule, at least in the current
version 3.2 rules and in trunk, I haven't checked outdated versions, chacks for
a _bad_ encoded header, not just for any encoded header, and it doesn't care
about a non-encoded prefix such "***SPAM*** " and it does look for an embedded
space near the end after the first three question marks. Your example does not
trigger the rule on my machine.
> This is a typical american bug, you still live in your happy ascii world
I'll have to leave the answer to that to one of the handful of SpamAssassin
developers who actually live in the US.
I'm closing the bug as WORKSFORME, but feel free to reopen it if you have an
actual test case that demonstrates a bug.
--
Configure bugmail:
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
