Jump to content

spamcop bug - blaming my ISPs IP.


elvey

Recommended Posts

IMO the headers show 64.147.96.99 as the source of the spam.

In the latest Received header server2.fastmail.fm shows that it received the spam from a machine claiming to be frontend3.messagingengine.com however lookups on the IP indicate the server's name is really 64.147.96.99.nyinternet.net. frontend3.messagingengine.com actually resolves to 66.111.4.32. In this case the sending server appears to be lying about its identity.

· Received: from frontend3.messagingengine.com (64.147.96.99.nyinternet.net [64.147.96.99]) by server2.fastmail.fm (Cyrus v2.2.3) with LMTP; Thu, 03 Jun 2004 20:45:12 -0400

I'd stop here and lart 64.147.96.99 as the source, but for a moment lets assume the server isn't lying.

In any event, the next header should show frontend3.messagingengine.com receiving the spam from somewhere:

· Received: from rivendell.westbay.net (rivendell.westbay.net [67.18.66.68]) by smtp.us.messagingengine.com (Postfix) with ESMTP id CC1254ED4AD for <x>; Thu, 3 Jun 2004 20:45:09 -0400 (EDT)

But the header shows smtp.us.messagingengine.com receiving the email instead.

smtp.us.messagingengine.com resolves to 66.111.4.31 not 64.147.96.99 who is the server that passed the spam to the final destination.

The second header would be discarded as bogus if I were processing the spaqm. The chain obviously isn't intact.

Link to comment
Share on other sites

Is SC no longer providing the munged examples of SUBE that causes listings?

Spammers were using the examples to get around spamcop, that's why they aren't shown anymore.

And I think, that if the reports are only from spam traps, nothing is shown at all.

Miss Betsy

Link to comment
Share on other sites

I contacted Spamcop Deputies about this bug a few days ago

about what specifically? Though even I get a bit perturbed about the turn-around time, I have yet to go for "a few days" for a response from one of the Deputies.

So I'm wondering whether they're waiting for you to advise them that NYI has done something, you've done something, or your query left too much unknown ... Unlike Spambo, I wouldn't have gone through the analysis of the snippet of the parse offered (though agreeing with the diagnosis) ... I'd want to see the actual headers ..

Link to comment
Share on other sites

about what specifically?  Though even I get a bit perturbed about the turn-around time, I have yet to go for "a few days" for a response from one of the Deputies.

Yes, they're normally very quick to respond.

I just sent them an email to let them know we have a new IP block we're using, and that it's causing the Spamcop received header parser to identify the wrong IP as the spam source. I provided a sample mail header, and asked if I needed to do something, or if they could update their received header parser to account for it.

Link to comment
Share on other sites

Spambo, thanks, but I'm sure 67.18.66.68, not 64.147.96.99 is the source of the spam. Here's some add'l info you didn't have, showing that spamcop ("SC") assigned blame incorrectly:

Jeremy Howard (who just posted) runs messagingengine ("ME") and fastmail ("FM"); they're related entities. NYI hosts the server2.fastmail.fm server and the frontend3.messagingengine.com servers.

FM has a multi-stage mail receipt process that results in several Received: lines.

Senderbase shows that 64.147.96.99 is 'new'. NYI is white hat. Jeremy has had the rDNS fixed to resolve to frontend3.messagingengine.com. But I just ran the email through SC again and it's still blaming 64.147.96.99.

So what needs fixing? The SC or FM system? What exactly? Any ideas?

My next guess is that FM needs to put its IP in the lower Received: line.

Link to comment
Share on other sites

Spambo, thanks, but I'm sure 67.18.66.68, not 64.147.96.99 is the source of the spam.

I wasn't questioning where the spam came from, I was pointing out where the headers SAY the spam came from.

If you're right, and I'm not saying you aren't, then the problem lies with whoever configured the server to appear to be lying about its name and where it got the spam from.

Link to comment
Share on other sites

Ok, I get your point.

I think the server in the first Received no longer

appears to be lying about its name and where it got the spam from, because of the rDNS change.

Is the chain still broken?

smtp.us.messagingengine.com isn't close enough to frontend3.messagingengine.com for SC to see a link?

They don't tie together perfectly; FM needs to fix that somehow?

Ideally FM would make it so the line would say

· Received: from rivendell.westbay.net (rivendell.westbay.net [67.18.66.68]) by frontend3.messagingengine.com (Postfix) with ESMTP id CC1254ED4AD for <x>; Thu, 3 Jun 2004 20:45:09 -0400 (EDT)

instead of

· Received: from rivendell.westbay.net (rivendell.westbay.net [67.18.66.68]) by smtp.us.messagingengine.com (Postfix) with ESMTP id CC1254ED4AD for <x>; Thu, 3 Jun 2004 20:45:09 -0400 (EDT)

?

Link to comment
Share on other sites

to let them know we have a new IP block we're using

Ignoring all the details thus far, there was a time when Julian had some code in place to deal with "recently discovered" e-mail sources. Basically, an IP showing up would be put into a bit of a probation box for a bit ... if continued traffic was "seen" and no reports, then at some point it would move to a "trusted" (or maybe "valid" would be a better word) ... but any report coming while under "probation" was a killer ... perhaps this "new IP block" has some connection to the parser's condition of not "trusting" the closeness and stuff .... but, adding the details back in, there's still some wonkiness to the IPs and addresses assigned.

Link to comment
Share on other sites

Hmm, that could help explain things.

Anyone have a copy of the spamcop code that was last released? (I heard it was on sourceforge once, though it's probably dramatically different now.)

Unfortunately, that scheme becomes a self-fulfilling prophecy in this case. A lot of spam is sent through FM, and a lot of reporters who are FM users aren't noticing that the reports they're filing (using SC) are reporting FM as the spam source. The IP had many SUBE reports filed against it, last I looked. I'll wager they're 95%+ false reports.

I'm still looking for further guidance. IIRC, there isn't anything on the SC site like a FAQ entry that says how headers should look.

In other words, saying what would be right would be even more helpful than saying what's wrong. My goal is to get SC to correctly assign blame for the SUBE, whether that involves FM or SC changing things.

Link to comment
Share on other sites

Anyone have a copy of the spamcop code that was last released?

No copies of code are available any more.

My goal is to get SC to correctly assign blame for the SUBE, whether that involves FM or SC changing things.

Try emailing deputies <at> spamcop.net. They can probably give more specific information. And let us know how it all turns out so that if someone comes with a similar problem, we know what to advise them.

Miss Betsy

Link to comment
Share on other sites

Anyone have a copy of the spamcop code that was last released?

No copies of code are available any more.

Well, I heard the code was open source'd (GPL'd?), so it is surely still available somewhere.

My goal is to get SC to correctly assign blame for the SUBE, whether that involves FM or SC changing things.

Try emailing deputies <at> spamcop.net. They can probably give more specific information. And let us know how it all turns out so that if someone comes with a similar problem, we know what to advise them.

Miss Betsy

Bug 'em again? Jeremy said he'd already emailed deputies[at] days ago. Hopefully he has heard from them, and will post here, as you suggested I do. [edit: But yeah, not much more the volunteers here can do at this point. Thanks for the links below, wazoo.]

Link to comment
Share on other sites

Hmm, that could help explain things.

Anyone have a copy of the spamcop code that was last released? (I heard it was on sourceforge once, though it's probably dramatically different now.)

http://www.spamcop.net/fom-serve/cache/8.html

I'm still looking for further guidance.  IIRC, there isn't anything on the SC site like a FAQ entry that says how headers should look.

http://www.spamcop.net/fom-serve/cache/17.html

http://www.spamcop.net/fom-serve/cache/368.html

There may be others ...

In other words, saying what would be right would be even more helpful than saying what's wrong.  My goal is to get SC to correctly assign blame for the SUBE, whether that involves FM or SC changing things.
Link to comment
Share on other sites

Thanks for confirming my recollection re. the source.

That's what I believed when I asked for it.

IIRC, there isn't anything on the SC site like a FAQ entry that says how headers should look.

What I mean is ~ where there are multiple Received lines. The links you provided aren't relevant to the problem at hand - the headers are not missing or mis-formatted.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...