No source IP address found, cannot proceed

[efa]

This full header seems confuse the parser.

Here the tracking url:

http://www.spamcop.net/sc?id=z1242652163z9...284b9ae8459932z

reporting procedure cannot identify the source IP as 200.104.158.168 of

inetnum: 200.104.128/17

owner: VTR BANDA ANCHA S.A.

ownerid: CL-VPNS-LACNIC

responsible: Italo Sambuceti

address: Reyes Lavalle, 3340, 4th floor

address: 6760335 - Santiago -

country: CL

phone: +56 02 3101502 []

person: Italo Sambuceti Oyarzún

e-mail: isambuce[at]VTR.CL

as the other IP are all local private lan IP.

The exact error is:

Mailhost configuration problem, identified internal IP as source

Mailhost:

Please correct this situation - register every email address where you receive spam

No source IP address found, cannot proceed.

Add/edit your mailhost configuration

Finding full email headers

Submitting spam via email (may work better)

Example: What spam headers should look like

Nothing to do.

[StevenUnderwood]

This full header seems confuse the parser.

Here the tracking url:

http://www.spamcop.net/sc?id=z1242652163z9...284b9ae8459932z

First, thank you for providing the TrackingURL.

I agree this is strange. The parser does not even appear to be seeing this header, which to my eye looks OK and is immediately after the last header it does reach.

Received: from chelo (200.104.158.168) by smtp-in10.libero.it (7.3.120)
		id 45D3597C0243682E for x; Sun, 4 Mar 2007 04:02:49 +0100

Reporting addresses:

abuse[at]vtr.net

lsoto[at]vtr.cl

Do all of your parses pass through 4 internal hops like this one?

[Farelf]

Parsing without mailhosts - http://www.spamcop.net/sc?id=z1242820663ze...c33ab8876d01ecz

No effective change, just a different message

Received: from chelo (200.104.158.168) by smtp-in10.libero.it (7.3.120) id 45D3597C0243682E for x; Sun, 4 Mar 2007 04:02:49 +0100

Bogus IP in HELO removed: 200.104.158.168

Received: from chelo [x.x.x.x] by smtp-in10.libero.it (7.3.120) id 45D3597C0243682E for x; Sun, 4 Mar 2007 04:02:49 +0100

Ignored

No source IP address found, cannot proceed.

So the vtr.cl IP address is pinged as bogus in this analysis. I'm lost.

[rconner]

Parsing without mailhosts - http://www.spamcop.net/sc?id=z1242820663ze...c33ab8876d01ecz

Seems like the parse quits after

Received: from localhost (172.31.0.73) by smtp-in9.libero.it (7.3.120)

id 45D9801401289400 for x; Sun, 4 Mar 2007 04:02:50 +0100

This seems to document an internal handoff within the libero.it domain.

Now, 172.x addresses are unrouteable, reserved for private net use (which may be what the parser is trying to tell you when it says "identified internal IP as source." Many ISPs (including mine) will use these addresses for internal mail handoffs, but this plays hell with SpamCop or any other application trying to trace the header chain. That would certainly end the parse unless SpamCop were told to look beyond it (i.e., using the mailhosts setup process for the e-mail address involved here).

It could be (1) you didn't put this e-mail address through the mailhosts process, or (2) libero.it has somehow changed their mail processing so that the old mailhosts info is no longer accurate.

-- rick

[Wazoo]

From: "WazoO"

To: "deputies"

Subject: MailHost / ISP configuration problem

Date: Sun, 4 Mar 2007 11:08:32 -0600

Forum Topic http://forum.spamcop.net/forums/index.php?showtopic=8003

MailHosted Tracking URL

http://www.spamcop.net/sc?id=z1242652163z9...284b9ae8459932z

Non-MailHosted Tracking URL

http://www.spamcop.net/sc?id=z1242820663ze...c33ab8876d01ecz

Problem: Local and Internal IP addresses are all non-routable IP addresses.

MailHosted parse seems to be 'happy' with that 'local' definition, but the

parsing itself dies .. I'm assuming because there is no 'real' hand-off

address beyond the injection point, making the decision point that

the e-mail never really went anywhere ....???? (probably not the

best attempted description, but .... that the MailHost parse didn't

die on the identification of the internal addresses to begin with .???)

[efa]

Do all of your parses pass through 4 internal hops like this one?

generally no, but today I received 3 spam with that schema.

On 2, parser correcly identified source IP, but this one is strange.

Now, 172.x addresses are unrouteable, reserved for private net use (which may be what the parser is trying to tell you when it says "identified internal IP as source." Many ISPs (including mine) will use these addresses for internal mail handoffs, but this plays hell with SpamCop or any other application trying to trace the header chain. That would certainly end the parse unless SpamCop were told to look beyond it (i.e., using the mailhosts setup process for the e-mail address involved here).

It could be (1) you didn't put this e-mail address through the mailhosts process, or (2) libero.it has somehow changed their mail processing so that the old mailhosts info is no longer accurate.

B block netrange 172.16.0.0/12 is quite large, 1.048.576 host IP, I cannot know in advance which are used from my ISP, and surely I cannot insert all that IP in the mailhost configuration form.

But private use IP aren't real source of spam, and the parser should look for away of them.

In this case under, in other case over.

[Wazoo]

On 2, parser correcly identified source IP, but this one is strange.

A Tracking URL of one of the successful items would be appreciated for comparitive/troubleshooting analysis.

netrange 172.16.0.0/12 is quite large, 1.048.576 host IP, I cannot know in advance which are used from my ISP, and surely I cannot insert all that IP in the mailhost configuration form.

Technically, not required. On the other hand, there should be an e-mail server involved with a routable address involved in the sequence at your ISP.

But surely private use IP aren't real source of spam, and the parser should look for away them.

It's not that non-routable IP addresses involved directly, it's more that there isn't a 'real / connected' server seen in your samples thus far tat relate to your ISP's handling of the e-mail ....

[efa]

A Tracking URL of one of the successful items would be appreciated for comparitive/troubleshooting analysis.

I looked in Past reports, and finded those two:

[Wazoo]

I looked in Past reports, and finded those two:

http://members.spamcop.net/mcgi?action=get...rtid=2179995530

http://members.spamcop.net/mcgi?action=get...rtid=2180112526

Thanks for the try .... however, please see the SpamCop FAQ entry (here) Getting a Tracking URL from a Report ID

[rconner]

netrange 172.16.0.0/12 is quite large, 1.048.576 host IP, I cannot know in advance which are used from my ISP, and surely I cannot insert all that IP in the mailhost configuration form.

I apologize in advance if I am wrong, but the quote suggests that you may not understand the mailhost setup process (you're far from alone on this one). You do NOT have to provide detailed mail host info as part of this process (at least not as far as I know). Actually, the only data you have to provide is the e-mail address (e.g., foo[at]fum.com) for which you want to report spam. SpamCop will send you one or more e-mails (i.e., one for each MX listed in DNS for your address), and your only job is to return them (or, more foolproof, paste them into a web form). After that, SpamCop should be able to understand how your ISP constructs headers and you should have fewer (or no) parsing problems.

See this link to the SpamCop help FAQ for some more detail.

Moderator Edit: Using the SpamCop FAQ 'here' would lead one to the non-SpamCop.net e-mail account holder's URL of http://www.spamcop.net/fom-serve/cache/397.html to reach that 'original' FAQ entry.

But surely private use IP aren't real source of spam, and the parser should look for away them.

In this case under, in other case over.

I believe that the problem isn't so much with the address itself as with the fact that the ISP has constructed a nonstandard mail header that SpamCop cannot make sense of without help (hence the mail host config process). SpamCop can't "look over" any data in the header chain unless it has been told how to do so via the mailhost config process.

The headers from your report (and many from other providers like my own ISP Verizon) are 'broken' and do not preserve the traceability that one expects to see. If SpamCop cannot trace the from-host in one line to the by-host in the line beneath it, this causes a big problem. Likewise, if the hosts show up at unrouteable addresses, and if the host-name chain is broken (as in your case), then it is very hard for SpamCop (or anyone else) to figure out a priori what is going on.

It used to be that you could assume that if the hostname chain in the header was broken at any point, this would be the point at which the spam was originated (and the earlier lines would then be forgeries intended to misdirect). This is unfortunately no longer the case, mainly because some ISPs have altered the way in which they record internal SMTP transfers. This is all of us SpamCop users had to go through the mailhosts setup process beginning some years back.

-- rick

[efa]

Thanks for the try .... however, please see the SpamCop FAQ entry (here) Getting a Tracking URL from a Report ID

spamcop is a little complicated, sorry

http://www.spamcop.net/sc?id=z1242666174z4...ed448e45811d45z

http://www.spamcop.net/sc?id=z1242736408z6...57d857314c41fbz

[Wazoo]

spamcop is a little complicated, sorry

Compounded by the fact that you are talking to volunteer users here .... thus my upstream e-mail request for help above.

http://www.spamcop.net/sc?id=z1242666174z4...ed448e45811d45z

http://www.spamcop.net/sc?id=z1242736408z6...57d857314c41fbz

Comparing these two samples to your previous (and Farelf's non-mailhosted example) shows that your MailHost Configuration of your Reporting Account was actually successfully performed. The basic confusion would more seem to be based on the lack of an appropriate error message in your MailHosted parse results .... if you note Farelf's example, the only non-routable IP address in that header was tossed out .. whereas, in your parse, the analysis simply halted with a seemingly 'incorrect' error condition ... the 'real' issue wasn't actually documented on 'your' result page.

In these two last examples, a valid source was actually found by the parser, thus the 'success' in generating a Report.

[efa]

The basic confusion would more seem to be based on the lack of an appropriate error message in your MailHosted parse results .... if you note Farelf's example, the only non-routable IP address in that header was tossed out .. whereas, in your parse, the analysis simply halted with a seemingly 'incorrect' error condition ... the 'real' issue wasn't actually documented on 'your' result page.

ok, maybe I have not understood your answer, but what should I do next time to get spamcop parser work correcly?

[Wazoo]

ok, maybe I have not understood your answer, but what should I do next time to get spamcop parser work correcly?

Have an e-mail from Ellen ... they (paid staff) are looking at the issue. Like you, waiting for an 'official' response ....

I believe I have the problem diagnosed, but .... handling by the parser is an issue that can only be handled by the IronPort folks.

[efa]

ok, I wait hoping in a fix.

Wazoo please write your thinked solution ;-)