After adding a bit of debugging information to Received.pm I was able to
track down the problem I was having with SpamAssassin and the -notfirsthop
rules. The following line is the code in spamass-milter that send the
pseudo header to Spamassassin:
assassin->output((string)"Received: from "+macro_s+"
("+smfi_getsymval(ctx,"_")+") by "+smfi_getsymval(ctx,"j")+";
"+macro_b+"\r\n");
macro_b is only available to spamass-milter if defined in Sendmail's
configuration; it's not defined in my Sendmail configuration. As a result
macro_b gets set to an empty string, but there is a space prior to macro_b
which remains. The end result is a whitespace preceding the newline
characters. In SpamAssassin's Received.pm we have the following:
my @rcvd = ($hdrs =~ /^(\S.+\S)$/gm);
This code populates @rcvd with the headers that will be passed to
parse_received_line(). As you can see from the regex, it doesn't take
kindly to whitespaces before the newline characters. As a result the pseudo
header from spamass-milter never gets parsed and SpamAssassin never knows
that the sending MTA existed. This causes problems since the assumption is
made that the Received: header added by the receiving MTA has already been
added before SpamAssassin processes the email.
This results in behavior such as header checks (including RBL checks) not
being performed on the sending MTA. This caused -notfirsthop rules like
DYNABLOCK to be practically useless since it would not catch open proxies on
cable/dsl machine which delivered directly to the SpamAssassin mail server.
In addition rules like DYNABLOCK would generate false-positives on emails
from dialup and cable/dsl users which traveled through a single hop (such as
their ISP's mail server) before reaching SpamAssassin since SpamAssassin
would see only a single header (the one added by the ISP) and would believe
that the mail had been delivered directly to SpamAssassin from the user's
machine.
My workaround was just to modify the spamass-milter code and remove the
macro_b and preceding space from the code since I'm not using it. There are
a couple obvious other solutions to this problem (in order of decreasing
preference) such as modifying the spamass-milter code to only insert the
whitespace if macro_b is defined, adding the required macro to the Sendmail
config, or modifying the SpamAssassin code to accept (but not store)
whitespace before the newline character.
Brian
-----Original Message-----
From: Brian Sneddon [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 4:42 PM
To: [EMAIL PROTECTED]
Subject: [SAtalk] SpamAssassin with Sendmail and spamass-milter
To any of you running SpamAssassin 2.60+ with SendMail and spamass-milter
0.2.0 I am curious as to whether the -notfirsthop rules (such as Dynablock)
are working correctly for you. (I'm aware of its move to SORBS) When
SpamAssassin processes email through spamass-milter it's rarely matching
Dynablock and sometimes even falsely matches it. If I take the same email
after it's reached my server and process it manually with SpamAssassin
(spamassassin -D -t < email.txt) then it correctly matches Dynablock. Since
the incoming email is passed to the milter prior to SendMail adding its
Received: headers (to my knowledge), spamass-milter 0.2.0 constructs a
Received: header itself to pass to SpamAssassin so that SpamAssassin can
take the information into consideration. This header is only used by
SpamAssassin as spamass-milter does not send this header back to Sendmail.
Sendmail continues to add its own header as it normally does. I've scoured
the regex code that parses the Received: headers and the specific header
that spamass-milter inserts does appear to match one of the regexes so that
the pertinent information can be parsed.
Here's a sample header of an email that got through. Names and IPs have
been changed somewhat to protect the innocent:
Received: from me (my.cable.address.comcast.net [68.46.27.0])
by spamfilter.mydomain.com (8.12.8/8.12.8) with SMTP id
hBCKiXws021742
for [EMAIL PROTECTED]; Fri, 12 Dec 2003 15:44:45 -0500
Date: Fri, 12 Dec 2003 15:44:33 -0500
From: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
X-Spam-Status: No, hits=-1.0 required=5.0 tests=BAYES_00,DATE_MISSING,
FROM_NO_LOWER autolearn=no version=2.61
X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
spamfilter.mydomain.com
$ host 0.27.46.68.dnsbl.sorbs.net.
0.27.46.68.dnsbl.sorbs.net has address 127.0.0.10
"spamfilter.mydomain.com" resolves to a global IP address, not a private
(reserved) one.
I posted this problem to the list a month or two ago looking for solutions
and despite the responses I did not find anything that solves this problem.
I'm interested now in seeing whether other people are experiencing this
problem (spamassassin called through a milter not working while working when
called other ways). Since Dynablock works correctly when the final email is
processed manually yet does not work when the email is passed through the
milter (and the pseudo Received: header added) I still suspect the problem
may be with parsing spamass-milter's psuedo header, but I've been unable to
determine for sure after looking at SpamAssassin's header parsing code.
All feedback is appreciated.
Thanks.
Brian
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
