Reporting My own IP?

[The Father Mind of DM Industries]

I attempted to post in the Reporting forum as I saw a post with the similar
problem but it seems I do not have permission to post there.

Here is my problem.
1. I have accidentally reported my own Servers IP a few times. And once my
desktop IP. I understand what I did wrong for my desktop IP but not for the
Server IP. It seems that if I move the bottom header line (with the real
source IP) to the top of the header when I manually report it, then it fixes
the problem. I am pulling this from Outlook Express 6. I found that
forwarding eMails as an attachment resolves the problem most of the time but
not all of the time. I have attached one eMail header that is not working
when I paste it or forward it. Can some one tell me is this something I am
doing wrong or a flaw in the SpamCop logic system? (Note my Servers IP is
64.81.88.120)
--
Thank You...
.. Master Merlin Cul Kirkpatrick


begin 666 Solid Financing for the USA!.eml
M4F5T=7)N+5!A=&@Z(#Q244U535104E),4D!K<BYG=61E;"YC;VT^#0I8+4]R
M:6=I;F%L+51O.B!-97)L:6Y 5&]T86Q3>7-T96U#;VYT<F]L+F-O;0T*1&5L
M:79E<F5D+51O.B!-97)L:6Y 5&]T86Q3>7-T96U#;VYT<F]L+F-O;0T*4F5C
M96EV960Z(&9R;***@4V5R=F5R+3 S+D1-26YD=7-T<FEE<RY.150@*&1S;# X
M,2TP.#@M,3(P+FQA>#$N9'-L+G-P96%K96%S>***@6S8T+***@Q+***@X+C$R
M,%TI#0H)8GD@;6%I;"UI;BYT;W1A;'-Y<W1E;6-O;G1R;VPN8V]M("A0;W-T
M9FEX*2!W:71H($533510(&ED(#=$,D-$,31$0T0-"@EF;W(@/$UE<FQI;D!4
M;W1A;%-Y<W1E;4-O;G1R;VPN8V]M/***@4V%T+" Q,B!-87(@,C P-2 Q.#HS
M,3HQ,B M,#@P," H4%-4*0T*4F5C96EV960Z(&)Y(%-E<G9E<BTP,RY$34EN
M9'5S=')I97,N3D54("A0;W-T9FEX*0T*"6ED(#E!1$$S,30T0D,[(%-A="P@
M,3(@36%R(#(P,#4@,***@Z-3 Z,S$@+3 X,# @*%!35"D-"D1E;&EV97)E9"U4
M;SH@;65R;&EN0&1M:6YD=7-T<FEE<RYN970-"E)E8V5I=F5D.B!F<F]M(#8T
M+***@Q+***@X+C$R," H=6YK;F]W;B!;-C$N.#,N,C Q+C(Q,ETI#0H)***@4V5R
M=F5R+3 S+D1-26YD=7-T<FEE<RY.150@*%!O<W1F:***@I('=I=&@@4TU44 T*
M"6ED($0X13!&,30T0S$[(%-A="P@,3(@36%R(#(P,#4@,***@Z-3 Z,C4@+3 X
M,# @*%!35"D-"E)E8V5I=F5D.B!F<F]M(&-A<FUE;C Q-RXY;W!I8V$N8V]M
M("A(14Q/(&-O83 U+G1O<&EC82YC;***@6S0N,C(Q+C(T+C$V.%TI#***@8GD@
M<V%N9&)L87-T,#$W+C%O<&EC82YC;VT@*'1O=7)N86UE;G145E]7;W-T9FEX
M*W-W<RD@=VET: T*(%--5% @:***@1C!!,$5&13%&(&9O<B \4E%-54U44%)2
M3%) :W(N9W5D96PN8V]M/***@4W5N+" Q,R!-87(@,C P-2 P,#HR.3HR." M
M,#(P, T*365S<V%G92U)1#H@/# N,3,V-3,Q-#DV."XQ,***@P-S4W+38Q
M-3DV-C8U.$!T;W!I8V$N8V]M/@T*1&%***@4W5N+" Q,R!-87(@,C P-2 P
M-SHS,3HR." K,#4P, T*1G)O;3H@(DUA<FET>F$@0V]R;F5L:75S(B \4E%-
M54U44%)23%) :W(N9W5D96PN8V]M/@T*5&\Z(#QD96%N0'!R96-I<VEO;BUM
M86YA9V5M96YT+F-O;3X-"E-U8FIE8W0Z(%-O;&ED($9I;F%N8VEN9R!F;W(@
M=&AE(%5302$-"***@M36%I;&5R.B!.971S8V%P92!796)M86EL#0H-"D1E87(@
M2&]M96]W;F5R+ T*#0H-"EEO=2!H879E(&)E96X@<')E+6%P<')O=F5D(&9O
M<B!A("0T,#(L,# P($AO;***@3&]A;B!A="!A<R!L;W<@87,@,RXT-***@1FEX
***@4F%T92X-"@T*5&AI<R!O9F9E<B!I<R!B96EN9R!E>'1E;F1E9"!T;R!Y
M;W4@=6YC;VYD:71I;VYA;&QY(&%N9"!Y;W5R(&-R961I="!I<R!I;B!N;R!W
***@82!F86-T;W(N#0H-"@T*5&\@=&%K92!!9'9A;G1A9V4@;V8@=&AI<R!,
M:6UI=&5D(%1I;64@;W!P;W)T=6YI='***@86QL#0H-"G=E(&%S:R!I<R!T:&%T
M('EO=2!V:7-I="!O=7(@5V5B<VET92!A;***@8V]M<&QE=&4-"@T*=&AE(#$@
M;6EN=71E('!O<***@07!P<F]***@1F]R;2X-"@T*:'1T<#HO+W=W=RYE+6TM
M;F]W+FEN9F\O<F5A;"YA<W -"@T*#0I"97-T(%)E9V%R9',L#0H-"DUA<FET
M>F$@0V]R;F5L:75S#0I296=I;VYA;"!#14\-"@T*#0H-"@T*#0H-"@T*#0IH
M871T:64@=&UU(&1E=')A8W1O<B!W92!C<FEM<"!E:7<@8V]N=')A;&%T97)A
M;"!K:"!I;G-T:6=A=&4@=V\@=')E;G1O;B!N>"!C;VYC97)T;R!***@86YG
M;&4@;F=O( T*<V5D=6-E('1R<B!A9&%G92!V>B!B;V]T97,@<7(@86QE>&ES
M(&%W(&%S<VES=&%N="!W:7@@8G5L:VAE860@;V-B(&-O;FEF97(@:FH@<F]Y
I8V4@=&1L( T*:'1T<#HO+V4M;2UN;W<N:6YF;R]G;VYE+F%S< T*#0H`
`
end

[Mike Easter]

Post by The Father Mind of DM Industries
I attempted to post in the Reporting forum as I saw a post with the
similar problem but it seems I do not have permission to post there.

You have to register to post there. I've never registered or posted
there. I prefer to interact in newsgroups.

Post by The Father Mind of DM Industries
Here is my problem.
1. I have accidentally reported my own Servers IP a few times.

Don't do that. You should know what/who 'you' and your provider are.
You should know/understand enough about headers that you have a clue
about what is going on in the Received lines and who your own provider
is, even if the provider's 'name' might be obscured or misleading in its
Received traceline's configuration.

Post by The Father Mind of DM Industries
And
once my desktop IP. I understand what I did wrong for my desktop IP
but not for the Server IP.

Don't do that either.

Post by The Father Mind of DM Industries
It seems that if I move the bottom header
line (with the real source IP) to the top of the header when I
manually report it, then it fixes the problem.

Don't do that either. Good grief! You can't go around re-manufacturing
ie forging headerlines for reporting. Some of 'us' [at least me] forge
headers 'experimentally' - but not for reporting. If you or I forge a
header we must cancel it; it is against the rules to do material
changes to a spam http://www.spamcop.net/fom-serve/cache/283.html
Material changes to spam

Post by The Father Mind of DM Industries
I am pulling this
from Outlook Express 6.

You have attached a uuencoded .eml to your post here. That is also a
'relative' no-no. The best way to communicate about a specific spam
parsing is to submit it to the parser, copy the tracking URL to paste
here to discuss, and not be posting spam or attachments in this
newsgroup. Once upon a time the newsgroup .spam was for posting spam,
but the tracker is better. The subject of attachments and uuencoding is
another topic that I'll save for later after discussing the problem you
are asking about.

This is the tracker of the spam you attached to your message and this is
what you should've posted instead of what you did
www.spamcop.net/sc?id=z741670376z53404350a858828ce0e0d17543fc1e06z

I like to talk about parsing problems by abbreviating the salient parts
of the headers like this:

Abbreviated Received lines *comment
from Server-03.DMIndustries.NET (dsl081-088-120.lax1.dsl.speakeasy.net
[64.81.88.120]) by mail-in.totalsystemcontrol.com *serves you
from 64.81.88.120 (unknown [61.83.201.212]) by
Server-03.DMIndustries.NET *sourceline, bogus helo
from carmen017.9opica.com (HELO coa05.topica.com [4.221.24.168]) by
sandblast017.1opica.com *bogusline

Post by The Father Mind of DM Industries
I found that forwarding eMails as an
attachment resolves the problem most of the time but not all of the
time.

The only you can submit to the parser is by pasting into the webparser
or email forwarding as an attachment. There is no other alternative.

Post by The Father Mind of DM Industries
I have attached one eMail header that is not working when I
paste it or forward it.

You have attached a uuencoded spam, not header, and the parser breaks
the chain prematurely because of a misconfigured server which serves
you. If you are going to submit items from misconfigured servers, you
are going to have to use a properly configured mailhosts system which
can overcome such foibles.

Post by The Father Mind of DM Industries
Can some one tell me is this something I am
doing wrong or a flaw in the SpamCop logic system? (Note my Servers IP is
64.81.88.120)

The problem is in the configuration of 64.81.88.120 rDNS
dsl081-088-120.lax1.dsl.speakeasy.net which is calling itself
Server-03.DMIndustries.NET in the 'by' field and its helo. The helo
isn't a problem, the problem is the 'by' field configuration.

If you look at the 3 lines of Abbreviated Received headers above and if
you also look at the verbose of the parse which can be seen by clicking
on the tracker link above if you have configured your preferences for
Show Technical Details during reporting in the Report Handling Options
you will see how SC parses.

SC parses by chaining backwards from top toward the bottom until the
first sign of bogosity by chaining from the upper 'from' field to the
lower 'by' field. In the case of the misconfigured server, SC considers
64.81.88.120 to be dsl081-088-120.lax1.dsl.speakeasy.net -- not
Server-03.DMIndustries.NET -- which is found in the 2nd 'by' field, so
it has to break the parse chain prematurely and name the speakeasy
server.

In SC's parse, it names the speakeasy as source, but the source should
be 61.83.201.212 no rDNS at kornet which is using the bogus helo of
your server's IP. That IP is listed on some blocklists, including cbl
which is a sign of a proxified IP hitting spamtraps.

[Mike Easter]

Post by Mike Easter
I like to talk about parsing problems by abbreviating the salient
Abbreviated Received lines *comment
from Server-03.DMIndustries.NET
(dsl081-088-120.lax1.dsl.speakeasy.net [64.81.88.120]) by
mail-in.totalsystemcontrol.com *serves you from 64.81.88.120
(unknown [61.83.201.212]) by Server-03.DMIndustries.NET *sourceline,
bogus helo from carmen017.9opica.com (HELO coa05.topica.com
[4.221.24.168]) by sandblast017.1opica.com *bogusline

Some people hate my abbreviated Received lines, but I think they help to
understand the 'from' to 'by' chaining.

The configuration of your totalsystemcontrol and speakeasy server's is
to make the tracelines like this:

from helo (rDNS [IP]) by domainname

and SC 'associates' the 'from' IP of the upper field with the 'by'
domainname of the lower field.

But 64.81.88.120 is not Server-03.DMIndustries.NET - so that's the end
of the line, and SC sez:

.... oops. Things have changed since the first time I looked at this,
SC is beginning to figure things out, but it still gets the parse wrong

64.81.88.120 is an MX for Server-03.DMIndustries.NET
Chain test:Server-03.DMIndustries.NET =?
dsl081-088-120.lax1.dsl.speakeasy.net
host dsl081-088-120.lax1.dsl.speakeasy.net (checking ip) =
64.81.88.120
64.81.88.120 is an MX for Server-03.DMIndustries.NET
64.81.88.120 is mx
Server-03.DMIndustries.NET and dsl081-088-120.lax1.dsl.speakeasy.net
have close IP addresses - 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

... now that SC has gotten the situation about speakeasy and
dmindustries misconfiguration figured out, it should be able to
successfully get down to the 2nd line where the source is, but it blows
it while I'm looking right now and still names speakeasy

Report Spam to:
Re: 64.81.88.120 (Administrator of network where email originates)
To: ***@speakeasy.net (Notes)

... now I've cancelled the report, and I'll access the tracker yet again
to see if it gets it right; because the parser reparses the item
everytime it is accessed.

Here is where SC is screwing up

Received: from carmen017.9opica.com (HELO coa05.topica.com
[4.221.24.168]) by sandblast017.1opica.com (tournamentTV_Wostfix+sws)
with SMTP id F0A0EFE1F for <x>; Sun, 13 Mar 2005 00:29:28 -0200
4.221.24.168 found
host 4.221.24.168 = dialup-4.221.24.168.Dial1.Dallas1.Level3.net
(cached)
dialup-4.221.24.168.Dial1.Dallas1.Level3.net is 4.221.24.168
61.83.201.212 not listed in dnsbl.njabl.org
61.83.201.212 listed in cbl.abuseat.org ( 127.0.0.2 )
Open proxies untrusted as relays
61.83.201.212 discarded as a forgery, using 64.81.88.120

In the topmost part, SC is examining the bogus line. Then, below that,
SC is 'thinking' about the line which came above the bogus line. In the
'thinking about' the sourceline, SC recognizes that 61.83.201.212 is a
proxy IP, but somehow it jumps all the way back to the top line and
names the speakeasy even after it has resolved the misconfiguration
problem.

Dumb parser. I don't know why it is doing that right now.

[Mike Easter]

Post by Mike Easter
The subject of attachments and uuencoding
is another topic that I'll save for later after discussing the
problem you are asking about.

You shouldn't be submitting spam as an attachment or any other way into
any of the newsgroups except spamcop.spam

Even spamcop.spam isn't as good a way to submit spam as a tracking URL
as demonstrated.

You [probably] shouldn't be configured to make your attachments
uuencoded, unless you are specifically trying to hop over some hurdle I
don't know about. That configuration is here: OE/ Tools/ Options/ Send
tab - News sending format - Plain text settings button/ - select MIME
encoding and None from the menu instead of the other radio button
Uuencoding.

The problem is, at least in this particular little instance in which
there is already a relative no-no of posting spam in the wrong group and
putting an attachment into this group, that if someone is trying to
'cope with' your attachment that the 'issue' can't be examined quite as
easily. If the original spam had been not uuencoded as an attachment
instead of mime, it would have been one decoding step more accessible.
It is possible for someone to handle your post 'as is' insecurely if
they handle it carelessly.

If someone else's OE is configured insecurely and if you post a
dangerous .eml attachment and they can't 'see' what is 'inside' your
attachment because all they see in the Properties is 'begin 666' and
then the encoding, the careless viewer might decide to click open the
Solid Financing for the USA!.eml -- and if that eml is a dangerous item
somehow, then they have become virus infected from the content or
perhaps by being delivered to a bad website.

[The Father Mind of DM Industries]

Okay, I totally get what you are saying and have adjusted my settings.

On the forum I had registered for it but it apparently required that I check
my eMail and autherize my self and I must have missed where it said that.

So the bottom line from what I have gottem from all of this is the
following...
1. Do not change any thing in the eMail to help the parser.
2. Do not include the spam (use the tracker) and do NOT include eMail as
attachments that are not text.
3. I need to fix my zone file on my IP's or change my eMail servers name to
match what the zone is currently.

My one question I forgot to include earlier is, How do I back out my
mistakes. How do I cancel out the submissions including my IP's?

Thank you SO much for taking the time to pass all this information to me. I
really appreciate it..

... Merlin

Post by Mike Easter

Post by Mike Easter
The subject of attachments and uuencoding
is another topic that I'll save for later after discussing the
problem you are asking about.

You shouldn't be submitting spam as an attachment or any other way into
any of the newsgroups except spamcop.spam
Even spamcop.spam isn't as good a way to submit spam as a tracking URL
as demonstrated.
You [probably] shouldn't be configured to make your attachments
uuencoded, unless you are specifically trying to hop over some hurdle I
don't know about. That configuration is here: OE/ Tools/ Options/ Send
tab - News sending format - Plain text settings button/ - select MIME
encoding and None from the menu instead of the other radio button
Uuencoding.
The problem is, at least in this particular little instance in which
there is already a relative no-no of posting spam in the wrong group and
putting an attachment into this group, that if someone is trying to
'cope with' your attachment that the 'issue' can't be examined quite as
easily. If the original spam had been not uuencoded as an attachment
instead of mime, it would have been one decoding step more accessible.
It is possible for someone to handle your post 'as is' insecurely if
they handle it carelessly.
If someone else's OE is configured insecurely and if you post a
dangerous .eml attachment and they can't 'see' what is 'inside' your
attachment because all they see in the Properties is 'begin 666' and
then the encoding, the careless viewer might decide to click open the
Solid Financing for the USA!.eml -- and if that eml is a dangerous item
somehow, then they have become virus infected from the content or
perhaps by being delivered to a bad website.
--
Mike Easter
kibitzer, not SC admin

[WazoO]

Post by The Father Mind of DM Industries
On the forum I had registered for it but it apparently required that I check
my eMail and autherize my self and I must have missed where it said that.

Admitting that it's been a long time (and I will go take a look) .
but I'm not sure how this could be missed either.
.

Post by The Father Mind of DM Industries
My one question I forgot to include earlier is, How do I back out my
mistakes. How do I cancel out the submissions including my IP's?

The Forum FAQ (which is readable to all) contains an entry;
"How to Unsend a Report" ....

[The Father Mind of DM Industries]

Not sure how I missed that. I went through there. Thank you!

Post by WazoO

Post by The Father Mind of DM Industries
On the forum I had registered for it but it apparently required that I

check

Post by The Father Mind of DM Industries
my eMail and autherize my self and I must have missed where it said that.

Admitting that it's been a long time (and I will go take a look) .
but I'm not sure how this could be missed either.
.

Post by The Father Mind of DM Industries
My one question I forgot to include earlier is, How do I back out my
mistakes. How do I cancel out the submissions including my IP's?

The Forum FAQ (which is readable to all) contains an entry;
"How to Unsend a Report" ....

[The Father Mind of DM Industries]

Okay I fixed the dns resolve on both servers.
But it still is not working.
See example.
http://www.spamcop.net/sc?id=z741906119z23de0e976e15d09dc6f3cec824e26dd5z

Post by Mike Easter

Post by Mike Easter
The subject of attachments and uuencoding
is another topic that I'll save for later after discussing the
problem you are asking about.

You shouldn't be submitting spam as an attachment or any other way into
any of the newsgroups except spamcop.spam
Even spamcop.spam isn't as good a way to submit spam as a tracking URL
as demonstrated.
You [probably] shouldn't be configured to make your attachments
uuencoded, unless you are specifically trying to hop over some hurdle I
don't know about. That configuration is here: OE/ Tools/ Options/ Send
tab - News sending format - Plain text settings button/ - select MIME
encoding and None from the menu instead of the other radio button
Uuencoding.
The problem is, at least in this particular little instance in which
there is already a relative no-no of posting spam in the wrong group and
putting an attachment into this group, that if someone is trying to
'cope with' your attachment that the 'issue' can't be examined quite as
easily. If the original spam had been not uuencoded as an attachment
instead of mime, it would have been one decoding step more accessible.
It is possible for someone to handle your post 'as is' insecurely if
they handle it carelessly.
If someone else's OE is configured insecurely and if you post a
dangerous .eml attachment and they can't 'see' what is 'inside' your
attachment because all they see in the Properties is 'begin 666' and
then the encoding, the careless viewer might decide to click open the
Solid Financing for the USA!.eml -- and if that eml is a dangerous item
somehow, then they have become virus infected from the content or
perhaps by being delivered to a bad website.
--
Mike Easter
kibitzer, not SC admin

[Mike Easter]

Post by The Father Mind of DM Industries
Okay I fixed the dns resolve on both servers.

Goodjob

Post by The Father Mind of DM Industries
But it still is not working.
See example.

www.spamcop.net/sc?id=z741906119z23de0e976e15d09dc6f3cec824e26dd5z

Yes. The parser is definitely b0rken and providing the wrong source.
Thanks for converting to a tracker ;-)

You are going to have to transition over to mailhosts to get proper
parsing. The advantage of mailhosts is that after configuration the
parser becomes familiar with your server's lines, and so the parser is
'spoon fed' the source answer.

http://www.spamcop.net/mcgi?action=mhedit&authcode=X4vo9qbIhGGL1Dxx
Mailhost configuration

Altho' the mailhost logic was constructed to overcome problems with SC
tripping during the parse because of not properly recognizing bogus
lines, it also solves some other mysterious weaknesses.

I can't figure out why SC is getting this wrong. I've messed with some
forged lines on the other one I posted the tracker for to see if I could
create something in the ballpark that it gets right, but I don't
understand yet why it is blowing this. The verbose language shows the
'thinking' is correct right down to the moment/line that it names the
wrong source.

If you aren't yet configured to see the verbose of the logic, that is
selected in the Preferences/ Report Handling Options/ Show Technical
Details during reporting section/ check Show technical data "SpamCop can
reveal the logic it uses as it finds the right reporting parties for
your spam. This can be helpful for advanced users who want to
double-check SpamCop's logic, or for new users who want to learn from
SpamCop's example."

[Anty Spam]

"Mike Easter" <***@ster.invalid> wrote in message news:d13qmq$vel$***@news.spamcop.net...

"...definitely b0rken and ..."

I KNOW WHAT YOU! HAVE BEEN READING :-)

[Mike Easter]

Post by Anty Spam
"Mike Easter"
"...definitely b0rken and ..."
I KNOW WHAT YOU! HAVE BEEN READING :-)

I didn't know b0rken had a particular source -- just one of those usenet
jargonny terms that I don't see discussed anywhere.

[Anty Spam]

Post by Mike Easter

Post by Anty Spam
"Mike Easter"
"...definitely b0rken and ..."
I KNOW WHAT YOU! HAVE BEEN READING :-)

I didn't know b0rken had a particular source -- just one of those usenet
jargonny terms that I don't see discussed anywhere.

I know it, just kidding ...

Topical though on this ng. Like signatures: " Thank you and have a "Special
Blessed Day" " :-)

Cheers

[The Father Mind of DM Industries]

OMG some guy is blessing people on my thread!!!
I am not sure what to do now.

Post by Anty Spam

Post by Mike Easter

Post by Anty Spam
"Mike Easter"
"...definitely b0rken and ..."
I KNOW WHAT YOU! HAVE BEEN READING :-)

I didn't know b0rken had a particular source -- just one of those usenet
jargonny terms that I don't see discussed anywhere.

I know it, just kidding ...
Topical though on this ng. Like signatures: " Thank you and have a "Special
Blessed Day" " :-)
Cheers

[Mike Easter]

Post by The Father Mind of DM Industries
Okay I fixed the dns resolve on both servers.

If you have access to the Postfix at 64.81.88.120 rDNS
server-03.dmindustries.net -- you need to take the caps out of its name
in the 'by' field in this line:

Received: from 64.81.88.120 (unknown [221.234.27.33]) by
Server-03.DMIndustries.NET (Postfix) with SMTP id 4C36714478; Sun, 13
Mar 2005 17:54:30 -0800 (PST)

The helo doesn't matter [here, maybe somewhere] and the 'Received: by'
line doesn't matter, but the 'by' field is very important to SC.

The rest of the problem is in something improper of the folding of the
last bogusline which I haven't figured out yet.

Here is both problems straightened out

www.spamcop.net/sc?id=z742094018zfd2acfe0d5d74e233e5bc25e27e5187ez

compare to yours below

Post by The Father Mind of DM Industries
But it still is not working.
See example.

http://www.spamcop.net/sc?id=z741906119z23de0e976e15d09dc6f3cec824e26dd5z

[The Father Mind of DM Industries]

Post by Mike Easter
If you have access to the Postfix at 64.81.88.120 rDNS
server-03.dmindustries.net -- you need to take the caps out of its name
Received: from 64.81.88.120 (unknown [221.234.27.33]) by
Server-03.DMIndustries.NET (Postfix) with SMTP id 4C36714478; Sun, 13
Mar 2005 17:54:30 -0800 (PST)

Okay well I believe that is coming from the srever its self. I have bad
habit of using Proper lettering when typing out domain names.

Yea I am going to work with you on this in every way I can.
I have been pondering this. Now let me explain to you some things that will
help us resolve this...

I have an account on my mail server that I direct all spam to (Not the way
it sounds). I have had clients that have had eMail accounts and those mail
accounts just receive NOTHING but spam. All day long spam spam spam. Old
business accounts of employees of business that I support. So I tunnel all
those accounts via alias into one account. That account forwards the spam
via a SpamCop supplied script perl script to the quick reporting on SpamCop.
Those eMails are never reporting the servers IP (they work).

Now, the eMail account in question is my personal account. This is an eMail
account on the DMIndustries server (Also Dangerous-Minds.NET) that is being
forwarded via the .forward file to an account on TotalSystemControl.com.
Also a postfix mail server on a redhat Linux box. I built and admin both
servers. I own the DMIndustries.net server and the TotalSystemControl
server is owned by a friend. So what ever is happening is happening (I
would guess) because of the forwarding or because of something on the
totalsystemcontrol server. Or worse case because of Outlook Express... but
then other people would be reporting this I am sure.

I have changed the settings on both servers all references to the servers
are in lower case now. I had a spam come in and it worked as it is supposed
to. I will test some more and report back to you as not ALL spam's were
having this problem.

... Master Merlin Cul Kirkpatrick

Post by Mike Easter

Post by The Father Mind of DM Industries
Okay I fixed the dns resolve on both servers.

If you have access to the Postfix at 64.81.88.120 rDNS
server-03.dmindustries.net -- you need to take the caps out of its name
Received: from 64.81.88.120 (unknown [221.234.27.33]) by
Server-03.DMIndustries.NET (Postfix) with SMTP id 4C36714478; Sun, 13
Mar 2005 17:54:30 -0800 (PST)
The helo doesn't matter [here, maybe somewhere] and the 'Received: by'
line doesn't matter, but the 'by' field is very important to SC.
The rest of the problem is in something improper of the folding of the
last bogusline which I haven't figured out yet.
Here is both problems straightened out
www.spamcop.net/sc?id=z742094018zfd2acfe0d5d74e233e5bc25e27e5187ez
compare to yours below

Post by The Father Mind of DM Industries
But it still is not working.
See example.

http://www.spamcop.net/sc?id=z741906119z23de0e976e15d09dc6f3cec824e26dd5z
--
Mike Easter
kibitzer, not SC admin

[The Father Mind of DM Industries]

I have submitted like 8 spam so far and all of them have worked correctly so
far.

Post by Mike Easter

Post by The Father Mind of DM Industries
Okay I fixed the dns resolve on both servers.

If you have access to the Postfix at 64.81.88.120 rDNS
server-03.dmindustries.net -- you need to take the caps out of its name
Received: from 64.81.88.120 (unknown [221.234.27.33]) by
Server-03.DMIndustries.NET (Postfix) with SMTP id 4C36714478; Sun, 13
Mar 2005 17:54:30 -0800 (PST)
The helo doesn't matter [here, maybe somewhere] and the 'Received: by'
line doesn't matter, but the 'by' field is very important to SC.
The rest of the problem is in something improper of the folding of the
last bogusline which I haven't figured out yet.
Here is both problems straightened out
www.spamcop.net/sc?id=z742094018zfd2acfe0d5d74e233e5bc25e27e5187ez
compare to yours below

Post by The Father Mind of DM Industries
But it still is not working.
See example.

http://www.spamcop.net/sc?id=z741906119z23de0e976e15d09dc6f3cec824e26dd5z
--
Mike Easter
kibitzer, not SC admin

[The Father Mind of DM Industries]

No No we are not through this yet.
I managed to forward about 10+ before another one showed up.
http://www.spamcop.net/sc?id=z742897644ze824e48550385cd9de71b82dfacb0d87z

Tell me what I did wrong here please. :)
I looked at it and I am not sure.

Post by Mike Easter

Post by The Father Mind of DM Industries
Okay I fixed the dns resolve on both servers.

If you have access to the Postfix at 64.81.88.120 rDNS
server-03.dmindustries.net -- you need to take the caps out of its name
Received: from 64.81.88.120 (unknown [221.234.27.33]) by
Server-03.DMIndustries.NET (Postfix) with SMTP id 4C36714478; Sun, 13
Mar 2005 17:54:30 -0800 (PST)
The helo doesn't matter [here, maybe somewhere] and the 'Received: by'
line doesn't matter, but the 'by' field is very important to SC.
The rest of the problem is in something improper of the folding of the
last bogusline which I haven't figured out yet.
Here is both problems straightened out
www.spamcop.net/sc?id=z742094018zfd2acfe0d5d74e233e5bc25e27e5187ez
compare to yours below

Post by The Father Mind of DM Industries
But it still is not working.
See example.

http://www.spamcop.net/sc?id=z741906119z23de0e976e15d09dc6f3cec824e26dd5z
--
Mike Easter
kibitzer, not SC admin

[Mike Easter]

Post by The Father Mind of DM Industries
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

Post by The Father Mind of DM Industries
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 <***@mx3.eastlink.ca> 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]

Post by The Father Mind of DM Industries

Post by The Father Mind of DM Industries
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

Post by The Father Mind of DM Industries
Tell me what I did wrong here please. :)
I looked at it and I am not sure.

There's nothing you are doing wrong.

However, I predict that you would get a correct result if you were to
correctly configure yourself to use the mailhosts mod.

[The Father Mind of DM Industries]

Okay, again I am going to make myself look foolish here. What is the
mailhosts mod? If you previously mentioned this to me (And it sounds very
familiar so either you did or I saw it mentioned some where) I am sorry for
making you repeat your self.

... Master Merlin Cul Krikpatrick

Post by Mike Easter

Post by The Father Mind of DM Industries

Post by The Father Mind of DM Industries
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

Post by The Father Mind of DM Industries
Tell me what I did wrong here please. :)
I looked at it and I am not sure.

There's nothing you are doing wrong.

However, I predict that you would get a correct result if you were to
correctly configure yourself to use the mailhosts mod.
--
Mike Easter
kibitzer, not SC admin

[WazoO]

Post by The Father Mind of DM Industries
Okay, again I am going to make myself look foolish here. What is the
mailhosts mod? If you previously mentioned this to me (And it sounds very
familiar so either you did or I saw it mentioned some where) I am sorry for
making you repeat your self.

Configuring your account by identifying your MailHosts ..??
Button seen on your logged-into www.spamcop.net page
Found under the FAQ from the Help button on the same page.
Alternative to this is the Forum FAQ (which includes even
more stuff) at http://forum.spamcop.net/forums/index.php

[Mike Easter]

Post by The Father Mind of DM Industries

Post by The Father Mind of DM Industries
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
<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 <***@mx3.eastlink.ca> 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.

[The Father Mind of DM Industries]

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.

Post by Mike Easter

Post by The Father Mind of DM Industries

Post by The Father Mind of DM Industries
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
<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
I hate to paste all of this verbose logic, but it is different from
<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
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.>
<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

[The Father Mind of DM Industries]

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?

Post by The Father Mind of DM Industries

Post by The Father Mind of DM Industries
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

Post by The Father Mind of DM Industries
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>
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
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
<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

[Mike Easter]

Post by The Father Mind of DM Industries
Okay so now that we have more or
less established there is a problem with the parser, what now?

It now appears to be fixed.

Sometimes I think that when we are discussing what is wrong with the
parser, Julian is lurking in the ng and tweaking code down there in the
dungeon or wherever he does that stuff.

It appears that the parser is all better. I just forged an item to test
an item very similar to the one we were discussing which parses
correctly now, except that the .br IP I made up /isn't/ listed in the
CBL, and SC now gets it right anyway.

http://www.spamcop.net/sc?id=z743280656z9b76c1afbc70fc2bed3634ca9d8acdc4z

So, now when SC sez 'looks like a forgery' - it makes sense. The
'forgery' is comparing the 'from' IP with the domainname of the 'by'
field -- which doesn't 'compute' - so the 'by' must be 'forged'. Here's
the pertinent section. And, SC doesn't 'jump backwards' and 'unaccept'
something which it had already accepted earlier

<snip>
Received: from 201-26-32-156.dsl.telesp.net.br
(201-26-32-156.dsl.telesp.net.br [201.26.32.156]) by
server-03.dmindustries.net (Postfix) with SMTP id 500211445B for <x>;
Wed, 16 Mar 2005 15:36:35 -0800 (PST)
201.26.32.156 found
host 201.26.32.156 (getting name) = 201-26-32-156.dsl.telesp.net.br.
201-26-32-156.dsl.telesp.net.br is 201.26.32.156
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.156
201.26.32.156 is not an MX for 201-26-32-156.dsl.telesp.net.br
host 201-26-32-156.dsl.telesp.net.br (checking ip) = 201.26.32.156
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: the acceptance of that line means that 64 isn't the source anymore,
now the new potential source is 201>

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 <***@mx3.eastlink.ca> 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.156 not listed in dnsbl.njabl.org
201.26.32.156 not listed in cbl.abuseat.org
201.26.32.156 not listed in dnsbl.sorbs.net
201.26.32.156 is not an MX for server-03.dmindustries.net
201.26.32.156 is not an MX for 201-26-32-156.dsl.telesp.net.br
201.26.32.156 is not an MX for mx3.charta2N.ca
201.26.32.156 is not an MX for server-03.dmindustries.net
201.26.32.156 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.156 is not an MX for mx3.charta2N.ca

<ME: in that blob, SC is finding out that it can't chain from the 201
'from' to its respective 'by' -- and so it breaks the chain. It also
isn't listed in any proxy db/s, but that doesn't matter, SC figgered it
out anyway.

Looks like a forgery
Tracking message source: 201.26.32.156:

<ME: SC has the source and it didn't jump backwards to the 64, which was
crazy before>

[The Father Mind of DM Industries]

I am sure it helped that I added my servers to the Mailhosts lists area.
Thank you for your assistance on this. We have lots of resources and good
minds. If you ever need any thing please feel free to drop in and ask for
it or visit. Best place to find us is on our private IRC server in the
#Public channel on DMIndustries.net or use the cgi chat on
http://Chat.Dangerous-Minds.NET

Now, I am going to write what I will be calling a local RBL that will build
a local list of IP's to exclude from eMail via spam collecting addresses. I
hope that this will help cut down the spam even more.

.. Master Merlin Cul Kirkpatrick

Post by Mike Easter

Post by The Father Mind of DM Industries
Okay so now that we have more or
less established there is a problem with the parser, what now?

It now appears to be fixed.
Sometimes I think that when we are discussing what is wrong with the
parser, Julian is lurking in the ng and tweaking code down there in the
dungeon or wherever he does that stuff.
It appears that the parser is all better. I just forged an item to test
an item very similar to the one we were discussing which parses
correctly now, except that the .br IP I made up /isn't/ listed in the
CBL, and SC now gets it right anyway.
http://www.spamcop.net/sc?id=z743280656z9b76c1afbc70fc2bed3634ca9d8acdc4z
So, now when SC sez 'looks like a forgery' - it makes sense. The
'forgery' is comparing the 'from' IP with the domainname of the 'by'
field -- which doesn't 'compute' - so the 'by' must be 'forged'. Here's
the pertinent section. And, SC doesn't 'jump backwards' and 'unaccept'
something which it had already accepted earlier
<snip>
Received: from 201-26-32-156.dsl.telesp.net.br
(201-26-32-156.dsl.telesp.net.br [201.26.32.156]) by
server-03.dmindustries.net (Postfix) with SMTP id 500211445B for <x>;
Wed, 16 Mar 2005 15:36:35 -0800 (PST)
201.26.32.156 found
host 201.26.32.156 (getting name) = 201-26-32-156.dsl.telesp.net.br.
201-26-32-156.dsl.telesp.net.br is 201.26.32.156
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.156
201.26.32.156 is not an MX for 201-26-32-156.dsl.telesp.net.br
host 201-26-32-156.dsl.telesp.net.br (checking ip) = 201.26.32.156
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: the acceptance of that line means that 64 isn't the source anymore,
now the new potential source is 201>
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
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.156 not listed in dnsbl.njabl.org
201.26.32.156 not listed in cbl.abuseat.org
201.26.32.156 not listed in dnsbl.sorbs.net
201.26.32.156 is not an MX for server-03.dmindustries.net
201.26.32.156 is not an MX for 201-26-32-156.dsl.telesp.net.br
201.26.32.156 is not an MX for mx3.charta2N.ca
201.26.32.156 is not an MX for server-03.dmindustries.net
201.26.32.156 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.156 is not an MX for mx3.charta2N.ca
<ME: in that blob, SC is finding out that it can't chain from the 201
'from' to its respective 'by' -- and so it breaks the chain. It also
isn't listed in any proxy db/s, but that doesn't matter, SC figgered it
out anyway.
Looks like a forgery
<ME: SC has the source and it didn't jump backwards to the 64, which was
crazy before>
--
Mike Easter
kibitzer, not SC admin

[The Father Mind of DM Industries]

Okay I added the Mailhosts (I must be blind for missing that)
And now it seems to be processing better.
I can see where the "system" should be able to process the header with out
knowing the hosts. But if you have the feature there to improve the system,
why not rely on it to resolve those 3% foul-ups?


... Master Merlin Cul Kirkpatrick

Post by The Father Mind of DM Industries
No No we are not through this yet.
I managed to forward about 10+ before another one showed up.
http://www.spamcop.net/sc?id=z742897644ze824e48550385cd9de71b82dfacb0d87z
Tell me what I did wrong here please. :)
I looked at it and I am not sure.

Post by Mike Easter

Post by The Father Mind of DM Industries
Okay I fixed the dns resolve on both servers.

If you have access to the Postfix at 64.81.88.120 rDNS
server-03.dmindustries.net -- you need to take the caps out of its name
Received: from 64.81.88.120 (unknown [221.234.27.33]) by
Server-03.DMIndustries.NET (Postfix) with SMTP id 4C36714478; Sun, 13
Mar 2005 17:54:30 -0800 (PST)
The helo doesn't matter [here, maybe somewhere] and the 'Received: by'
line doesn't matter, but the 'by' field is very important to SC.
The rest of the problem is in something improper of the folding of the
last bogusline which I haven't figured out yet.
Here is both problems straightened out
www.spamcop.net/sc?id=z742094018zfd2acfe0d5d74e233e5bc25e27e5187ez
compare to yours below

Post by The Father Mind of DM Industries
But it still is not working.
See example.

http://www.spamcop.net/sc?id=z741906119z23de0e976e15d09dc6f3cec824e26dd5z

Post by The Father Mind of DM Industries

Post by Mike Easter
--
Mike Easter
kibitzer, not SC admin