Jump to content

[Resolved] SpamCop fooled by fake headers


Recommended Posts

Posted
Does anybody know why SpamCop overruns the last good Received: line (calling it an internal handoff) and parses the fake Received: line? This is the second time that this has happened today. The sending machine 24.232.132.187 is certainly not part of my mailhost setup.

27048[/snapback]

The only reason I can figure out is because 172.19.34.100 (the IP mx.perfora.net is claiming to be) is a non-routable IP address so the OL187-132.fibertel.com.ar[24.232.132.187] would have to be internal to that network. I did not think that spamcop took the receiving servers IP address into account at all, but where it looks like you are still in mailhost mode there, that may affect things.

In this case I am believing it is not the fake header fooling spamcop but an incorect header placed there by 24.232.132.187 (1&1?). Do you have a good parse through the same servers, perhaps even sent to yourself that could be analyzed?

Posted

A little more research has revealed that this spam was apparently sent to the secondary MX and 1&1 seems to have recently (maybe today?) changed the format of the Received: line used by that machine. With that new Received: line, SpamCop does not recognize it anymore as part of my mailhost configuration. So this seems to be really a mailhost issue. Please move to the appropriate forum.

I tried deleting and recreating my mailhost entry for 1&1. It went fine for the primary MX and created the same mailhost table that I had before. For the secondary MX, however, I now get this error:

Sorry, SpamCop has encountered errors:

Source IP not found.

Your email host does not appear to correctly identify the sending IP of
the email you receive.

The last address identified by your mail host was 172.19.34.100 ().
This does not appear to be a spamcop.net address.

If you feel this is in error, please try again or seek help in the SpamCop
help forum: http://www.spamcop.net/help.shtml

The relevant Received: lines in the probe look like this:

Received: from unknown (192.168.1.103)
  by blade5.cesmail.net with QMQP; 26 Apr 2005 01:02:19 -0000
Received: from mout.perfora.net (217.160.230.41)
  by mailgate2.cesmail.net with SMTP; 26 Apr 2005 01:02:19 -0000
Received: from sc-app4.spamcop.net[64.74.133.245]
 by mx.perfora.net[172.19.34.100] (Nemesis),
 id 0MKuxu-1DQE831PWp-0000kN for [MUNGED my email address]
X-SpamCop-Conf: [code removed]

I guess it might be confused about that unroutable IP address in there. Any ideas about how to fix this?

For comparison, here is what the probe looks like for the (properly working) primary MX:

Received: from unknown (192.168.1.103)
  by blade6.cesmail.net with QMQP; 26 Apr 2005 00:56:27 -0000
Received: from mout.perfora.net (217.160.230.40)
  by mailgate2.cesmail.net with SMTP; 26 Apr 2005 00:56:27 -0000
Received: from sc-app4.spamcop.net[64.74.133.245] (helo=spamcop.net)
	by mx.perfora.net with ESMTP (Nemesis),
	id 0MKv22-1DQE821rwW-0002NO; Mon, 25 Apr 2005 20:40:42 -0400
X-SpamCop-Conf: [removed]

Posted

You're going to have to make an attempt at following the guidance offered up in the Pinned items in this Forum section, noting that the "read before posting" comment was placed there for a reason, as was the peer-to-peer / user-to-user notification .... You're in the position that if the database has to be 'touched' to force acceptance of this bad configuration, there's but a couple of people with that type of access.

Posted

Thanks, Wazoo. I have contacted Ellen. I hope we will get this fixed soon, because this probably does not affect only me, but many other customers of 1&1, the world's largest hosting company, who might also be SpamCop reporters.

Posted

That's really weird, actually. I know 1and1, I know how huge they are, but it sure seems like their name has been coming up more and more over the last 6-8 months or so. Not just here either. It may be that they are just getting toooo huge, and just don't have the right folks at the right places. Casting no aspersions, just (again) surprised at such an 'interesting' network configuration by such an outfit. Yep, Ellen is the one that might be able to pull it off, I think she's done this exact setting for some other folks. It just seems scary from my point of view .. if they are going to slap a system that's identifying itself with a non-routable IP, would one also conjecture that they may be using thier own network's DHCP amd tomorrow's power outage will have a dozen systems re-booting and this server's IP will the be 172.19.34.105 ???? Maybe a bad analogy, but the point is manipulating the SpamCopBL database using some funky data for one system that could change IPs in a heartbeat, perhaps then causing you (and perhaps others) some serious bad reporting issues.

Posted

The problem was not the non-routable IP address, but the lack of whitespace between the server name and the square brackets around the IP address. Ellen fixed it within one day. What an amazing service! :) Thanks Steven and Wazoo for all your help.

Posted

Now that you point it out, it is a bit obvious <g> So used to trying to ignore the whitespace problems with this applcation ... Yep, Ellen's got things going on .. glad she got it finagled.

Posted
The problem was not the non-routable IP address, but the lack of whitespace between the server name and the square brackets around the IP address. Ellen fixed it within one day. What an amazing service!  :) Thanks Steven and Wazoo for all your help.

27220[/snapback]

Thanks for the kind words but Julian is the one who fixed the code and some other nice folks at IP got the new code uploaded :-) And as was said further up the thread, yes this was affecting more than one user.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...