Hopefully something here will be useful

spamass-milter 0.2.0

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.

This problem was fixed in spamass-milter HEAD and should also be fixed in spamass-milter 0.3.0 which was released in February 2005.

Posted 5 years, 3 months ago on May 15, 2005
The trackback url for this post is http://www.colynx.com/~bsneddon/blog/bblog/trackback.php/5/

---