Jump to content

Faulty header processing by Spamcop report softwar


Jungleboy

Recommended Posts

I have complained about a faulty header parsing several times to blproblem[at]admin.spamcop.net. Until now, I have not received any reaction, nor is the problem fixed.

Because of this, we are still receiving spamcop reports, stating that

spam email originated from our network, but it was certainly not. Our network just acted as a relay for a customer domain.

This reports are taking way to much time to process, and gives us a bad name, due to the fact that an IP is seen as an spam originating IP, when its not!

Could someone from spamcop react to this problem, and are there more ISPs with this problem?

Link to comment
Share on other sites

An example of where the parser is stopping too soon certainly would help us to see where the problem lies. We are not administrators of spamcop, just users who have experience in what has happened in the past.

If you cansupply us with a tracking URL of a spamcop parse, that would be the easiest way to see what spamcop is "thinking".

Usually this type of problem occurs because your servers are not recording the headers in an RFC compliant way, so spamcop can not trust them and so trusts the headers that received the message from you.

If we can not determine the problem, we can refer you to the deputies who have direct access to Julian (the author of the software). There is also a way to become a "trusted" relay, but that would require good headers first, I believe.

Link to comment
Share on other sites

This post falls into one or all of the following categories:

1. A simple rant.

2. Veno, vidi, abscedere. (Latin for came to see never to come back again!).

3. A spammer who knows they are spamming but refuses to accept the concept of spamming therefore resorting to circular reasoning (see Merlyn post above or Miss Betsy's post bellow).

Link to comment
Share on other sites

Since they are relaying spam for a customer, it certainly seems as though they could do something about it - like stop relaying the spam.

It is the *sending* end that has to be responsible about not allowing spam to be sent. If Jungleboy doesn't like getting reports, then he should do something about cutting off the customer who is sending spam through his relays. Why should spamcop stop reporting?

Miss Betsy

Link to comment
Share on other sites

Too bad people always want to see the bad side of things. This makes a simple discussion rather impossible. But, let me sketch the situation:

- We are an ISP, hosting a lot of sites (200.000+).

- Mr. Someone has a website, and email hosting at one of our customers.

- This Mr. Someone doesn't want to POP several email boxes, so they let our customer forward ALL their mail to the email account they have at their Internet access provider.

- Now, a spammer wants to spam " Mr. Someone".

- This email travels from a open or hacked proxy host, to our network, to our customers server.

- Our customers servers says: "Hey, this Mr. Someone wants all their email forwarded to his access provider email address, lets send it there".

- The access providers mail servers pick it up, and Mr. Someone POP's it to his computer.

Now here is the thing that goes wrong:

- Mr. Someone is reporting the spam email to spamcop. And the header parsing of spamcop, see's the server of our customer as the server where the spam is originating from, but the headers clearly state that its not!

This is not correct, as far as I'm concerned.

If example headers are still required, I will try to post some tomorrow.

BTW, I got 2 replies from service[at]admin.spamcop.net, so I hope they can do something about it.

Link to comment
Share on other sites

Well, it looks like our Mr Somebody is listed in other blocklists for spamming, SpamCop is the least of Mr Somebody's problem, here is what one of those says:

IP address 203.210.152.68 is listed here as 203.210.193.153 misc.spam.

The misc.spam group is mostly (but not entirely) composed of entire addresses blocks that have a) sent spam here, B) have consecutive or missing reverse dns, and c) have no customer sub-delegation via either the controlling RIR (ARIN, RIPE, LACNIC, APNIC, etc) or an rwhois server referenced in the main RIR records.

In particular, 203.210.152.68 has reverse dns of localhost. If your domain name does not appear as the last components in any of those reverse dns names, that needs to be fixed first. Also, none of those names has a forward dns mapping to the original 203.210.152.68. That needs to be fixed. Any email sent to the address at the top of this page will be ignored until that is fixed.

...more block lists can be found HERE!! As for the IP you mention it is correctly recognized as a possible relay: 80.84.226.49, when parsing that example!

I think Merlyn has recognized the problem as well, but stated it so much more succintly than I!

Link to comment
Share on other sites

Reports regarding this spam have already been sent:

Re: 80.84.226.49 (Administrator of network where email originates)

Reportid: 1223156438 To: abuse[at]proserve.nl

Re: http://ifho.5qjl.p25g82-u6emj45mo4pvm.quic...03074/kznfnnbd/ (Administrator of network hosting website referenced in spam)

Reportid: 1223156443 To: abuse[at]mci.com

Reportid: 1223156445 To: abuse[at]mci.com

Re: 80.84.226.49 (Third party interested in email source)

Reportid: 1223156442 To: spamcop[at]imaphost.com

Even though the parse looks as though it recognizes the relay, reports /were/ sent to 80.84.226.49. Sometimes there are glitches that occur because of what the parser looks up. It's hard to tell what the problem was since the parser is realtime.

The third party interested is cyveillance.

Sorry that people were suspicious - I think we all assumed that you were relaying it /out/, not /in/.

However, there is a way to respond to Mr. Someone and let him know that something has gone wrong. I should have thought you would have tried that first.

Miss Betsy

Link to comment
Share on other sites

As Miss Betsy said, it was parsing wrong, but now is accepting your host as a valid relay and pointing to the next host in the chain.

If Mr. Sombody had registered their mailhosts, the parser would automatically expect to see your IP addres in the chain and would not go through all the testing is did.

Link to comment
Share on other sites

If Mr. Sombody had registered their mailhosts, the parser would automatically expect to see your IP addres in the chain and would not go through all the testing is did.

That would be true if the mailhosts process was a bit more trustworthy...which it's NOT. Please see my current topic to that effect in the Mailhosts forum.

DT

Link to comment
Share on other sites

That would be true if the mailhosts process was a bit more trustworthy...which it's NOT. Please see my current topic to that effect in the Mailhosts forum.

DT

17291[/snapback]

Fortunately those errors happen rarely in my experience and a careful reporter spots them quickly, and does something about it.

Link to comment
Share on other sites

Fortunately those errors happen rarely in my experience and a careful reporter spots them quickly, and does something about it.

That's a bit like saying that it's OK to drive your car if you're aware that it has a tendency to catch on fire, as long as you're careful and watch for the smoke and carry a fire extinguisher so that you can "do something about it."

IMO, it would be better if the problem with the car that led to this tendency were fixed, because then there wouldn't be any "damage control" necessary.

DT

Link to comment
Share on other sites

David,

Mailhosts, while not perfect, is much less likely to be affected by external forces (for example slow DNS resolution which at times has actually caused hundreds of incorrect parses at a time). They should probably use a combination, looking at the mailhost configuration and if the host does not exist do the more strict parsing of the last accepted header and the next one.

Please do not "write off" a system which may cause a few problems for one already shown to have weak link causing many more problems. There were days in the newsgroup where nearly EVERY post was that their ISP had been reported because of their reporting. We have not seen the level of problems in the last year or so as there were modifications made.

We have seen very few failures of the new system and it is, from what I have seen, much more "ready for prime time" than the current system.

Link to comment
Share on other sites

Fortunately those errors happen rarely in my experience and a careful reporter spots them quickly, and does something about it.
That's a bit like saying that it's OK to drive your car if you're aware that it has a tendency to catch on fire, as long as you're careful and watch for the smoke and carry a fire extinguisher so that you can "do something about it."

17293[/snapback]

...Well, IMHO it's a bit more like a situation in which you aren't able to buy your own car so you along with many other people use someone else's car, one you find is the best available although it has a few small quirks that appear to be easily fixable but the owner hasn't fixed it and you aren't able to communicate directly with him.
Link to comment
Share on other sites

I wouldn't characterize it that harshly, the deputies or moderators have been prompt and helpful when I stumbbled on the occasional quarcky engine ....and the system seems to improve every day, ever so slowly.. Unfortunately so do the spammer's tricks.. they keep us on our toes at least..

Link to comment
Share on other sites

Well, IMHO it's a bit more like a situation in which you aren't able to buy your own car so you along with many other people use someone else's car, one you find is the best available although it has a few small quirks that appear to be easily fixable but the owner hasn't fixed it and you aren't able to communicate directly with him.

Except for the fact that I'm paying the owner for the use of the car, but these comments aren't really on topic for this thread. I'll continue this in the Mailhosts forum.

DT

Link to comment
Share on other sites

Actually, I don't think if you are an email customer, you are paying for reporting. It comes as an extra. And, if you are a paying reporting only customer, you are making a 'donation' towards the maintenance of the parser.

The same goes for the use of the bl, if you pay for it, it is a donation. spamcop is really for small ISP's who can't afford to create their own blocklists that are sensitive to changes in where spam is coming from. You donate both spam and money, if you can, and get a blocklist.

That's possibly one reason why spamcop doesn't seem responsive to individual reporter problems or suggestions.

Miss Betsy

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...