You did not go deep enough ...

[Neil Parks]

http://www.spamcop.net/sc?id=z810156459zb3...60c16244220421z

This is one of the first times I have attempted to report spam since registering for the Mailhost plan. I get mail at an address in "torah.org" which uses a mail server "capalon.com". That forwards to an address in "en.com" (Exchange Net, Voyager, Corecomm, gatewaydefender.com). As instructed by the Mailhost screens, I registered both addresses in "reverse" order--the en.com address first and then the torah.org address.

Prior to joining the new plan I would just delete all the top headers that showed the traffic between capalon.com and en.com. Tne first Received line you saw would clearly show where capalon.com received it from the spammer's IP.

I joined the Mailhost plan hoping to make things easier for myself. I thought now I could just forward the email to SC as an attachment, and you would know how to read down through the authorized relays to get to the spammer's IP. But alas, that is not the way it turned out.

As you can see if you go to the URL above and look at the headers, SC stopped one record short of its goal. Capalon routes its mail internally by way of a 127.0.0.1 host before it goes off to en.com. SC got fooled by that extra internal routing, and did not go onto the next line which clearly shows where it entered Capalon.

I hope that problem can be corrected.

[Neil Parks]

Another example of same situtation, just to verify that the one above is not an isolated instance:

http://www.spamcop.net/sc?id=z810156097z35...ca2179cacda0f2z

[Wazoo]

Not sure who you think you are writing to ... the parsing and reporting tool is a bit of computer code. The "you" that's typing this response in is a volunteer supporter sitting a few thousand miles/kilometers/whatever away from the computers that attempted to parse your spam. The error message I see in your sample parse is on a computer system sitting a bit closer to you. Maybe you can get those folks to fix their system?

3: Received: from localhost (localhost [127.0.0.1]) by horiyos.capalon.com (Postfix) with ESMTP id 8518216DE46 for <x>; Wed, 28 Sep 2005 09:10:10 -0400 (EDT)

63.208.156 does not report source IP correctly

No source IP address found, cannot proceed.

If you look at your headers, the same system allegedly received this e-mail three times .... but with wildly varying inserted headerline data ...

Received: by horiyos.capalon.com (Postfix)

id 93E0716DE05; Wed, 28 Sep 2005 09:10:10 -0400 (EDT)

Received: from localhost (localhost [127.0.0.1])

by horiyos.capalon.com (Postfix) with ESMTP id 8518216DE46

for <x>; Wed, 28 Sep 2005 09:10:10 -0400 (EDT)

Received: from powers-host.net (ftp.xparty.co.il [199.203.243.85])

by horiyos.capalon.com (Postfix) with ESMTP id 2964116DE05

for <x>; Wed, 28 Sep 2005 09:10:05 -0400 (EDT)

MailHost configuration of your reporting account isn't a "plan" ,,,???? Have you read any of the Pinned items provided for your use, especially the ones tagged with "read before posting" ...???

And to go a step further, your sample spam ran through a non-MailHost configured reporting account results in the same failure being pointed out ...

http://www.spamcop.net/sc?id=z810165251z9f...a1d2c97fa8fbeez

Received: from localhost (localhost [127.0.0.1]) by horiyos.capalon.com (Postfix) with ESMTP id 8518216DE46 for <x>; Wed, 28 Sep 2005 09:10:10 -0400 (EDT)

127.0.0.1 found

host 127.0.0.1 = localhost (cached)

localhost is 127.0.0.1

Receiving server (63.208.156) does not report source IP accurately

Deleting Headers lines is basically breaking the "material alterations" rule.

[Wazoo]

Another example of same situtation, just to verify that the one above is not an isolated instance:

http://www.spamcop.net/sc?id=z810156097z35...ca2179cacda0f2z

33444[/snapback]

Same error seen on the same server / IP ...??? I'll agree, not an isolated case involved here.

[Neil Parks]

I'm aware of all the things that you said. But I guess I didn't make my point clearly enough: I could have edited all that localhost junk out before submitting the spam, and it would have parsed CORRECTLY--as all the spams I have reported in the past parsed correctly.

I could have DELETED everything through this:

Received: from localhost (localhost [127.0.0.1])
	by horiyos.capalon.com (Postfix) with ESMTP id 3373D16DED3
	for <x>; Wed, 28 Sep 2005 06:47:18 -0400 (EDT)

and sent it to SC starting with this:

Received: from d58-104-255-9.dsl.nsw.optusnet.com.au (d58-104-255-9.dsl.nsw.optusnet.com.au [58.104.255.9])
	by horiyos.capalon.com (Postfix) with SMTP id 498C816E0A4
	for <x>; Wed, 28 Sep 2005 06:47:10 -0400 (EDT)

I guess I misunderstood the PURPOSE of the mailhost registration plan (and I think that's a good word for it.) I thought that SC's code (you think I don't know it's a program??) would then recognize all headers associated with registered domains such as capalon.com, and skip down to where it found one that was not.

But obviously I was wrong about that and I'll just have to go back to the old cut-and-paste way that was working before.

[Neil Parks]

I guess I misunderstood the PURPOSE of the mailhost registration plan (and I think that's a good word for it.)  I thought that SC's code ... would then recognize all headers associated with registered domains such as capalon.com, and skip down to where it found one that was not.

But obviously I was wrong about that ...

33447[/snapback]

After further review, I don't think I was so wrong after all.

http://forum.spamcop.net/forums/index.php?showtopic=2009

The purpose of Mail-hosts:

To identify the mail hosts/mail servers used by you to recieve email and to separate them from those used to send you mail. To find the demarkation in the received headers where they switch from servers "belonging" to you or your ISPs/hosting companies and switch to received headers showing the source of the email.

That's exactly what I was expecting, and that isn't what's happening.

[Wazoo]

Well, it's like this ... you asked a question, made some accusations and challenges .. then did some major editing of previous posts.

I responded advising that you were violating the rules you agreed to when signing up to use the SpamCop parsing and reporting toolset, I pointed out that the host in question has some serious configuration issues, pointed you to existing documentation on what to do if "your issue" falls outside of the run-of-the-mill type problems .....

You respond to that by cherry-picking one bit of data that you interpret to further your cause, somehow seemingly to ignore the rest of the data provided ... and go on to say that you're going to march on doing things the wrong way, against the policies of the folks that run things ....

Guess there's not much more than needs to be said here by me ...

[StevenUnderwood]

But obviously I was wrong about that and I'll just have to go back to the old cut-and-paste way that was working before.

33447[/snapback]

Which may be AGAINST THE RULES.

As stated by Wazoo: Deleting Headers lines is basically breaking the "material alterations" rule.

You need to get capalon.com to fix their header problem or stop reporting spam through spamcop.

[turetzsr]

<snip>

You need to get capalon.com to fix their header problem or stop reporting spam through spamcop.

33458[/snapback]

...Or contact the SpamCop deputies at deputies [at] spamcop [dot] net and politely ask if they can help.

[Wazoo]

...Or contact the SpamCop deputies at deputies [at] spamcop [dot] net and politely ask if they can help.

33461[/snapback]

As seen in the Pinned and tagged "read before posting" items already pointed to <g>

[Jeff G.]

Another reason to contact the Deputies is that they have access to the database which has the flag that produces "63.208.156 does not report source IP correctly" in the Parser, and the corresponding evidence to back up their (or a SpamCop Admin's) decision to set that flag, and you should ask them to review that evidence in light of your current circumstances. Copying the email admins at capalon.com with your correspondence may help to speed the process.

[SpamCopAdmin]

Handled by email...

Receiving server (63.208.156) does not report source IP accurately

That's the key to this whole thing. The parse will *always* tag a server that has been marked as a "liar" no matter what sort of Mailhost configuration the user has set up.

In this case, the user's Mailhost configuration is correct, and the headers of the emails at issue are good enough for SpamCop to correctly process.

No source IP address found, cannot proceed.

The fact that SpamCop knew the "lying" server belonged to the user and refused to report it is a demonstration of the value of the Mailhosts system.

horiyos.capalon.com (horiyos.teamgenesis.com [63.208.156.20] is part of the 63.208.156/24 range that was marked as "untrustworthy" (Liar status) at the request of Teamgenesis a long time ago, for reasons of their own.

I removed the "liar" flag because it is no longer viable now that the Teamgenesis servers are being used as a forwarding service. The parse is finding the true source of the spam now.

Altering headers is a *huge* taboo with us. It is *never* the way to go.

- Don D'Minion - SpamCop Admin -

service at admin.spamcop.net

[Wazoo]

Thanks for the time and effort Don!