You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Matt Kettler <mk...@comcast.net> on 2005/12/05 04:27:40 UTC

Re: Added ISP as relayhost, now mail is coming in with FORGED_RCVD_HELO

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.


Re: Added ISP as relayhost, now mail is coming in with FORGED_RCVD_HELO

Posted by Matt Kettler <mk...@comcast.net>.
At 01:05 AM 12/5/2005, Chad wrote:
>On 12/4/05, Matt Kettler <mk...@comcast.net> 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?)



Re: Added ISP as relayhost, now mail is coming in with FORGED_RCVD_HELO

Posted by Chad <ma...@gmail.com>.
On 12/4/05, Matt Kettler <mk...@comcast.net> 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.  My AWL dropped the
score so my messages aren't marked as Spam, but nonetheless, it
bothered me to see that I was getting that check.  So I figured I
didn't understand what was happening (which I do now, thanks :) ). 
I'm just getting my hands dirty learning some things about using
SpamAssassin, guess there's quite a bit more for me to know :-)

Chad