Spamex on Spamcop (or Why Spamex does not support the use of Spamcop.net)
CEO, ClicVU, Inc. (Providers of the Spamex Disposable Email Address Service)
December 16, 2002
We at the Spamex Disposable Email Address Service have always felt a certain camaraderie with Spamcop.net and others in the business of helping people deal with unwanted email. Sure we are competitors, but we are, after all, working towards the same goal. As of late however, Spamcop.net has fallen out of our favor for a number of reasons, some technical and some policy as explained below.
We have a few long-term technical issues with Spamcop incorrectly identifying Spamex as the source of spam when our users reported spam to Spamcop that was received through a Disposable Email Address. This does not happen often, probably because most people do not report spam received through their DEAs, but rather just turn off the compromised DEA. Spamcop has also been fairly responsive whenever it has resulted in a blacklisting, so while annoying it has been manageable.
Recently, however, Spamex found itself unable to deliver email to anyone who subscribed to the Spamcop RBL (Real-Time Block List). Why? Because another customer of our ISP had been blacklisted by Spamcop due to reports that they were sending spam.
What does that have to do with Spamex? Well, nothing actually, except that Spamcop has a policy of listing a broader range of IP addresses than those actually in use by the reported party as a way of trying to apply pressure to the ISP to deal with the Spammer. Spamcop.net is knowingly and intentionally harming uninvolved parties in an effort to exert pressure on another party or parties. Isn't this the same twisted logic that terrorist use?
We figured that this would be easy to resolve by requesting that Spamcop whitelist our servers (not that we should have had to ask for whitelisting since we were not involved in the first place) so we contacted spamcop.net the morning that we became aware of the problem and received no response. We contacted them again in the evening and were told by Julian Haight (the owner or Spamcop.net) that
"I have decided to allow these listings to stand in order to put pressure on upstream providers"
At one point the Spamcop RBL seemed like it had potential. It was quick to list spammers and quick to remove the blocks when the spam stopped. In contrast to SPEWS and its policy of not removing netblocks even when they clean up, this made it one of the better RBLs, if one is going to use an RBL. However, by knowingly listing uninvolved parties, Spamcop has, in our opinion gone the way of SPEWS and rendered their RBL useless. Most people cannot afford to use an RBL that intentionally blocks email from hosts that have not been reported as spam sources but rather just happen to be in the wrong place at the wrong time. This causes too much collateral damage.
We were very surprised to find how many of our users were not receiving mail through their Disposable Email Addresses because their ISP, without the users knowledge, was subscribing to the Spamcop RBL. Our users were a bit surprised as well and a fair number of them are off to have a chat with their ISPs about this.
On an ironic related side note, most of the ISPs were blocking Spamex do to the Spamcop RBL listing were returning a 4xx error to our mail servers which just causes the email to be held in queue for later delivery. If this is in fact how people are using the RBL, then their methodology is as broken as Spamcop's as that does not stop the spam, it just defers delivery until the sender is removed from the RBL.
Please send any questions or comments to SpamcopRBL@spamex.com
Follow-up (December 18, 2002): Someone at Spamcop (not Julian) did ultimately whitelist the Spamex SMTP servers and the whitelisting is still be in place as of this writing, however our /27 IP block is still listed in the Spamcop RBL and our other, non-spamex SMTP servers are therefore still blocked.
Follow-up (December 18, 2002): Spamcop has delisted the /27 belonging to the Spamex Disposable Email Address Service. Their policy regarding expanding listing beyond the IP range of the reported parties remains the same.