Hi,
This is the header of a spam that I reported to spamcop:

As you can see the ip address of the last server before our server is 212.52.128.2 but the system actually grabs 212.52.155.35.

The only reliable ip address is 212.52.128.2 because that is the ip address of the sender logged by our server all other ip addresses can be modified by spamer before sending the email.



Return-Path: <cashu[at]service.com>
Delivered-To: XXXX
Received: (qmail 27831 invoked by uid 1006); 2 Jun 2009 23:48:54 -0000
Delivered-To: XXXX
Received: (qmail 27829 invoked by uid 0); 2 Jun 2009 23:48:54 -0000
Received: from mail.cenatrin.bf (HELO koulouba.cenatrin.bf) (212.52.128.2)
by cleanvps.com with SMTP; 2 Jun 2009 23:48:54 -0000
Received: from localhost (localhost [127.0.0.1])
by koulouba.cenatrin.bf (Postfix) with ESMTP id 67D82933197;
Tue, 2 Jun 2009 23:26:15 +0000 (WET)
X-Virus-Scanned: amavisd-new at
X-spam-Flag: NO
X-spam-Score: 4.676
X-spam-Level: ****
X-spam-Status: No, score=4.676 tagged_above=-10 required=6.6
tests=[BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116,
FORGED_OUTLOOK_HTML=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457,
RDNS_NONE=0.1]
Received: from koulouba.cenatrin.bf ([127.0.0.1])
by localhost (koulouba.cenatrin.bf [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id rZn2YhhR7OYG; Tue, 2 Jun 2009 23:26:14 +0000 (WET)
Received: from airburki-fatclq.airburkina.local (unknown [212.52.155.35])
by koulouba.cenatrin.bf (Postfix) with ESMTP id 1B9DE932FF0;
Tue, 2 Jun 2009 23:25:38 +0000 (WET)
Received: from User ([217.12.63.26]) by airburki-fatclq.airburkina.local with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 2 Jun 2009 23:41:42 +0000

-------------------------

No, no, 'we' can see much better if you supply a Tracking URL - that gives us the assurance of looking at the complete headers and it lets us see exactly what the parser is doing and the messages it inserts in the parse as it works. Have you got "Show technical details" selected? And/or (Preferences tab) Report Handling Options > Show Technical Details during reporting, "Show technical data" selected? If not, the additional detail shown to you in the parse once you have that set up may answer your question.

Sorry I have removed that email from my mailbox!

But surely I will receive a new one and this time I will provide the tracking url.

Thanks, assume you were worried about the reporting offered and cancelled reports? In any event, you should still be able to pick it up from your "Past reports" - just get the URL by clicking the "Parse" link when the report page is displayed and copying, like

Hi,
That wasn't the correct tracking url.
What I was worried about was that the spamcop didn't get the first ip address "212.52.128.2" as the spammer ip address but selected a later ip address of "212.52.155.35" as the source of spam.

My mailserver received this spam from 212.52.128.2.

So the problem here is if the guys on 212.52.128.2 send me an email with fake header (they can easily change the part related to 212.52.155.35 in header) and i submit it to spamcop, instead of the sender mail server of 212.52.128.2 the fake ip address might be classified as spam sender.

I find the option to regenerate the tracking number so this is the tracking number:

http://www.spamcop.net/sc?id=z2964620554z6...5ee1cf5bb62d14z

it says 212.52.128.2 is possible spammer but ignores it down the line and decides to report 212.52.155.35 instead.

No, just an example to be sure you knew what it looked like and where to find it.Thanks for the tracker. Do you have technical details (reporting account setting) turned on? If you do, you will see that the parser accepts 212.52.128.2 as a relay, which is why it doesn't lay blame there. The parser saysSo it says it 'believes' 212.52.155.35 relayed through 212.52.128.2 because 212.52.128.2 is a mail exchange and that's its job. We can't go around reporting MXs for doing their jobs. True, spam could be injected at the mail exchange and the rest of the headers cleverly forged to make it look like it came from further 'downstream' but that is not very likely.

It refuses to have anything to do with the next received line, from 217.12.63.26. That could be the 'real' injection point or it could be a forgery. If it is the injection point then 212.52.155.35 has no business relaying for it, that would make 212.52.155.35 a promiscuous server and it is a better/higher-value target regardless.

Well, that's my interpretation of the parse results anyway. That's another benefit of working with the tracker (and 'technical details' turned ON) - all that analysis is provided, the exact logic of the parse is available for scrutiny and discussion.

(Just about) all the messages you get from outside your network should be reaching your network through someone else's mail server. It is usually where it came from before that which is where the deliberate/illegal spam insertion is found.

Hope I've made this clear for you. Hope I have it right (I'm not very 'technical' )

Oh, I should add that both 212.52.128.2 and 212.52.155.35 have the same reporting addresses anyway. You can check that by pasting/writing the IP addresses into the spam submission webform (your members page). But they (network admin in Bukina Faso) would probably not be impressed if SC blamed the MX (212.52.128.2) for 'MX-ing'. Mightn't seem much of a distinction but a world of difference in terms of the work the ISP would need to do to fix the real hole in their network or - more to the point - the confidence they might have in the SC report.

It might be a little of topic but do you know which one of those IP addresses qmail uses to check rbldns servers to decide to accept or reject the email?

If you want the parser to more reliably find the server sending you the messages, you would want to complete the mailhost configuration which tells spamcop which servers you expect to touch your messages.

SpamCop will still trust certain servers to reliably relay messages, however.

You would have to ask gmail and, I suspect, would not get any information from them. ISPs guard their secrets about how they detect spam email very carefully because it is an arms race between them and the spammers for detection and how to evade detection.

I also expect (though I am not a gmail user) that you have some filter options that you can tweak to send those emails to your junk folder.

Not sure exactly what you are trying to do here. The spamcop report is going to the proper abuse desk so I wonder why you were concerned about the exact IP address - except out of curiosity or in an effort to understand the spamcop parser logic. Now since you are asking about gmail filters, you might be trying to identify spam that is evading filters.

If you have a specific purpose in mind, perhaps, if you stated it, you would get answers that more directly address your purpose.

Miss Betsy

my question is not about gmail but qmail the linux based email agent.
We use qmail in our server and we use spamcop to reject spams.

The reason that I am asking is to see if qmail actually uses the same mechanism to find the ip address in an email and then decide to accept or reject an email by asking rbldns for status of that ip.
Does it look at the header or does it just check the ip of connecting(sender) smtp server?

If it checks the later ip address (in this case 212.52.128.2) what is the point of spamcop selecting 212.52.155.35 as spam ip?

If email servers only check the rbldns servers for the connecting ip address, shouldn't the spamcop only list those ips?

It is most likely going to base its lookup on the "connecting" IP address.

However, you generally don't want to block an ISPs main outgoing MX because a few spams got relayed through it from their own IP space. That would be like blocking all mail from AOL's MX because a few spams get sent out, which would most likely be a high "collateral damage" situation.

You are far better off to report the original injection point, as detected by spamcop in this case, and let the ISP deal with those few like this.

In most cases, spam is sent "direct to MX", completely bypassing an ISPs MX server, so in those cases, IP based connection filtering would pick up those machines listed on a blacklist and refuse the connection.