(Note: this topic involves the SCBL, "SC Reporting," and even SC email accounts, so if a wise moderator chooses to move it, I'll understand. However, please don't move it to the SC Email forum, because the other two categories have much more to do with this issue.)

I have some SC email accounts which use SpamCop Blocklist listings as one factor in filtering messages and redirecting them to a "Held Mail" folder. Like millions of other people, I've downloaded OpenOffice.org software and they occasionally send me emails, but sometimes these messages wind up being diverted to my Held Mail due to SCBL listings of their outbound mail servers. This happened again today, so I logged into my SC Reporting account and looked up the details about the blocked IP (204.16.104.2).

Sure enough, it's currently listed:


So I took a look at the Report History and found these:


The "[users]" denotes the "Users Mail List" at OpenOffice.org, which is mentioned here:

http://support.openoffice.org/index.html

So, I thought, maybe they're not being careful about unconfirmed subscriptions, so I sent an email to the "users-subscribe" address and I then received a "Subject: confirm subscribe to users[at].." message back (had to dig it out of my Held Mail, actually), which demonstrated that the SC users who are submitting those reports were most likely confirmed subscribers to the OpenOffice.org "Users" mail list and have been reporting the list messages they are receiving as if they were spam. This is why that IP is currently blocked and I contend that it's due to misreporting on behalf of those users. If they want to unsubscribe from the list, they can, but they shouldn't be reporting those messages as spam, and this should be looked into by the Deputies (please?).

I also took a look at the SenderBase stats on the IP and they are benign, and a lookup at the Multi-RBL check (http://www.robtex.com/rbls.html) showed only the SCBL listing.

Regarding the contact info for that IP, yes, I see that there's a problem there preventing SC reports from reaching the responsible parties, but that's a secondary issue...the reports probably shouldn't have been generated in the first place.

The SpamCop BL is a useful tool, but not when it's being fed by careless users. I've seen this happen before with list subscriptions, and the denizens here are often quick to defend the SC reporting users. I don't think that reporting messages from a list to which they have willingly subscribed is defensible.

DT

Hi David,

It does look as though some user(s) are reporting stuff they have signed up for.

If the responsible admins for the list aren't receiving the reports then they, obviously, cannot challenge them. So the matter you mention does contribute to making the problem worse. But clearly these forums can only debate the rights/wrongs.

The responsible person(s) need to contact the deputies to resolve the matter and challenge the mistaken reporters. Presumably those filing these reports could lose their reporting privileges unless they have a reasonable defence (although I'm not sure what that could be).

Andrew

Mostly true, except that when an SC admin drops by, the possibility exists that they could look into things further.


I'll try contacting them. However, the contact information being shown on that IP in the SC Reporting system seems to be incorrect (outdated). When I query ARIN on that IP, I show different contact info (a "collab.net" address) than what's being shown in the SC system (an "ethereal.net" address). I see that the ARIN info was updated three days ago, and the old info (which is still cached at DNSStuff.com) shows the "ethereal.net" address. Therefore, whenever the SC system starts pulling the more recent contact info, then the people responsible for this IP should start to receive reports. Again, it's possible that a SC admin might be able to correct (or refresh) the outdated contact info being used by the SC reporting system.

DT

Yet another issue .....
Parsing input: 204.16.104.2
Routing details for 204.16.104.2
[refresh/show] Cached whois for 204.16.104.2 : tristan+dns[at]ethereal.net
Using abuse net on tristan+dns[at]ethereal.net
No abuse net record for ethereal.net
Using default postmaster contacts postmaster[at]ethereal.net
postmaster[at]ethereal.net bounces (8 sent : 7 bounces)
Using postmaster#ethereal.net[at]devnull.spamcop.net for statistical tracking.

I hit the 'refresh' link ... now shows;

Parsing input: 204.16.104.2
Routing details for 204.16.104.2
[refresh/show] Cached whois for 204.16.104.2 : hostmaster[at]collab.net
Using abuse net on hostmaster[at]collab.net
abuse net collab.net = abuse[at]collab.net
Using best contacts abuse[at]collab.net

How about perhaps doing some research on just what/who the correct address should actually be ....

Edit: see that research/work/posting was being done at the same time ....

Yes, and as you reported, it looks as if the SC reporting/parsing system is now displaying the correct contact address for that IP. Unfortunately, due to the lag in the updating of the contact info, all of those recent SC reports went to devnull, so the server and list admins haven't received the necessary information from SC.

I've sent off a message to the Abuse address at collab.net as well as the list owners, telling them of the apparently bogus spam reporting and the listing in the SCBL and I suggested that they contact the Deputies. It's a little odd that the contact information for the IP happened to get magically updated only minutes after I posted this topic....hmmmm....a suspicious mind would look to see if a SC admin has been lurking.... [on edit: Wazoo explains the phenomenon below...nothing suspicious about it at all]

[on edit] update: I received a very quick response from an OpenOffice.org rep:


DT

Perhaps you missed the tidbit I typed in there ... I hit the 'refresh' link ... now shows;

Sort of...I actually had no idea that when one user does that, that it would update the information for other users. So, I could have helped out by using that same link, I suppose? (although not in time to have had any effect on the devnull'd reports of the SCBL listing) I've never used the "[refresh/show]" link before, and so am not very well informed as to its potential ramifications. Now I'll have to go looking through the FAQ to see if it's mentioned anywhere. :-)

DT

1. Reporting messages from a list they have subscribed to is a punishable offense. That is one of the options the receiver of the reports has.

2. It is also possible that in this case, the person reporting has not signed up for this list but instead currently has an address that once belonged to someone who subscribed. IF (and it is a big if because I don't think it is likely what is happening here) that is what is happening, the list should be responsible to drop addresses from lists if they bounce more than a couple times in a row.

3. I think it is more likely someone has some scri_pt written to auto-report any messages with certain characteristics (like being blocked by SpamCop) and they don't even know they are doing it.

Yes, and I'm confident that they're already doing that. However, this issue doesn't involve bounces.


Possible, but if so, they should certainly lose their reporting privs, because they're responsible for harming innocent third parties. I hope that a SC admin can close this case by reporting exactly that.

DT

And how do you know they are doing that? Does it state as much in their documentation? Have you asked anyone?

In my experience, the bulk of mailing lists do NOT do this sort of maintenance. This year, I had an account at work that had not existed in over 5 years. A new employee started that had the same email address in the short format and in the first day they had messages from 3 different lists appear in the inbox that the old user had signed up for. I immediately changed her email account to a non-standard format (for our company) and reported the messages (manually) stating the facts of the situation. Never did hear back from any of the list managers and I have not tried that address since, so do not know the resolution.

I supended the user responsible for the false reports.

The list server at 204.16.104.2 is not currently on our list, so everything should be OK going forward.

- Don D'Minion - SpamCop Admin -

Thanks Don ....

Wow! Thanks for the quick and prompt action.

It wasn't someone by the name of William Gates, was it?

Wasn't that the guy who promised, 2 years ago, that spam would be eliminated by 2006? Gates believes ...

Let me also add my thanks to the growing list. I also know that the folks at OpenOffice.org are much happier now that both issues are cleared up (the problem with the reporting address and the false reports). I've been in touch with them since starting this topic and they asked me for advise on preventing this in the future. I think they realize that as long as any further SC reports are brought to their attention, they can then react to any false reporting. I'll also suggest that they inquire about adding an additional address to receive reports, if they think that's necessary.

DT

...Glad this worked out! <g> I am marking this topic as "Resolved."

Well....it *was* resolved, but there still seems to be a SpamCop user who submits the OpenOffice.org announcements as spam. Here's the most recent:


I have alerted OOo, Collab.net, Sun, SC Deputies and the Royal Canadian Mounted Police. ;-)

Looks like maybe there's another SC reporting user who needs to have their privs suspended.

DT

There's always somebody that doesn't pay attention to what they are doing. Maybe a brief suspension will encourage them to pay more attention to what they are submitting.

Just got a response back from Don D'Minion, SpamCop Admin. He confirmed that since that initial user suspension, that at least four other SC reporting users have been reporting the OpenOffice.org newsletters as spam. Indeed, I just checked the recent reports for the IP address in question, and there's a SC user in Arbedo, Switzerland who just reported one on Jan. 30th, but his reporting privs have not been suspended, nor have those of the three others.

However, Don CC'd the reporters (using the internal Spamcop addresses associated with specific reports) and the OOo list admins to whom I'll be suppying the personal addresses of the four reporters and I'll suggest that they preemtively scrape them off any and all OOo lists, lest they continue their false reports. It frustrates me when other users carelessly abuse the SC system, especially since I'm currently unable to report any spam due to a dispute with Don over the "material changes" clause.

I'll be interested to see if any of the four reporters respond back to me.

DT

We still have a stupid SC reporting user who is reporting the OpenOffice.org newsletters as spam. I just did a lookup on the IP address [204.16.104.2] and found a report from 22 Feb:



Looks like maybe SpamCopAdmin might need to use his "cluestick" on this user (again?). At least it's only one idiot this time, and the IP didn't wind up on the SCBL as in the past.

DT

Months later, and there's STILL at least one stupid SpamCop Reporting System user (maybe more) who submits each and every OpenOffice.org newsletter as if it were spam...they're NOT!

Latest:


It would be nice if the SA Admins would take some punitive action against these false reporters.

DT

As I mentioned before, perhaps this user is not the original owner of the address this is being sent to. In that case, it is reportable spam. I have not gone back over this topic, but have you contacted the deputies and gotten a response on this issue? Continuously complaining in a user to user forum will not help anything.

Time for an attitude change!

Reply to my request for the deputies to investigate/comment:

figures

Aw, c'mon...that's pure hypothetical speculation. It's MUCH more likely that they're just reporting stuff without being careful...it happens ALL the time! I've produced PLENTY of proof of that here before.


I put the OpenOffice people and the SpamCop people *and* the IronPort people all in touch over this last year. Yes, there was plenty of communication. What we have here are users making bogus reports.

DT


Quoting Ellen:

Been there, done that. In fact, Don D'Minion revoked the reporting privs of one of the boneheads who was doing this before. That was in December, 2006. Then, over a month later, it happened again, so I alerted both the OpenOffice.org people and the SpamCop Deputies. Don got confused at that point and broacast my personal email address to the four errant SpamCop reporting system users (Merlyn, that should help explain part of the "attitude" issue).

As for Ellen's Q about the nature of the lists....to quote one of the OO.o admins:


Any questions? I know what I'm talking about here....the reports are bogus. As a SpamCop user (and paying email customer) I get frustrated when I see misuse of the SC system.

DT

It is good for the Open Office people that you are keeping tabs especially since spamcop doesn't, apparently, keep records of prior communications.

However, why are the OpenOffice people not doing something when they get spamcop reports? I know many whitehat admins don't like spamcop reports because they are almost always reporter error. What I don't understand is why they can't politely tell the reporter/spamcop. It seems to me that the spamcop method of reporting spam is infinitely superior to other methods of spam filtering where there is no way to find out /why/ an email didn't make it. The problem is that it is not easier for the server admin, only the customer.

OpenOffice admins should be looking after the interests of all the OpenOffice subscribers (the customers) who are responsibly subscribing and unsubscribing by chasing down the ones who aren't and are causing newsletters to be considered spam. At least with spamcop there is a report and therefore a heads up. With systems that just 'learn' from 'this is spam' button pushers, there is no way to know why suddenly a newsletter is not going through to the ones who have subscribed responsibly.

Miss Betsy

Now, Miss Betsy's tone and point is much more reasonable, and if I were part of the OpenOffice.org team, I'd probably be doing exactly what she suggests. However, they've done nothing wrong, and they shouldn't really have to. My primary point is that there are people using the SC reporting system who are careless and who are damaging the reputation of the SCBL by their carelessness.

DT

And the only way these things get fixed (i.e. incorrect reporters get punished) is when the reported parties, complain about the problem. If OpenOffice.org is receiving invalid reports, does nothing, and ends up listed, part of the responsibility is theirs and the major inconvienience is also theirs.

They need to provide the proof to spamcop that the reporter is the person who signed up. Then the reporter can be dealt with.

Sounds reasonable, except that it winds up costing them money in staff time to refute the false reports, and that's inherently not fair. Can you imagine how much money is wasted every year on frivolous lawsuits? They wind up costing real money for the innocent defendants, unless things progress far enough to the point where a judge orders the plaintiff to pay the legal costs.

I'm not sure that organizations such as OpenOffice.org have any choice but to spend the time and energy necessary to defend themselves from false SpamCop reporting. The people responsible for their outbound mail servers are receiving reports and may very well be challenging them...only the Deputies would be able to determine that. As a SpamCop Email customer, I want the SCBL to be as accurate as possible, and it irks me to see continued false reporting of messages that are clearly NOT spam. I've commented here to add to the "historical record" for others to stumble upon, in order to document that not all of the reporting that feeds the SCBL is valid, and should be questioned. Too often, I see the denizens here defending the system as if it were more perfect than it actually is.

DT

Part of the cost of doing business.

I agree with you here. It is spamcop's (user or admin) reporting process that is at fault here. Openoffice mailing list managers are doing it the right way. I hope spamcop's admins will rectify this problem...

raju

I do not agree. the proof is on them not spamcop.

Life's not fair. I shouldn't have to report spam or JHD. The point is (and your point also) that if everybody did what they were supposed to do, the system would work better. Everyone makes mistakes so both reporting and responding to reports needs to be done.


Life isn't perfect. A while back a mailing list manager of a PAID list posted here wondering why someone who /paid/ for the list would report the newsletter as spam!

Miss Betsy

In the USA, it's generally "innocent until proven guilty," Merlyn....NOT the other way around.

DT

That may be true in criminal court, but doesn't generally apply to other areas. Espcecially where the internet is concerned, a much better policy is suspicious until proven otherwise.

As you yourself said, we are not talking about a huge volume here. One or two reporters in a six month period causing a problem for a large mailing list is certainly not an unreasonable volume to deal with. All it reaquires is someone to click the link in the report and tell the deputies that the reporter has subscribed to that mailing list. If they want to save a back-and-forth exchange, they can even provide evidence of the subscription in that first email and the deputies will handle it from there.

True...not a huge volume, but it was enough when this all started to put their server on the SCBL, and it appears to be more than "one or two reporters" (but not a lot more). I've kept on top of this particular situation to document that there's a problem with the choices made by at least some SC reporters (so this topic could actually be taking place in the Reporting forum, had it not originally involved the BL).

I'm thinking that with some proven "white hat" servers, an "alert flag" could be triggered for Deputy inspection when people report them....but that's probably a "feature request" and I don't think it would have much of a chance of getting anywhere.

DT

In the US, I have to show proof of identity if I want to use a check to pay for my purchases and I have never, ever written a bad check.

Business owners have to do all kinds of things (which are added to the cost of purchases for 'innocent' customers) to protect against the few bad hats. Internet businesses must realize that doing business on the internet also creates costs.

Spamcop does its job by notifying the business that there is a report. If it is erroneous, then the business needs to do something about it to protect its other customers. When it is not erroneous, then the business needs to correct the problem. Spamcop does fine and suspend users for erroneous reports, but cannot do so if it is not notified. The problem with a 'flag' is that if there is a mistake on the sending end (and people do make mistakes like when changing servers, forgetting to turn off the open relay), the business is not promptly notified - the entire purpose of spamcop particularly for whitehats.

Miss Betsy

...DT, the only thing I can suggest is to keep working on Don and the Deputies. Complaining in a user forum does not really get the problem fixed (although I appreciate your alerting us users to this problem, even if we sometimes seem to not want to hear it).
...Good luck, I hope this eventually gets resolved to your satisfaction -- I don't think any of us wants SpamCop to get the reputation of permitting repeated false spam accusations.

Thanks, Steve. I'll try to take your advice, but Don and I have some "issues."

A propos to this topic, in another topic/thread, I had identified a LOT of false reporting of the occasional newsletters sent out to registered users of the JAlbum web photo album software. Another newsletter just went out yesterday, and so I checked for SpamCop reports on the IP of the sending server, and sure enough, there were two false spam reports:

Submitted: Friday, June 08, 2007 10:32:35 AM -0700:
JAlbum newsletter: Skins and Photo book

* 2325434771 ( https://jalbum.net/skins ) To: ripe[at]bahnhof.se
* 2325434767 ( https://jalbum.net/donate.jsp ) To: ripe[at]bahnhof.se
* 2325434766 ( http://jalbum.net/skins ) To: ripe[at]bahnhof.se
* 2325434760 ( 213.136.35.49 ) To: ripe[at]bahnhof.se

Submitted: Friday, June 08, 2007 6:46:22 AM -0700:
JAlbum newsletter: Skins and Photo book

* 2324737065 ( 213.136.35.49 ) To: ripe[at]bahnhof.se

I have alerted the owner of JAlbum and suggested that he obtain the reports from BanHof.se. I suggested that he challenge the reports.

It *really* irritates me that there are stupid reporters out there submitting false reports that feed the SCBL.
Some of you may think otherwise, but....you'd be wrong.

DT

Another OpenOffice.org newsletter was sent out today, and yet again, we have stupid SpamCop users (actually only one stupid user so far, but give it time) reporting the message as if it were spam (and it's NOT!).

Submitted: Monday, September 10, 2007 2:46:34 AM -0700:
[ooo-announce] IBM joins the OpenOffice.org Community

* 2491061634 ( http://www.openoffice.org/press/ibm_press_relea... ) To: abuse[at]collab.net
* 2491061630 ( http://www.openoffice.org/press/ibm_press_faq.html ) To: abuse[at]collab.net
* 2491061627 ( 204.16.104.2 ) To: abuse[at]collab.net

I'll contact the Collab.net abuse folks and let them know that they ought to nip this in the bud, before their IP address winds up on the SCBL again.

DT

Update: a helpful forum user suggested that I bypass the Deputies and send some queries to the "reports.spamcop.net" addresses associated with the bogus OpenOffice.org spam reports. I just did, and I received a positive response from a mail server admin, who said that he would:



DT

...If I were a spammer, that bit of information would be very valuable to me, wouldn't it? <frown>

Good point - time will tell. I suspect the overwhelming majority of the little baskets don't work that hard at their 'trade', on the assumtion that one of them would own the observable universe by now if they did. I guess this becomes an inadvertent test of that hypothesis.

To be honest, it's that other bit of How to .. that got my attention. Yes, the capability was always there to 'use' a Report-ID, but ..... that it's now been pointed out clearly, with a suggested usage ... a bit of an ouch there possible for some ....

Update: another OpenOffice.org newsletter went out today and lo and behold, two idiot reporting system users have already reported it as if it were spam. I've sent queries to:

(removed)[at]reports.spamcop.net
[second address removed on edit, because the user responded--in ALL CAPS, what a....--and promised to stop]

asking them why they keep reporting these non-spam items as spam and told them that I'd report them to the deputies. I'm tired of people being allowed to report non-spam as if it where spam, so I guess I'll just keep after these idiots until they either stop on their own or get the deputies to hit them with a clue-stick.

Another update: I checked the reporting history again and another user has carelessly reported the OOo newsletter:

(removed)[at]reports.spamcop.net

I've written to them and am awaiting their response.

[update] Got a very nice response from the most recent reporter, confessing to his mistake and promising to be more careful. I'll take another shot at this when the next OOo newsletter gets sent out. I think that reports on obviously good senders such as OOo should be flagged by the system for Deputy intervention/action.

DT

Heh, winks and nods to blind horses etc (previous post). Yet the clues have been 'out there' for ages (easy enough to say in retrospect, to be sure), I thought Don had even mentioned it in clear terms recently but I must have been mistaken. Not something to add to the FAQ/Wiki presumably - yet what is the harm, actually?

The "you could use yours" thing was the somewhat given. It was the "you could use someone else's" that has never been specifically pointed out before (on SpamCop.net turf) ..... the general thought being .. only someone devious would even dare think of such a thing ..... that naive, trust thing yet again I suppose ..

The last time that this actual bit of knowledge came up ... spammers were using those same addreses in their spam directly. Seems like that was over a couple of years ago .... back in the "it was normal to seek revenge" days ....

Thanks for that, and it was then compounded by one or more things going wrong to allow +30 day reports to be used (failure to 'retire' expired report IDs, failure to adequately filter) IIUC.