You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2008/12/06 04:20:55 UTC
[Bug 6027] New: SpamAssassin creates it's own spam (BAD_ENC_HEADER)
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6027
Summary: SpamAssassin creates it's own spam (BAD_ENC_HEADER)
Product: Spamassassin
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: blocker
Priority: P5
Component: Score Generation
AssignedTo: dev@spamassassin.apache.org
ReportedBy: web2@bak-o-soft.dk
When encoding headers with utf-8 spamassassin will create it's own spam (or
rather increase the spam score).
First, when a rule marks a mail as spam, it will add "***SPAM*** " to the the
front of the subject. This will now trigger a BAD_ENC_HEADER which can actually
cause the mail to be deleted!
Example:
X-Spam-Status: Yes, score=4.679 tagged_above=-999 required=3
tests=[BAD_ENC_HEADER=2.87, HTML_IMAGE_ONLY_20=1.808,
HTML_MESSAGE=0.001]
This gives the following subject:
Subject: ***SPAM*** =?utf-8?B?Z2hqaiBoaiBoamhqa2w=?=
This will cause the BAD_ENC_HEADER to be triggered!
Of course , adding the "spam" to the subject MUST be done in a real manner.
This is a typical american bug, you still live in your happy ascii world :-(
To reproduce, encode headers in utf-8 and trigger a mild spam status, that adds
"***SPAM*** " to the subject. Notice that it will now also trigger the
BAD_ENC_HEADER !
THIS MAY NEVER HAPPEN! It totally ruins the 'mild' spam status. FIX IT!
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6027] SpamAssassin creates it's own spam (BAD_ENC_HEADER)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6027
Anthony Howe <ac...@snert.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |achowe@snert.com
--- Comment #2 from Anthony Howe <ac...@snert.com> 2008-12-06 02:46:47 PST ---
I agree with the developer.
I'd like to add further comment to edify the reporter that RFC 2047 section 5
defines where "encoded-words" can be used to encode single words or phrases
intermixed with ASCII words or phrases. In the case of the Subject: header,
there is nothing that requires the WHOLE header be an encoded-word, when an
encoded-word is used. Therefore the insertion of a spam tag, mailing list name,
Re:, Fwd:, or similar prefixes in the Subject: header does not break the
encoded-word.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6027] SpamAssassin creates it's own spam (BAD_ENC_HEADER)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6027
Sidney Markowitz <si...@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #1 from Sidney Markowitz <si...@sidney.com> 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.