Why Blacklisting Spammers Is A Bad Idea

Roland Piquepaille writes "For the last two months, an eternity in Internet time, I was unable to reach -- and to contribute to -- Smart Mobs, the collective blogging effort around the next social revolution initiated by Howard Rheingold. Why that? Because an unknown customer of Verio decided it was a spamming site and asked the company to blacklist the site. Verio complied -- probably without even checking it -- and my problems started. It took me dozens of e-mails and phone calls and two visits to the headquarters of my french ISP, Noos, to fix the situation. More about this horror story is available here."

Comments

Re:Run your own mail server on your own domain

[bhtooefr]

RTFA. Verio was doing blacklisting on ALL PROTOCOLS for this ISP. The guy could not even GET TO THE SITE.

That's what I'd call costumer care...

[rune.w]

Quoting from the article:

1. Technical support people don't have access to Internet;
2. They are not allowed to phone to customers;
3. And they are not allowed to send them emails.

Maybe it is a good time to change ISP?

Re:Improperly done blacklist

[l-ascorbic]

I'm assuming that by "running your own SMTP server" you mean you're running one at the end of a DSL line or similar. If so, why don't you use your ISP's server as smarthost and relay through them? Avoids DSL/dialup/dynamic blacklisting, and reduces the strain on your server. Win-win, surely?

Verio = SBF (Spammer's Best Friend)

[NoSuchGuy]

To get kicked from Verio, you have to burn down a network center or something like this. About 500 mails from users to abuse@verio.net for one spamvertized website netmails.com and no action taken ==> They do nothing against spam. They tolerate spam.

Check for yourself: Verio's Listing .

I use blackholes.us to block (port 25) entire countries (cn, kr, tw) and ISPs (Verio, interbusiness.it...) that do not qualify (in my standards) for connecting to my mailserver.

NSG

Re:My own slashdot horror story...

[pyrrhonist]

And you couldn't manually request a new DHCP address because... ?

He probably could, but unfortunately he'll probably get the same IP address. From the RFC:

If an address is available, the new address SHOULD be chosen as follows:

• The client's current address as recorded in the client's current binding, ELSE
• The client's previous address as recorded in the client's (now expired or released) binding, if that address is in the server's pool of available addresses and not already allocated, ELSE
• The address requested in the 'Requested IP Address' option, if that address is valid and not already allocated, ELSE
• A new address allocated from the server's pool of available addresses; the address is selected based on the subnet from which the message was received (if 'giaddr' is 0) or on the address of the relay agent that forwarded the message ('giaddr' when not 0).

Bummer, dood.