Re: Reporting My own IP?

Mike Easter wrote:
> The Father Mind of DM Industries wrote:
>> No No we are not through this yet.
>> I managed to forward about 10+ before another one showed up.
> www.spamcop.net/sc?id=z742897644ze824e48550385cd9de71b82dfacb0d87z

> The parser is screwing up.  It is accepting a line and then tripping
> and jumping 'backwards' and upwards past the line it has already
> accepted.

> 201.26.32.157 is not an MX for mx3.charta2N.ca
>
> <ME: this is where SC is supposed to be finishing the analysis of the
> relationship or rather the non-relationship between 201.26.32.157 and
> mx3.charta2N.ca in the 'by' field and breaking the chain between line
> 2 and line 3 and deciding that 201.26.32.157 is, in fact the
> spamsource, but NO.... SC makes a crazy decision....>
>
> Looks like a forgery
> 201.26.32.157 discarded as a forgery, using 64.81.88.120
> Tracking message source: 64.81.88.120:
>
> <ME: that step of unaccepting the previously accepted line 2 doesn't
> make any sense to me, and gives the wrong result>

The parser is getting this right now, I'm beginning to think that SC
isn't 'competent' to name an IP as a source unless it is listed in a
proxy db or something.:

I hate to paste all of this verbose logic, but it is different from
before:

<snip>
Received:  from 201-26-32-157.dsl.telesp.net.br
(201-26-32-157.dsl.telesp.net.br [201.26.32.157]) by
server-03.dmindustries.net (Postfix) with SMTP id 500211445B for <x>;
Wed, 16 Mar 2005 15:36:35 -0800 (PST)
201.26.32.157 found
host 201.26.32.157 (getting name) = 201-26-32-157.dsl.telesp.net.br.
201-26-32-157.dsl.telesp.net.br is 201.26.32.157
64.81.88.120 not listed in dnsbl.njabl.org
64.81.88.120 not listed in cbl.abuseat.org
64.81.88.120 not listed in dnsbl.sorbs.net
64.81.88.120 is not an MX for babcomm.totalsystemcontrol.com
64.81.88.120 is an MX for server-03.dmindustries.net
Possible spammer: 201.26.32.157
201.26.32.157 is not an MX for 201-26-32-157.dsl.telesp.net.br
host 201-26-32-157.dsl.telesp.net.br (checking ip) = 201.26.32.157
host server-03.dmindustries.net (checking ip) = 64.81.88.120
64.81.88.120 not listed in dnsbl.njabl.org
64.81.88.120 not listed in cbl.abuseat.org
64.81.88.120 not listed in dnsbl.sorbs.net
   Chain test:server-03.dmindustries.net =? server-03.dmindustries.net
   server-03.dmindustries.net and server-03.dmindustries.net have same
hostname - chain verified
Possible relay: 64.81.88.120
64.81.88.120 not listed in relays.ordb.org.
64.81.88.120 has already been sent to relay testers
Received line accepted

<ME: that section starts with 'showing' the 2nd line, the sourceline and
shows that SC is going to start considering the 'from' 201.26.32.157 as
the spamsource.  It wants to finish thinking about the previous 1st line
which it accepted which temporarily made 64.81.88.120 the source,
because it matters if that IP is a proxy or something.  Then it goes on
to decide that it is going to accept this 2nd line -- which means that
64.81.88.120 isn't the source anymore.  Now, 201.26.32.157 has become
the new source and SC is going to check the next line [and think about
201 some more]>

Received:  from ms-smtp-05.texas.rr.com ([24.93.47.44]) by
mx3.charta2N.ca (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14
2004)) with ESMTP id <[email protected]> for x (ORCPT x);
Wed, 16 Mar 2005 15:23:52 -0800
24.93.47.44 found
host 24.93.47.44 = ms-smtp-05.texas.rr.com (cached)
ms-smtp-05.texas.rr.com is 24.93.47.44
201.26.32.157 not listed in dnsbl.njabl.org
201.26.32.157 listed in cbl.abuseat.org ( 127.0.0.2 )
Open proxies untrusted as relays

<ME: now SC starts looking at the bogusline, and after that it starts to
think about the new apparent source 201.26.32.157 from the preceding
section and that's when it discovers that 201 is listed in the cbl.
That does it.  That breaks the chain.  It isn't going to chain from a
proxy to any kind of 'by' field, no matter if there's some kind of good
forgery in there.>

Tracking message source: 201.26.32.157:

<ME: now, SC names the 201 and goes from there>

So, if all parses were to behave like this one, we would say that SC
can't accurately name an IP as a source without jumping backwards for
some alleged 'forgery' if the IP isn't listed in one of the proxy db/s.
If the parser has 'degenerated' to that level of incompetency unless
there's a mailhost configuration, that would be very sad.  And I'm over
in nanae trying to defend it.


-- 
Mike Easter
kibitzer, not SC admin