Re: Reporting My own IP?

cbl.abuseat.org
is on my list of filters.
So that IP would have had to be added to it recently and this would explain
why the logic changed.
Otherwise cbl.abuseat.org  should have stopped the spam from getting
through.

"Mike Easter" <[email protected]> wrote in message
news:[email protected]...
> 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
>