http://bugzilla.spamassassin.org/show_bug.cgi?id=3123
Summary: domain name with '-c' in it messes up spamc and writing
headers
Product: Spamassassin
Version: 2.61
Platform: Other
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P5
Component: spamc/spamd
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
details from associate whoc discovered this:
In the spamassassin subroutine there are several places that test
$spamc_options for a '-c' option. If the option is set, spamc just checks
the mail for spam, adding the X-Spam headers but not rewriting the
message. We are not using the '-c' option. However, the way the test is
done is flawed for certain domains. Here's the most relevant section of
code:
1. $spamc_options="$spamc_options -u \"$cmdline_recip\"" if
($cmdline_recip ne "");
2. &debug("SA: run $spamc_binary $spamc_options <
$scandir/$wmaildir/new/$file_id");
3. open(SA,"$spamc_binary $spamc_options \
< $scandir/$wmaildir/new/$file_id|")||&error_condition("cannot run
$spamc_binary \
< $scandir/$wmaildir/new/$file_id - $!");
4. open(SOUT,">$scandir/$wmaildir/new/$file_id.spamc") \
||&error_condition("cannot open for write
$scandir/$wmaildir/new/$file_id.spamc - $!");
5. while (<SA>) {
6. if (!$sa_tag) {
7. if ($spamc_options =~ /\-c/) {
8. chomp;
9. ($sa_score,$sa_max)=split(/\//,$_,2);
10. $sa_tag++;
11. } else {
12. #X-Spam-Status: No, hits=2.8 required=5.0
13. if (/^X-Spam-Status: (Yes|No), hits=(-?[\d\.]*)
required=([\d\.]*)/) {
14. $sa_tag++;
15. $sa_status=1 if ($1 eq "Yes");
16. $sa_score=$2;$sa_max=$3;
17. }
18. }
19. }
20. print SOUT;
21. }
In line 1, the program adds a '-u' option, followed by the recipient's
email address, to the $spamc_options variable.
In line 7, and in later lines of the same subroutine, it tests
$spamc_options for the presence of the '-c' option.
This is where the problem comes in. For our domain, c-cap.com, the
recipient's email address is now satisfying the '-c' test because it's
part of the $spamc_options. Any domain with a "-c" in it would cause the
same problem - essentially, telling this subroutine that spamc is not
rewriting the message when it really is (and also messing up $sa_max,
which is why we were seeing the funky "X-Spam-Status: No, hits=Received:
from localhost [127.0.0.1] by webfree.nxsbg.com required=?" header.)
I've put a bandaid on this by inserting a space after the '-c' test in
each case. This isn't a good fix, though; if $spamc_options is set to, for
instance, "-c" (with no trailing space) and for some reason there doesn't
seem to be a $cmdline_recip, it will fail the test in the other direction.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
