At 01:05 AM 12/5/2005, Chad wrote:
On 12/4/05, Matt Kettler <[EMAIL PROTECTED]> wrote:
> At 09:19 PM 12/4/2005, Chad wrote:
> >Evenin!
> >
> >I have been reading on relays, and such. I am in a situation where a
> >user on my system sends mail to AOL, but AOL blocks email from dynamic
> >IP's (at least all of them I've ever used). So in order to get the
> >mail to the AOL user, I have setup my MTA (postfix) to relay email
> >through my ISP's mail server.
> >
> >So far so good, it seems anyway (it's not quite been a full day yet,
> >but things seem to be working fine). But, now in my email headers,
> >Spam Assassin is running the FORGED_RCVD_HELO against messages sent
> >from me. I'm AWL of course, but this is still confusing. I don't
> >understand what's happening I guess.
>
> First I'd have to ask.. why do you even care? This rule scores less than
> 0.2 points in SA 3.1.0.
>
> The rule is strictly informational, and all it means is that neither of the
> following is true:
> 1) HELO string didn't match the hostname of the PTR record (aka
> reverse DNS lookup) of the connecting IP.
> -and-
> 2) the A record look up of the HELO string did not match the
> connecting IP.
>
> In the SA 3.1.0 mass-checks this rule matched more nonspam than it matched
> spam. Nobody should take it as any serious indicator of spam.
>
>
I guess the biggest reason I care is that so far, for me, this was the
biggest indicator of Spam that I receive. I raised the default score
by +3 because it was so evident. I have, so far, got 0 false
positives based solely off me raising that score.
I can't imagine why you didn't have any FPs. The statistics for this rule
are outright HORRIBLE..
Next time check STATISTCS-*.txt to see how the rule really performed in the
mass-check tests.
From SA 3.0.x's STATISTICS-set3.txt
OVERALL% SPAM% HAM% S/O RANK SCORE NAME
24.580 19.4030 29.4878 0.397 0.34 0.00 FORGED_RCVD_HELO
And 3.1.0:
23.352 19.2045 33.0225 0.368 0.26 0.14 FORGED_RCVD_HELO
S/O is a really good number to look at for this. If you multiply by 100, it
tells you what percentage of the messages matching this rule were spam. So
in SA 3.0.0's run only 39.7% of the hits were spam and 60.3% were nonspam.
Ouch.
Technically speaking, the statistics of this rule are so bad it should have
been removed from SA. The general rule-of-thumb is any the S/O of spam rule
needs to be more than 0.8 and any ham rule less than 0.2.
My only guess is the devs are keeping this rule around because it is
statistically interesting to them, or contains code which is useful in some
other test (a meta test?)
