You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Chad <ma...@gmail.com> on 2005/12/05 03:19:04 UTC
Added ISP as relayhost, now mail is coming in with FORGED_RCVD_HELO
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.
Any explaination is very appreciated.
Not sure if this is necessary, but here's some info:
Just a 'regular user' so I'm assigned dynamic IP's in the residential range
ISP is comcast, and my relayhost is set to relayhost = smtp.comcast.net
I send email to a mail list, that in turn, sends the email to me, and
this is where I see this info. As a complication to add to all of the
above, the mail list server is my backup mx server.
Thanks!
Chad
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
Re: Added ISP as relayhost, now mail is coming in with
FORGED_RCVD_HELO
Posted by Matt Kettler <mk...@comcast.net>.
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.