The true source of this message

[DavidT]

Those of you who are very adept at understanding the interaction between the reporting system's email parsing, mailhosts, etc., please take a look at the following Tracking URL:

http://www.spamcop.net/sc?id=z793358273zba...b0d3d45c3224ecz

The message isn't spam, but it's from someone in Italy who is telling me that their Internet provider is *not* Interbusiness.it, even though a visual inspection of the Received lines of the message appears to indicate otherwise. The parser is deciding that the true source is not the IP in the first received line:

Received: from host46-15.pool80117.interbusiness.it (HELO fausto) (80.117.15.46)
  by trantor.weblink.it with SMTP; 5 Aug 2005 10:33:33 -0000

but actually the third one (counting from bottom to top, of course):

Received: from trantor.weblink.it (trantor.weblink.it [217.18.0.24])
	by choralnet.org (Postfix) with ESMTP id 9B292C2925E
	for <x>; Fri,  5 Aug 2005 03:35:36 -0700 (PDT)

Please take a look at all the headers (and you'll see that the message is eventually delivered to a Spamcop email account) and explain to me why the parser is deciding that the "Interbusiness.it" IP address is not the source of this message.

DT

[StevenUnderwood]

3: Received: from host46-15.pool80117.interbusiness.it (HELO fausto) (80.117.15.46) by trantor.weblink.it with SMTP; 5 Aug 2005 10:33:33 -0000

Hostname verified: host46-15.pool80117.interbusiness.it

Possible forgery. Supposed receiving system not associated with any of your mailhosts

Will not trust anything beyond this header

Well, to start with, it appears that trantor.weblink.it is not trusted within the parser to reliably report the connecting IP address so it stops there, at least with mailhosts enabled. I believe mailhosts does modify how deep the parser looks for the source.

If you trust that host, the source is 80.117.15.46 with Reporting addresses:

postmaster<at>telecomitalia.it

abuse<at>telecomitalia.it

abuse<at>interbusiness.it

Perhaps interbusiness.it is related to telecomitalia.it. That IP does look like a DHCP served one for the end users machine. weblink.it sounds like a webmail type service that this person is using as his email provider.

[Jank1887]

parser is deciding that the "Interbusiness.it" IP address is not the source of this message.

31345[/snapback]

I think the problem is that trantor.weblink.it doesn't list its own IP address in its received line. I.e., if the line:

Received: from host46-15.pool80117.interbusiness.it (HELO fausto) (80.117.15.46)
  by trantor.weblink.it with SMTP; 5 Aug 2005 10:33:33 -0000

instead read:

Received: from host46-15.pool80117.interbusiness.it (HELO fausto) (80.117.15.46)
  by trantor.weblink.it ([217.18.0.24]) with SMTP; 5 Aug 2005 10:33:33 -0000

it might parse ok. I'm not certain, but I think that if the host isn't one of your mailhosts, lack of that IP in the line causes the 'chain to be broken' and SC reverts to the previous IP.

That's my guess though.

[DavidT]

I think the problem is that trantor.weblink.it doesn't list its own IP address in its received line.

No, I don't think so. I've seen a LOT of Received lines, and the initial "handoff" from one with an IP to another named server is often done without listing the IP of the receiving server. Here are a few from my current inbox:

Received: from winxp ([64.230.106.*munged*]) by tomts40-srv.bellnexxia.net

(InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP

id <20050805014838.XYF1799.tomts40-srv.bellnexxia.net[at]winxp>;

Thu, 4 Aug 2005 21:48:38 -0400

Received: from ns.umph.net (umpublishing.org [67.106.203.*munged*])

by *munged*.com (8.11.6/8.11.6) with SMTP id j74LtTO00423

for <x>; Thu, 4 Aug 2005 17:55:29 -0400

Received: from pc03 (host145-189.pool8259.interbusiness.it [82.59.189.*munged*])by smtp-out2.email.it (Email.it) with ESMTP id 19C5B1BC032for <x>; Mon, 1 Aug 2005 00:28:39 +0200 (CEST)

All of those parsed correctly, no matter how many other Received lines were involved, so your explanation doesn't seem to hold water. Thanks for trying to help, however.

DT

[Jeff G.]

I took the original Tracking URL, clicked the View entire message Link, copied all but the first two lines, pasted into a form configured not to use Mailhosts, and ended up with a new Tracking URL, the parse for which tracks all the way to "message source: 80.117.15.46".

It appears that DT is a SpamCop Email System Customer who also has an account with choralnet.org, and the former got the message from the latter.

It appears that choralnet.org got the message from trantor.weblink.it, his Italian correspondent's smarthost.

It appears that trantor.weblink.it got the message from dynamic host fausto (host46-15.pool80117.interbusiness.it [80.117.15.46]) (which was found in 15 lists (of 260 tested) by dr. jørgen mash's DNS database list checker drbcheck)

DT's Italian correspondent can determine its own IP Address independently.

One way almost anyone can use to determine their IP Address is to browse to

http://www.inter-corporate.com/ip/ and read the info on the left side that starts "Your IP address is:".

A second way almost anyone can use is to browse to http://privacy.net/ and

read the info in the top left corner that ends "is your IP address."

Also, since DT's Italian correspondent appears to be running Windows, a third way to determine its IP Address is to type "IPCONFIG" and tap the "Enter" key at a DOS Prompt.

The info above is confirmed by SenderBase's impression that trantor.weblink.it sends around a thousand emails a day, and host46-15.pool80117.interbusiness.it sends none.

It also appears that the clock on choralnet.org is running 1 minute 59 seconds fast (+/- 4 seconds).

[Jeff G.]

Please ask the Deputies to think about having the Parser trust trantor.weblink.it. Thanks!

[DavidT]

I took the original Tracking URL, clicked the View entire message Link, copied all but the first two lines, pasted into a form configured not to use Mailhosts, and ended up with a new Tracking URL, the parse for which tracks all the way to "message source: 80.117.15.46".

Which is the actual source IP...the connection from which the message originated.

It appears that DT is a SpamCop Email System Customer who also has an account with choralnet.org, and the former got the message from the latter.

Yes and yes....I did mention that in my original message when I wrote "you'll see that the message is eventually delivered to a Spamcop email account."

The info above is confirmed by SenderBase's impression that trantor.weblink.it sends around a thousand emails a day, and host46-15.pool80117.interbusiness.it sends none.

I think we rely a bit too much on SenderBase around here, in that it only "sees" a VERY limited amount of Internet email traffic...a tiny slice out of a BIG pie...and often doesn't show any traffic for dynamic IPs, even though they are the original "source" of many messages. I just sent a test message from my cable connection to one of my email aliases, which eventually arrives at my SpamCop email account. I parsed the message through SpamCop, and it identified my computer's currently-leased IP as the "message source," which is what I'd expect it to do. The reason I started this topic is that the parser did *not* behave as expected with the message from Italy that's the object of the Tracking URL I posted.

So, I'm still left wondering.

DT

[DavidT]

Speaking of SenderBase and dynamic IPs....I just looked up the source of many email worms (Klez) that we've been receiving at ChoralNet. Here's the link:

http://www.senderbase.org/?searchBy=ipaddr...ng=82.60.179.88

It's on the same system in Italy as the source of the message in my original post, and yet, SenderBase has most certainly "seen" email spewing from this particular dynamic host IP.

DT

[Jeff G.]

Let me put it another way. With Mailhosts configured, the Parser sees that the bottom-most trusted server is choralnet.org, and whatever delivered to that server that is not a Mailhost or trusted to relay must be the "spammer". This is a drawback (from your perspective) of using Mailhosts, but it is an asset in that it catches the forgers who use direct-to-mx and chain-preserving subsequent forged Received Header Lines.

[DavidT]

Thanks for trying to explain it to me, Jeff...I'm still a little hazy, but between what Steve wrote above and your responses, maybe I will eventually get it.

I had another message from the same person in Italy that they sent to a mailbox at ChoralNet.org that never made it to my SpamCop address. I just parsed it, and here's the Tracking URL:

http://www.spamcop.net/sc?id=z793406025zd7...9926e181da8cc4z

You'll see that they didn't use the "weblink.it" system, but rather their DHCP host handed off directly to ChoralNet's (previous, we've moved) email host (host2.oneononeinternet.com). In this case, there's no room for the parser to misreport the source, in that there's only one IP address involved.

Having set up my MailHosts is indeed sometimes a disadvantage, in that it makes the parser behave differently. I realize the inherent advantages, but in this particular case, it didn't serve my needs.

DT

[Jeff G.]

I had another message from the same person in Italy that they sent to a mailbox at ChoralNet.org that never made it to my SpamCop address. I just parsed it, and here's the Tracking URL:

http://www.spamcop.net/sc?id=z793406025zd7...9926e181da8cc4z

31371[/snapback]

It looks like, in this case, your correspondent used its local Exchange Server SRV-DEV.DOMAIN2003.LOCAL to send direct-to-MX, rather than using its Outlook to send via a smarthost.

[Jank1887]

Having set up my MailHosts is indeed sometimes a disadvantage, in that it makes the parser behave differently.

31371[/snapback]

So let me get this straight:

If you don't have mailhosts setup, the parser steps through the received chain until it finds one that "doesn't add up" whether that be due to forgery or just poor configuration. If you do have mailhosts, it reports the first received line that follows your last trusted host? Even if the message made multiple hops before reaching one of your trusted hosts? I would have thought that after reaching your last trusted host, it would then revert to the standard method of parsing the rest of the chain, and step through until it reaches the "doesn't add up" condition. At least, up until now I thought's that's what it was supposed to do. Can anyone give me a good reason why it shouldn't?

[Jeff G.]

So let me get this straight:

If you don't have mailhosts setup, the parser steps through the received chain until it finds one that "doesn't add up" whether that be due to forgery or just poor configuration.

31386[/snapback]

Right.

If you do have mailhosts, it reports the first received line that follows your last trusted host?

31386[/snapback]

Yes, it does.

Even if the message made multiple hops before reaching one of your trusted hosts?

31386[/snapback]

Yes.

I would have thought that after reaching your last trusted host, it would then revert to the standard method of parsing the rest of the chain, and step through until it reaches the "doesn't add up" condition.  At least, up until now I thought's that's what it was supposed to do.  Can anyone give me a good reason why it shouldn't?

31386[/snapback]

IIRC, part of the reason for having Mailhosts in the first place was to cut down on forgeries. Thinking of the "last trusted host" as being "your MSP's front door" (where MSP is a Mail Service Provider), whatever non-trusted host delivered the mail to your MSP's front door is what your MSP wants to see on the SCBL if it's delivering enough spam, and the admin of that non-trusted host is probably more likely to be able to take effective action (and send nastygrams downstream with backup documentation like mailserver log snippets) than the admin of the end-user IP Address that's probably an open proxy or zombie (unless they are the same, in which case there need be no distinction).

[Farelf]

Is there a problem with this one? The following case identifies "my" spam source as 32.97.166.40 (mx1.prserv.net - which happens to be my service provider, AT&T, and surely my exchange server wouldn't be sending me spam?):

http://www.spamcop.net/sc?id=z809264859z1e...54cafbfee4b4e5z

Anyway, even given my limited comprehension it seems suspicious to me, I haven't come across a similar actual routing of my email before. The first link in the chain, maximilian.ns1.com.br ([200.142.252.41]) seems a far more likely culprit (on history) but is marked as a trusted relay by the parser. I see nothing trustworthy past the initial "Received:" actually, the rest I would think is forged. The message ID says it all. This parse is R/S, isn't it? Should somebody in SpamCop be made aware of it?

[Wazoo]

Is there a problem with this one?

I'd rather phrase it "how many problems can one see?" Gads, what a mess! ...

  The following case identifies "my" spam source as 32.97.166.40 (mx1.prserv.net - which happens to be my service provider, AT&T, and surely my exchange server wouldn't be sending me spam?):

http://www.spamcop.net/sc?id=z809264859z1e...54cafbfee4b4e5z

Anyway, even given my limited comprehension it seems suspicious to me, I haven't come across a similar actual routing of my email before.  The first link in the chain, maximilian.ns1.com.br ([200.142.252.41]) seems a far more likely culprit (on history) but is marked as a trusted relay by the parser. I see nothing trustworthy past the initial "Received:" actually, the rest I would think is forged.  The message ID says it all.  This parse is R/S, isn't it?  Should somebody in SpamCop be made aware of it?

33185[/snapback]

There is a bit of a definition thing with the parse output of "trusted" ... but based on looking at the mess, struggling a bit myself in wondering how those headers could possibly have 'accidentally' gotten that screwed up, looking at http://www.senderbase.org/search?searchString=200.142.252.41 ... "someone" will get an e-mail <g>

[Farelf]

... "someone" will get an e-mail <g>

33189[/snapback]

Thanks Wazoo ... it made no sense to me, glad to know that was not all down my own ignorance. I've seen a few of those "messages" lately, this is the first with such bizarre (supposed) routing that I've noticed.

[Farelf]

Several items of concern with this one: http://www.spamcop.net/sc?id=z812463587zd7...82a55114e870e0z

In relation to the parser's Relay trusted (217.72.192.225), this email "message" seems similar to stuff reported in the abuse groups from that server, such as: http://groups.google.com/group/news.admin....c64816c7e455db5

... but the parser skips through to "poor old Verizon". This may be justice, but is it correct? As seems to be standard for the German domain, the From: address appears to be a functioning email address in the domain - I'm not used to that!

Secondly, the largish attachment (+100k) pword_change.zip slips straight through Norton anti-virus without a whisper. Other abuse reports on the German server: http://groups.google.com/groups?scoring=d&...5+group:*abuse* - urge caution, such as: http://groups.google.com/group/news.admin....6c7283581aa8e01

I suspect some sort of nastiness, shan't be opening that attachment of course, suppose I should hunt up my link for "manual submission" of suspect attachments to Symantec (got it here somewhere - very efficient service last time I used it incidentally but there are risks in handling the attachments to the extent required IMO) - I'm guessing it will turn out to be something non-viral. Also, I think I shall be avoiding links from the advertisers on kascus.com (Indonesian forum) in future - though I do know what "bule gila" means now, in more ways than one

But The pertinent point is, is it possibly the "wrong" spammer blamed? Shouldn't the Deputies be reconsidering the "trusted relay"?

[Added - clarifying (belts & braces) it is of course the spam, not the parser message, which is similar to examples in the abuse groups. 2^nd sentence.]

[Wazoo]

Several items of concern with this one: http://www.spamcop.net/sc?id=z812463587zd7...82a55114e870e0z

In relation to the parser's Relay trusted (217.72.192.225), this "message" seems similar to stuff reported in the abuse groups from that server, such as: http://groups.google.com/group/news.admin....c64816c7e455db5

... but the parser skips through to "poor old Verizon".

not sure what's going on, but the parse is showing Comcast as the source ..??? Most believable <g>

Secondly, the largish attachment (+100k) pword_change.zip slips straight through Norton anti-virus without a whisper.

I tried three ways to snag 'your' file and see what I could see ... it was the third time that I remembered your (+100k) remark and matching that against the 50k limit on a submittal ... chasing amd playing with code all day has definitely left me confused <g>( http://forums.invisionpower.com/index.php?...97&bug_cat_id=2 ) But, yeah, standard warnings would apply. A new password for what, for where, and who changed it .... on and on .... Yet, can't get over you talking of a 'no detect' by your anti-virus tool right after another user got excited at me mentioning that scenario ... what timing ...

But  The pertinent point is, is it possibly the "wrong" spammer blamed?  Shouldn't the Deputies be reconsidering the "trusted relay"?

33780[/snapback]

I'll follow your links in a bit, but for right now, even if it is relaying, it does appear to be passing on the right data ...??? more research to follow, or maybe someone else will jump in with already documented stuff???

[Farelf]

not sure what's going on, but the parse is showing Comcast as the source ..???  Most believable <g>

...  more research to follow, or maybe someone else will jump in with already documented stuff???

33781[/snapback]

Thanks Wazoo, my concern is that there is a body of evidence implicating the top server - smtp07.web.de ([217.72.192.225]) - in very similar stuff, therefore is the supposed relay the proverbial "clever forgery"? There is little or no general evidence of clever forgeries per se. Maybe because they're so clever. This is not a good environment for the semi-informed fussbudget (me). All this just in case Comcast (of all organizations) might be wrongly identified. Still, we must have integrity.

[Farelf]

I tried approaching web.de "at an arms length" via Google's "Translate this page" and lo, they seem totally legitimate. Several theories scratched. Still inclined to the notion of random and/or directed malevolence due to the abuse group listings (noting apparently forged headers in those, pointing at other sources/relays as well as web.de commonality) Conjecture is fruitless but maybe web.de has an unconconfirmed opt-in for some service or another, which together with ridiculously large attachments in "confirmation" (why would a legit organization do that?) makes them a perfect tool for such purposes? With a slow modem link I am not particularly keen to test this one (not mention a notable lack of German - Sergeant Schulz/Hogan's Heroes not a particularly good education in this). But that conjecture doesn't fit with the forged headers/relays seen in abuse groups and seems unnecessarily elaborate to be so used?

Simplest explanation is, of course, the parser got it right. In either case, there is a chance others here have seen something similar (hence my concern about correct identification). Think I've just about talked myself into going with the parser at this stage. In which case it is web.de being defamed, more power to SpamCop for revealing it.