Bug#775183: spamass-milter adds bad Received: header, creating false positive
All, I’m surprised that this has not yet been fixed. It makes the package unusable with SpamAssassin’s tests that rely on the Received header (such as all SPF and RBL tests), which are enabled by default. This bug should therefore be classified as ``serious’'. I’m also attaching a patch. Claus patch_spamass-milter_775183.diff Description: Binary data
Bug#775183: spamass-milter adds bad Received: header, creating false positive
On 14.01.2015 17:49, Don Armstrong wrote:
Can you try switching from confMILTER_MACROS_ENVRCPT to
confMILTER_MACROS_ENVFROM ? If that fixes this up, I'll change the
recommendation.
IE, add:
define(`confMILTER_MACROS_ENVFROM',`b')dnl
and remove b from ENCRCPT.
I imagine that somewhere in the code, sendmail falls back to the
date/time it started instead of the current time if it's unable to get a
correct date.
No luck with that. I had
define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name}, {if_name},
{if_addr}')dnl
define(`confMILTER_MACROS_HELO',`s, {tls_version}, {cipher}, {cipher_bits},
{cert_subject}, {cert_issuer}')dnl
define(`confMILTER_MACROS_ENVFROM',`{auth_authen}, b')dnl
define(`confMILTER_MACROS_ENVRCPT',`i, j, r, v, Z, _')dnl
Still, the date in the Received: headers sometimes is bad (sendmail startup
time).
But then I also removed the b from confMILTER_MACROS_ENVFROM.
This fixes the problem. The date still comes from sendmail, but
now it is correct. (Probably because of the b in
confMILTER_MACROS_CONNECT).
Maybe spamass-milter should always rely on its own system
time here that should be the same as the one from
sendmail. I suppose.
On a side note, please also add recommandation regarding the
'{auth_authen}' macro to the documentation. Otherwise the -I
option will not work.
moritz
--
aldebaran ProgrammierungIT-Lösungen GmbH
Softwareentwicklung Individualsoftware
mail:i...@aldebaran.dehttp://www.aldebaran.de
Tel: 0511-270 416-0 Fax:0511-270 416-33
Adresse: Hanomaghof 2 Ort: D-30449 Hannover
Geschäftsführung: Ursula (Usch) Wildt - Moritz Both
Handelsregister: Amtsgericht Hannover HRB 56 991
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775183: spamass-milter adds bad Received: header, creating false positive
On Wed, 14 Jan 2015, Moritz Both wrote:
Regarding the date problem, I have added some debug
statements to the spamass-milter code to get more info
about the result of smfi_getsymval(ctx, b).
This is the result:
Jan 14 08:33:19 eroski spamass-milter[51579]: mlfi_connect: enter
Jan 14 08:33:19 eroski spamass-milter[51579]: b macro is Wed, 14 Jan 2015
08:33:19 +0100
[...]
Jan 14 08:33:20 eroski spamass-milter[51579]: mlfi_envrcpt: enter
Jan 14 08:33:20 eroski spamass-milter[51579]: Total of 1 actual recipients
Jan 14 08:33:20 eroski spamass-milter[51579]: Date for Received header line
from macro b: Wed, 7 Jan 2015 11:04:24 +0100
It seems you are right about the sendmail b macro messed up,
but only in certain callbacks to the milter.
So this might be a sendmail / libmilter problem, or anything messes
with the ctx structure.
Yeah. Apparently it was happening back in 2006, too:
http://newsgroups.derkeiler.com/Archive/Comp/comp.mail.sendmail/2006-06/msg00413.html
and apparently this workaround works:
http://mail-archives.apache.org/mod_mbox/spamassassin-users/201402.mbox/%3c20140221143538.ga6...@fantomas.sk%3E
[...]
I have these definitions in my sendmail.mc file:
define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name}, {if_name},
{if_addr}')dnl
define(`confMILTER_MACROS_HELO',`s, {tls_version}, {cipher}, {cipher_bits},
{cert_subject}, {cert_issuer}')dnl
define(`confMILTER_MACROS_ENVRCPT',`b, i, j, r, v, Z, _')dnl
Can you try switching from confMILTER_MACROS_ENVRCPT to
confMILTER_MACROS_ENVFROM ? If that fixes this up, I'll change the
recommendation.
IE, add:
define(`confMILTER_MACROS_ENVFROM',`b')dnl
and remove b from ENCRCPT.
I imagine that somewhere in the code, sendmail falls back to the
date/time it started instead of the current time if it's unable to get a
correct date.
moritz
--
aldebaran ProgrammierungIT-Lösungen GmbH
Softwareentwicklung Individualsoftware
mail:i...@aldebaran.dehttp://www.aldebaran.de
Tel: 0511-270 416-0 Fax:0511-270 416-33
Adresse: Hanomaghof 2 Ort: D-30449 Hannover
Geschäftsführung: Ursula (Usch) Wildt - Moritz Both
Handelsregister: Amtsgericht Hannover HRB 56 991
--
Don Armstrong http://www.donarmstrong.com
Overcast nights are beautiful; the sun, mostly set, a near full moon
partially risen, light pollution from the city, and the sky delicately
purpleorangegray, as if it were a livid bruise.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775183: spamass-milter adds bad Received: header, creating false positive
Regarding the date problem, I have added some debug statements to the spamass-milter code to get more info about the result of smfi_getsymval(ctx, b). This is the result: Jan 14 08:33:19 eroski spamass-milter[51579]: mlfi_connect: enter Jan 14 08:33:19 eroski spamass-milter[51579]: b macro is Wed, 14 Jan 2015 08:33:19 +0100 [...] Jan 14 08:33:20 eroski spamass-milter[51579]: mlfi_envrcpt: enter Jan 14 08:33:20 eroski spamass-milter[51579]: Total of 1 actual recipients Jan 14 08:33:20 eroski spamass-milter[51579]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 It seems you are right about the sendmail b macro messed up, but only in certain callbacks to the milter. So this might be a sendmail / libmilter problem, or anything messes with the ctx structure. It only happens with some messages. I can reproduce it with messages from our web contact form (the web is running somewhere else), some other spam has a correct date at that spot. The bad date is somewhat constant. At the moment, it is Wed, 7 Jan 2015 11:04:24 +0100. It is directly related to sendmail daemon uptime: root@eroski:~# zgrep 'starting daemon' /var/log/mail.log* /var/log/mail.log.1:Jan 7 11:04:24 eroski sm-mta[50274]: starting daemon (8.14.4): SMTP+queueing@00:10:00 It is not directly related to server uptime: root@eroski:~# uptime 10:27:32 up 34 days, 19:49, 2 users, load average: 0,03, 0,22, 0,20 Neither is it related to spamass-milter daemon running time, I restarted it frequently. Restarting sendmail leads to a new constant date, the rest is the same. grepping the logfile for the macro b date: root@eroski:~# grep 'Date for Received header line from macro b' /var/log/mail.log Jan 13 11:11:54 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 11:11:53 +0100 Jan 13 11:24:24 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 11:24:23 +0100 Jan 13 11:24:26 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 11:25:46 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 11:25:44 +0100 Jan 13 11:28:32 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 11:28:31 +0100 Jan 13 11:35:34 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 11:35:32 +0100 Jan 13 11:40:06 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 11:40:04 +0100 Jan 13 11:43:04 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 11:49:30 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 11:49:28 +0100 Jan 13 11:50:54 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 11:50:53 +0100 Jan 13 12:02:54 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:03:08 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:07:06 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 12:07:05 +0100 Jan 13 12:10:16 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 12:10:15 +0100 Jan 13 12:13:07 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:14:47 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:14:53 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:15:25 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:15:30 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:15:34 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:15:42 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:16:24 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:16:43 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:25:56 eroski spamass-milter[32120]: Date for Received header line from macro b: Tue, 13 Jan 2015 12:25:54 +0100 Jan 13 12:26:03 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:30:20 eroski spamass-milter[32120]: Date for Received header line from macro b: Wed, 7 Jan 2015 11:04:24 +0100 Jan 13 12:34:33 eroski spamass-milter[32120]: Date for Received header line from macro b:
Bug#775183: spamass-milter adds bad Received: header, creating false positive
On Tue, 13 Jan 2015, Moritz Both wrote:
Don,
thank you for the response. I hope this bug report does not mutate
to a support case embarrasingly ;) Anyway I'm confused your
source code is diffrent from mine... is there something newer than
0.3.2-1 in stable? Is your code from 0.3.2-1b1 from sid?
moritz@eroski:~/src$ apt-get source spamass-milter
[...]
Holen: 1 http://ftp.de.debian.org/debian/ wheezy/main spamass-milter 0.3.2-1
(dsc) [1.882 B]
Holen: 2 http://ftp.de.debian.org/debian/ wheezy/main spamass-milter 0.3.2-1
(tar) [155 kB]
Holen: 3 http://ftp.de.debian.org/debian/ wheezy/main spamass-milter 0.3.2-1
(diff) [15,1 kB]
Es wurden 172 kB in 0 s geholt (526 kB/s).
dpkg-source: Information: spamass-milter wird nach spamass-milter-0.3.2
extrahiert
dpkg-source: Information: spamass-milter_0.3.2.orig.tar.gz wird entpackt
dpkg-source: Information: spamass-milter_0.3.2-1.debian.tar.gz wird entpackt
dpkg-source: Information: ignore_by_smtp_auth wird angewandt
dpkg-source: Information: fix_spacing_in_received_header wird angewandt
dpkg-source: Information: fix_header_char_cast wird angewandt
dpkg-source: Information: add_ipv6_support wird angewandt
dpkg-source: Information: auth_in_received wird angewandt
Now, spamass-milter.cpp says
string rec_header;
rec_header=(string)Received: from +macro_s+
(+macro__+)\r\n\t;
if (strlen(macro_auth_type)!=0) {
rec_header+=(string)(authenticated;
if (strlen(macro_auth_ssf)!=0) {
rec_header+=(string) bits=+macro_auth_ssf;
}
rec_header+=(string))\r\n\t;
}
rec_header+=(string)by +macro_j+(+macro_v+/+macro_Z+)
with +
macro_r+ id +macro_i+\r\n\t+
macro_b+\r\n\t+
(envelope-from +assassin-from()+\r\n;
debug(D_SPAMC, Received header for spamc: %s,
rec_header.c_str());
assassin-output(rec_header);
It is obvious that this code does not add the ; or ). To me it is not
obvious why my dates are messed up. I added the -d ALL switch and wait
for the next occurance in the next several hours.
Hrm. Actually, I see the problem now. For some crazy reason, the patches
(probably when I was updating to 3.3.2) got screwed up, and I didn't
catch this.
I'll fix them now.
--
Don Armstrong http://www.donarmstrong.com
Live and learn
or die and teach by example
-- a softer world #625
http://www.asofterworld.com/index.php?id=625
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775183: spamass-milter adds bad Received: header, creating false positive
Don,
thank you for the response. I hope this bug report does not mutate
to a support case embarrasingly ;) Anyway I'm confused your
source code is diffrent from mine... is there something newer than
0.3.2-1 in stable? Is your code from 0.3.2-1b1 from sid?
moritz@eroski:~/src$ apt-get source spamass-milter
[...]
Holen: 1 http://ftp.de.debian.org/debian/ wheezy/main spamass-milter 0.3.2-1
(dsc) [1.882 B]
Holen: 2 http://ftp.de.debian.org/debian/ wheezy/main spamass-milter 0.3.2-1
(tar) [155 kB]
Holen: 3 http://ftp.de.debian.org/debian/ wheezy/main spamass-milter 0.3.2-1
(diff) [15,1 kB]
Es wurden 172 kB in 0 s geholt (526 kB/s).
dpkg-source: Information: spamass-milter wird nach spamass-milter-0.3.2
extrahiert
dpkg-source: Information: spamass-milter_0.3.2.orig.tar.gz wird entpackt
dpkg-source: Information: spamass-milter_0.3.2-1.debian.tar.gz wird entpackt
dpkg-source: Information: ignore_by_smtp_auth wird angewandt
dpkg-source: Information: fix_spacing_in_received_header wird angewandt
dpkg-source: Information: fix_header_char_cast wird angewandt
dpkg-source: Information: add_ipv6_support wird angewandt
dpkg-source: Information: auth_in_received wird angewandt
Now, spamass-milter.cpp says
string rec_header;
rec_header=(string)Received: from +macro_s+
(+macro__+)\r\n\t;
if (strlen(macro_auth_type)!=0) {
rec_header+=(string)(authenticated;
if (strlen(macro_auth_ssf)!=0) {
rec_header+=(string) bits=+macro_auth_ssf;
}
rec_header+=(string))\r\n\t;
}
rec_header+=(string)by +macro_j+(+macro_v+/+macro_Z+)
with +
macro_r+ id +macro_i+\r\n\t+
macro_b+\r\n\t+
(envelope-from +assassin-from()+\r\n;
debug(D_SPAMC, Received header for spamc: %s,
rec_header.c_str());
assassin-output(rec_header);
It is obvious that this code does not add the ; or ). To me it is not
obvious why my dates are messed up. I added the -d ALL switch and wait
for the next occurance in the next several hours.
Regards,
moritz
On 13.01.2015 01:16, Don Armstrong wrote:
On Mon, 12 Jan 2015, Moritz Both wrote:
Package: spamass-milter
Version: 0.3.2-1
Severity: important
Dear Don,
when a message is detected as spam, it is prepended with a waring message.
The original message appears as a mime attachment.
This attachment has a bad Received: header like this:
Received: from vwp12xxx.webpack.hosteurope.de
(vwp12xxx.webpack.hosteurope.de [5.35.232.xxx])
by eroski.aldebaran.de(8.14.4/8.14.4/Debian-4) with ESMTP id
t06Df1fZ019601
Wed, 10 Dec 2014 14:38:06 +0100
(envelope-from scr...@wp11273xxx.server-he.de
Note the following problems:
1. The semicolon at the end of the id is missing (RFC 2822
requires it like id t06Df1fZ019601;).
2. The (envelope-from... comment does not have a closing parenthesis.
3. Most importantly, the date is wrong. This email was received on 06 Jan
2015.
It is very strange that we have a wrong date here because the clock of the
mail
server running spamass-milter and sendmail has probably been correct; it is
adjusted using ntp with several servers in the net. Also, all the other
date headers in the mail are correct and if the clock would have been
wrong, more header lines should be wrong, too.
This is kind of odd... the actual code that generates this is the
following:
assassin-output((string)
Received: from +macro_s+ (+macro__+)\r\n\t+
by +macro_j+(+macro_v+/+macro_Z+) with
+macro_r+ id +macro_i+;\r\n\t+
macro_b+\r\n\t+
(envelope-from +assassin-from()+)\r\n);
which contains the semicolon and properly encloses the from.
The date which is reported is by calling macro_b, or if that's not
available, by calling
strftime(date, sizeof(date), %a, %d %b %Y %H:%M:%S %z, localtime(tval));
Could it be something in SA which is screwing up this header (or maybe
macro _b is totally screwed up?)
Jan 6 14:41:03 eroski sm-mta[19601]: t06Df1fZ019601:
from=scr...@wp11273xxx.server-he.de, size=4298, class=0, nrcpts=1,
msgid=1420551661.54abe5ed54...@www.aldebaran.de, proto=ESMTP,
daemon=MTA-v4, relay=vwp12xxx.webpack.hosteurope.de [5.35.232.xxx]
Jan 6 14:41:03 eroski spamd[11954]: spamd: connection from localhost
[127.0.0.1] at port 51249
Jan 6 14:41:03 eroski spamd[11954]: spamd: creating default_prefs:
/dev/null/.spamassassin/user_prefs
Jan 6 14:41:03 eroski spamd[11954]: spamd: failed to create readable
default_prefs: /dev/null/.spamassassin/user_prefs
Jan 6 14:41:03 eroski spamd[11954]: spamd: processing message
1420551661.54abe5ed54...@www.aldebaran.de for xnfo:xxx
Jan 6 14:41:08 eroski spamd[11954]: spamd:
Bug#775183: spamass-milter adds bad Received: header, creating false positive
Package: spamass-milter Version: 0.3.2-1 Severity: important Dear Don, when a message is detected as spam, it is prepended with a waring message. The original message appears as a mime attachment. This attachment has a bad Received: header like this: Received: from vwp12xxx.webpack.hosteurope.de (vwp12xxx.webpack.hosteurope.de [5.35.232.xxx]) by eroski.aldebaran.de(8.14.4/8.14.4/Debian-4) with ESMTP id t06Df1fZ019601 Wed, 10 Dec 2014 14:38:06 +0100 (envelope-from scr...@wp11273xxx.server-he.de Note the following problems: 1. The semicolon at the end of the id is missing (RFC 2822 requires it like id t06Df1fZ019601;). 2. The (envelope-from... comment does not have a closing parenthesis. 3. Most importantly, the date is wrong. This email was received on 06 Jan 2015. It is very strange that we have a wrong date here because the clock of the mail server running spamass-milter and sendmail has probably been correct; it is adjusted using ntp with several servers in the net. Also, all the other date headers in the mail are correct and if the clock would have been wrong, more header lines should be wrong, too. Point 3 leads to false positive. Here is a quote of most of the message, with only the end (with content) cut off, and some sensitive info replaced with x. 8--- Return-Path: scr...@wp11273xxx.server-he.de Received: from xx.aldebaran.de ([unix socket]) by xx (Cyrus v2.4.16-Debian-2.4.16-4+deb7u2) with LMTPA; Tue, 06 Jan 2015 14:41:09 +0100 X-Sieve: CMU Sieve 2.4 Received: from eroski.aldebaran.de (mail.aldebaran.de [81.14.208.171]) by xx.aldebaran.de (8.14.4/8.14.4/Debian-4) with ESMTP id t06Df84L017749 for x...@xxx.aldebaran.de; Tue, 6 Jan 2015 14:41:09 +0100 Received: from vwp12xxx.webpack.hosteurope.de (vwp12xxx.webpack.hosteurope.de [5.35.232.xxx]) by eroski.aldebaran.de (8.14.4/8.14.4/Debian-4) with ESMTP id t06Df1fZ019601 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for x...@aldebaran.de; Tue, 6 Jan 2015 14:41:02 +0100 Received: from wp11273xxx by vwp12xxx.webpack.hosteurope.de running ExIM with local id 1Y8UNZ-0001NQ-EH; Tue, 06 Jan 2015 14:41:01 +0100 Message-ID: 1420551xxx.54abe5ed5x...@www.aldebaran.de Date: Tue, 06 Jan 2015 14:41:01 +0100 Subject: Kontakt-Mail =?utf-8?Q?=C3=BCber?= www.aldebaran.de From: xx...@www.aldebaran.de To: x...@aldebaran.de MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=--=_54ABE5F4.1DA96507 X-Priority: 3 (Normal) X-Mailer: TYPO3 X-bounce-key: webpack.hosteurope.de;scr...@wp11273xxx.server-he.de;1420551662;b5358da8; X-Spam-Flag: YES X-Spam-Status: Yes, score=6.7 required=5.0 tests=BAYES_50,DATE_IN_FUTURE_96_Q, HTML_MESSAGE,T_FILL_THIS_FORM_SHORT,UNPARSEABLE_RELAY,URI_OBFU_WWW,XPRIO autolearn=spam version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eroski.aldebaran.de This is a multi-part message in MIME format. =_54ABE5F4.1DA96507 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Spam detection software, running on the system eroski.aldebaran.de, has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: xx xxx Content analysis details: (6.7 points, 5.0 required) pts rule name description -- -- 2.4 DATE_IN_FUTURE_96_QDate: is 4 days to 4 months after Received: date 2.5 URI_OBFU_WWW BODY: Obfuscated URI 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 1.0 XPRIO Has X-Priority header 0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. =_54ABE5F4.1DA96507 Content-Type: message/rfc822; x-spam-type=original Content-Description: original message before SpamAssassin Content-Disposition: attachment Content-Transfer-Encoding: 8bit X-Envelope-From: scr...@wp11273xxx.server-he.de X-Envelope-To: i...@aldebaran.de Received: from vwp12xxx.webpack.hosteurope.de (vwp12xxx.webpack.hosteurope.de [5.35.232.xxx]) by eroski.aldebaran.de(8.14.4/8.14.4/Debian-4) with ESMTP
Bug#775183: spamass-milter adds bad Received: header, creating false positive
On Mon, 12 Jan 2015, Moritz Both wrote: Package: spamass-milter Version: 0.3.2-1 Severity: important Dear Don, when a message is detected as spam, it is prepended with a waring message. The original message appears as a mime attachment. This attachment has a bad Received: header like this: Received: from vwp12xxx.webpack.hosteurope.de (vwp12xxx.webpack.hosteurope.de [5.35.232.xxx]) by eroski.aldebaran.de(8.14.4/8.14.4/Debian-4) with ESMTP id t06Df1fZ019601 Wed, 10 Dec 2014 14:38:06 +0100 (envelope-from scr...@wp11273xxx.server-he.de Note the following problems: 1. The semicolon at the end of the id is missing (RFC 2822 requires it like id t06Df1fZ019601;). 2. The (envelope-from... comment does not have a closing parenthesis. 3. Most importantly, the date is wrong. This email was received on 06 Jan 2015. It is very strange that we have a wrong date here because the clock of the mail server running spamass-milter and sendmail has probably been correct; it is adjusted using ntp with several servers in the net. Also, all the other date headers in the mail are correct and if the clock would have been wrong, more header lines should be wrong, too. This is kind of odd... the actual code that generates this is the following: assassin-output((string) Received: from +macro_s+ (+macro__+)\r\n\t+ by +macro_j+(+macro_v+/+macro_Z+) with +macro_r+ id +macro_i+;\r\n\t+ macro_b+\r\n\t+ (envelope-from +assassin-from()+)\r\n); which contains the semicolon and properly encloses the from. The date which is reported is by calling macro_b, or if that's not available, by calling strftime(date, sizeof(date), %a, %d %b %Y %H:%M:%S %z, localtime(tval)); Could it be something in SA which is screwing up this header (or maybe macro _b is totally screwed up?) Jan 6 14:41:03 eroski sm-mta[19601]: t06Df1fZ019601: from=scr...@wp11273xxx.server-he.de, size=4298, class=0, nrcpts=1, msgid=1420551661.54abe5ed54...@www.aldebaran.de, proto=ESMTP, daemon=MTA-v4, relay=vwp12xxx.webpack.hosteurope.de [5.35.232.xxx] Jan 6 14:41:03 eroski spamd[11954]: spamd: connection from localhost [127.0.0.1] at port 51249 Jan 6 14:41:03 eroski spamd[11954]: spamd: creating default_prefs: /dev/null/.spamassassin/user_prefs Jan 6 14:41:03 eroski spamd[11954]: spamd: failed to create readable default_prefs: /dev/null/.spamassassin/user_prefs Jan 6 14:41:03 eroski spamd[11954]: spamd: processing message 1420551661.54abe5ed54...@www.aldebaran.de for xnfo:xxx Jan 6 14:41:08 eroski spamd[11954]: spamd: identified spam (6.7/5.0) for xnfo:xxx in 5.6 seconds, 4802 bytes. Jan 6 14:41:08 eroski spamd[11954]: spamd: result: Y 6 - BAYES_50,DATE_IN_FUTURE_96_Q,HTML_MESSAGE,T_FILL_THIS_FORM_SHORT,UNPARSEABLE_RELAY,URI_OBFU_WWW,XPRIO scantime=5.6,size=4802,user=xnfo,uid=xxx,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=51249,mid=1420551661.54abe5ed54...@www.aldebaran.de,bayes=0.50,autolearn=spam Jan 6 14:41:08 eroski sm-mta[19601]: t06Df1fZ019601: Milter add: header: X-Spam-Flag: YES Jan 6 14:41:08 eroski sm-mta[19601]: t06Df1fZ019601: Milter add: header: X-Spam-Status: Yes, score=6.7 required=5.0 tests=BAYES_50,DATE_IN_FUTURE_96_Q,\n\tHTML_MESSAGE,T_FILL_THIS_FORM_SHORT,UNPARSEABLE_RELAY,URI_OBFU_WWW,XPRIO\n\tautolearn=spam version=3.3.2 Jan 6 14:41:08 eroski sm-mta[19601]: t06Df1fZ019601: Milter add: header: X-Spam-Level: ** Jan 6 14:41:08 eroski sm-mta[19601]: t06Df1fZ019601: Milter add: header: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eroski.aldebaran.de Jan 6 14:41:08 eroski sm-mta[19601]: t06Df1fZ019601: Milter change: header Content-Type: from multipart/alternative;\n boundary=_=_swift_v4_142055166154axx0ede_=_ to multipart/mixed; boundary=--=_54ABE5F4.1Dxx Jan 6 14:41:08 eroski sm-mta[19601]: t06Df1fZ019601: Milter message: body replaced Jan 6 14:41:09 eroski sm-mta[19604]: t06Df1fZ019601: to=x...@xx.aldebaran.de, delay=00:00:07, xdelay=00:00:01, mailer=esmtp, pri=37875, relay=xx.aldebaran.de. [x.x.0.x], dsn=2.0.0, stat=Sent (t06Df84L01 Message accepted for delivery) It might be informative to set -d ALL to spamass-milter too, just to see what is going on. -- Don Armstrong http://www.donarmstrong.com Filing a bug is probably not going to get it fixed any faster. -- Anthony Towns -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
