Bug 1073 - RCVD_IN_OSIRUSOFT_COM (127.0.0.3) incorrectly triggers on origination host
Summary: RCVD_IN_OSIRUSOFT_COM (127.0.0.3) incorrectly triggers on origination host
Status: RESOLVED DUPLICATE of bug 1153
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 2.41
Hardware: Other other
: P2 normal
Target Milestone: ---
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-07 07:11 UTC by Ken Causey
Modified: 2002-10-30 04:28 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Causey 2002-10-07 07:11:10 UTC
The relays.osirusoft.com 127.0.0.3 response is a match against
dialup.relays.osirusoft.com which is a database of known dialup IP addresses. 
This database is to be used to detect relaying against unlikely SMTP hosts. 
However, the rule RCVD_IN_OSIRUSOFT_COM is triggering against the origination
received header for the 127.0.0.3 response which is completely incorrect as this
should PROPERLY be an entry in dialup.relays.osirusoft.com as it would logically
be a dialup and is not in fact relaying the email but originating it.

I previously reported this in bug 268
http://bugzilla.spamassassin.org/show_bug.cgi?id=268 and claims to have been
fixed as part of bug 399 which was closed as of 2.30.  However I'm continuing to
see this problem with 2.41.

Ken Causey
Comment 1 Justin Mason 2002-10-30 03:21:56 UTC
I'm mystified.  the system *is* listed in relays.osirusoft.com --  but solely as
a dialup IP.  SA gives it 0.4 points for that.  If it was listed as an open
relay, it'd get lots more points, but it doesn't.  if it got a hit for a dialup
IP in some REceived line other than the first one, the points would be a lot
higher, but it doesn't.

Finally, the test message from that old bug scores -2 points under CVS in total,
so it is NOT marked as spam anyway.

where's the problem?

In this setup, being sent from a dialup IP (even if it's originating there) is
worth 0.4 points -- same as using BCC is worth a fraction of a point, or not
using a real name in the From line is worth a fraction of a point.  As long as
the points don't go over 5, there is no problem.  That's how SA works. it's a
heuristic!

Comment 2 Ken Causey 2002-10-30 09:11:02 UTC
Why should someone sending email from a dialup IP address be worth ANY points? 
This is totally appropriate and good behaviour.  The only effect I can see from
this is discouraging ISPs from adding their dialups to dialup.relays.osirusoft.com.

Why should someone's nasty HTML email which ends up with a 4.7 score because
they had too much fun playing with HTML font colors and sending their friend a
tasteless joke be pushed over the edge because they are sending email from their
home computer over POTS lines?

Let me note that I'm reporting this bug not because of any specific message but
because of a history of observations that I have made.
Comment 3 Daniel Quinlan 2002-10-30 13:28:42 UTC
> Why should someone sending email from a dialup IP address be worth ANY
> points?  This is totally appropriate and good behaviour.  The only effect I
> can see from this is discouraging ISPs from adding their dialups to
> dialup.relays.osirusoft.com.
>
> Why should someone's nasty HTML email which ends up with a 4.7 score because
> they had too much fun playing with HTML font colors and sending their friend
> a tasteless joke be pushed over the edge because they are sending email from
> their home computer over POTS lines?

For the same reason it would be pushed over the edge if they set their clock
in 4 days into the future -- it looks like spam.  Spammers tend to use dial-up
lines often enough that dial-up lines get a positive score.

> Let me note that I'm reporting this bug not because of any specific message
> but because of a history of observations that I have made.

The scores for the rules, including RCVD_IN_OSIRUSOFT_COM, is the result of
a genetic algorithm that attempts to find the optimal score to catch most
spam balanced against the goal mistaking non-spam for spam.  It is not
perfect, but it is much better than any of us humans.

The fix located in bug 268 was unmaintainable and was used prior to scoring
the RBL rules with the GA.  Once the RBL rules were GA-scored, fixing the
then-broken RBL code (to repair the already-broken code from bug 268) was
not necessary.

The right solution for incrementally improving the RBL code is located in bug
1153, therefore, I am marking this bug as a duplicate for it.



*** This bug has been marked as a duplicate of 1153 ***