Re: Reporting My own IP?

201.26.32.157 discarded as a forgery, using 64.81.88.120
Tracking message source: 64.81.88.120:

yea I saw this line and when I was reviewing the tech details (what I
understood of it) made no sense.  Okay so now that we have more or less
established there is a problem with the parser, what now?

"Mike Easter" <[email protected]> wrote in message
news:[email protected]...
> 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
> >
> > Tell me what I did wrong here please.  :)
> > I looked at it and I am not sure.
>
> There's nothing you are doing wrong.
>
> 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.
>
>   Abbreviated Received lines *comment
>   from server-03.dmindustries.net (server-03.dmindustries.net
> [64.81.88.120]) by babcomm.totalsystemcontrol.com *serves recipient
>   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 *sourceline
>   from ms-smtp-05.texas.rr.com ([24.93.47.44]) by mx3.charta2N.ca
> *bogusline
>   from cpe-065-188-010-077.sc.rr.com ([81.243.148.86]) by
> sc004pub.verizon.net ([206.46.170.180]) *bogusline
>
> If we 'number' the lines above 1-4 top to bottom, the parse proceeds
> downward from 1 to 2, 2 to 3, etc. as a chain from above 'from' to below
> 'by'.  The verbose of the parse 'mixes up' the process which it is
> describing;  that is, it starts talking about the parsing of the next
> line down before it has completely digested the veracity of the line
> above.  That is normal procedure.
>
> What is going wrong here is after SC accepts line 1 and works on line 2,
> SC accepts line 2 and starts working on line 3.  In this case described
> below in more detail which I've annotated <ME: like this>, it accepts
> line 2 and starts working on line 3.  While it is working on line 3, it
> inexplicably 'goes back' and decides to say something is a forgery
> [which is always useless information, totally non-informative] and
> apparently 'unaccepts' line 2, which I don't understand.
>
> <snip>
> Parsing header:
>
> Received:  from server-03.dmindustries.net (server-03.dmindustries.net
> [64.81.88.120]) by babcomm.totalsystemcontrol.com (Postfix) with ESMTP
> id 7F59B147C7 for <x>; Wed, 16 Mar 2005 15:16:33 -0800 (PST)
> 64.81.88.120 found
> host 64.81.88.120 = server-03.dmindustries.net (cached)
> server-03.dmindustries.net is 64.81.88.120
> Possible spammer: 64.81.88.120
> 64.81.88.120 is an MX for server-03.dmindustries.net
> 64.81.88.120 is mx
> Received line accepted
>
> <ME: that 'accepted' is an important step, at this point 64.81.88.120 is
> a spamsource until the chain goes further back>
>
> Received:  by server-03.dmindustries.net (Postfix) id 253151448A; Wed,
> 16 Mar 2005 15:36:51 -0800 (PST)
> no from
>
> Ignored
>
> <ME: that isn't a Received: from line>
>
> 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 = 201-26-32-157.dsl.telesp.net.br. (cached)
> 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 accepted is an important step.  64.81.88.120 is no longer the
> spamsource;  now 201.26.32.157 is the spamsource until the chain goes
> further back;  next we are working on the 3rd line>
>
> 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 not listed in cbl.abuseat.org
> 201.26.32.157 not listed in dnsbl.sorbs.net
> 201.26.32.157 is not an MX for server-03.dmindustries.net
> 201.26.32.157 is not an MX for 201-26-32-157.dsl.telesp.net.br.
> 201.26.32.157 is not an MX for mx3.charta2N.ca
> 201.26.32.157 is not an MX for server-03.dmindustries.net
> 201.26.32.157 not listed in dnsbl.njabl.org
> Possible spammer: 24.93.47.44
> host mx3.charta2N.ca (checking ip) ip not found ; mx3.charta2N.ca
> discarded as fake.
> 24.93.47.44 is not an MX for mx3.charta2N.ca
> 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>
>
> I've been discussing this in a different thread in a different newsgroup
> over in spamcop.
>
> A previous tracker you posted which parsed incorrectly was parsing
> correctly and we discussed that improvement over there.  The business
> about the caps problem appeared to be corrected by the parser algorithm,
> besides the fact that you eliminated it.
>
> -- 
> Mike Easter
> kibitzer, not SC admin
>