You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Sietse van Zanen <si...@wizdom.nu> on 2006/05/09 19:26:29 UTC
Nasty bug? in 3.1.1 headers inserting?
Hi,
I have come across a nasty issue after upgrading from 3.0.2 to 3.1.1
last weekend.
Somehow the escape sequence when inserting headers into messages. Has
changed from \n\t to \n\r\t
See the two log examples below.
Apr 30 04:36:14 zpm sendmail[27183]: k3U2ZMeZ027183: Milter add: header:
X-Spam-Status: Yes, score=21.4 required=5.0
tests=BAYES_99,DCC_CHECK,\n\tDOMAIN_RATIO,HTML_90_100,HTML_IMAGE_ONLY_08
,HTML_MESSAGE,\n\tMIME_HTML_MOSTLY,MIME_QP_LONG_LINE,MPART_ALT_DIFF,PLIN
G_PLING,\n\tURIBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL
autolearn=no \n\tversion=3.0.2
May 9 15:37:03 zpm sendmail[25589]: k49DaweE025589: Milter add: header:
X-Spam-Status: Yes, score=21.5 required=6.0
tests=DCC_CHECK,\r\n\tDNS_FROM_RFC_ABUSE,FORGED_HOTMAIL_RCVD,FORGED_MUA_
OUTLOOK,\r\n\tFORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_10_20,HTML_ME
SSAGE,\r\n\tHTML_MIME_NO_HTML_TAG,HTTPS_IP_MISMATCH,INVALID_DATE,MIME_HT
ML_ONLY,\r\n\tMISSING_HEADERS,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,TO_CC_
NONE,\r\n\tX_PRIORITY_HIGH autolearn=spam version=3.1.1
You can disable the inserting of spam/ham headers and the issue is gone,
but then ofcourse the milter no longer works correctly, as it needs the
headers to extract the score from the message. It results in these
messages:
May 9 19:13:28 zpm spamass-milter[14281]: Could not extract score from
<>
I wonder why the escape sequence suddenly includes a carriage return
(\r) together with the newline (\n) and tab (\t). I use this machine as
a spam removal gateway for my Exchange environment and Exchange is not
amused by the carriage return and writes the part of the header after
that and any other headers directly into the body of the message.
I am using spamassassin 3.1.1, milter 0.3.0 sendmail 8.12.10 on redhat
enterprise 3.0
I use the following local.cf. This is all configuration I have, all mail
is checked for user root, as it is for Exchange and not local.
required_hits 6
rewrite_header Subject [SPAM (_HITS_)]
report_safe 1
trusted_networks 10.10.
lock_method flock
skip_rbl_checks 0
clear_headers
#add_header all DCC _DCCB_: _DCCR_
dns_available yes
ok_locales nl en
use_dcc 1
dcc_home /var/dcc
dcc_path /usr/local/bin/dccproc
def_whitelist_from_rcvd *@wizdom.nu
wizdom.nu
use_razor2 1
use_bayes 1
bayes_path /var/lib/spamassassin/bayes
use_bayes_rules 1
bayes_auto_learn 1
bayes_auto_learn_threshold_spam 8.0
bayes_ignore_header X-XS4ALL-DNSBL
bayes_file_mode 0777
bayes_journal_max_size 1048576
bayes_expiry_max_db_size 600000
use_auto_whitelist 1
Anybody has any ideas how this can be fixed?
-Sietse
Re: Nasty bug? in 3.1.1 headers inserting?
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 5/9/2006 2:16 PM, Theo Van Dinter wrote:
> There's some difference of opinion around this question, but my general
> opinion is that there should be an update to spamass-milter which
> properly handles the newlines either way. I'm not sure whether or not
> that's happened yet.
As discussed in this SA bug:
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4844
this spamass-milter bug has a (confirmed to work) patch that fixes the
problem with spamass-milter:
http://savannah.nongnu.org/bugs/?func=detailitem&item_id=16164
I do not know if there is an updated spamass-milter release. I'm
assuming there isn't since their bug is still open.
Daryl
Re: Nasty bug? in 3.1.1 headers inserting?
Posted by Theo Van Dinter <fe...@apache.org>.
On Tue, May 09, 2006 at 07:26:29PM +0200, Sietse van Zanen wrote:
> Somehow the escape sequence when inserting headers into messages. Has
> changed from \n\t to \n\r\t
Sort of, "\r\n\t".
> I wonder why the escape sequence suddenly includes a carriage return
> (\r) together with the newline (\n) and tab (\t). I use this machine as
> a spam removal gateway for my Exchange environment and Exchange is not
> amused by the carriage return and writes the part of the header after
> that and any other headers directly into the body of the message.
This has been discussed before, but the basics are that SpamAssassin
was previously always just adding in "\n", which caused problems on some
platforms where the line endings were supposed to be "\r\n". After much
debate about which way ("\r\n" vs "\n" vs ...) was correct, and whether
or not changing the behavior was a UI/API change versus a bug fix, etc,
we added in a patch to have the line ending determined and then use
that when adding in headers. Now SpamAssassin "does the right thing"
no matter what kind of line ending you throw at it. However, while half
the people are happy that this happens now, the other half are annoyed
that the previous "\n"-only behavior isn't the default anymore.
> I am using spamassassin 3.1.1, milter 0.3.0 sendmail 8.12.10 on redhat
> enterprise 3.0
[...]
> Anybody has any ideas how this can be fixed?
There's some difference of opinion around this question, but my general
opinion is that there should be an update to spamass-milter which
properly handles the newlines either way. I'm not sure whether or not
that's happened yet.
--
Randomly Generated Tagline:
A liar isn't believed even when he speaks the truth.