Where's The Backup Plan For Stopping Spam?
from the plan-B? dept
Normally, if you're trying to solve a difficult problem, you have a few different plans. If something doesn't work, you need to be ready to move onto plan B. I've been asking since the CAN SPAM bill was passed, how is the government planning to measure how successful (or not) it's been - and what's plan B? Now that it's becoming increasingly clear that CAN SPAM hasn't been even remotely successful - and has basically done nothing to slow down the rise of spam, I want to know again, what is the government's plan B? They were so proud of themselves for passing CAN SPAM, yet they included no money for enforcement, no way to measure how successful it was, and no plan B. In other words, yet another law that makes for a good press release, and a good sound bite at election time, but does nothing to solve a problem.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Reader Comments
Subscribe: RSS
View by: Time | Thread
uh, hate to be the cynic here ... but
This act is nothing more than a "how-to" guide for the slimeballs at the Direct Marketing Association which guides them in "best practices" for ensuring they can't be sued by companies forced to spend thousands of dollars and man-hours stopping the theft of hard disk space and bandwidth, not to mention employee productivity.
Laws passed by any nation have no effect on the Internet anyway; laws "outlawing" spam in the United States have no effect in other countries.
The only way SPAM will ever be reduced is for the blacklist community to blackhole entire ISPs once it has been proven that they are friendly toward spammers.
Once that occurs, the price an ISP pays for not monitoring the use of its resources by its customers and enforcing its terms of service will guarantee spammers have no homes from which to operate.
[ link to this | view in chronology ]
I have an idea...
What if we used a simple keyword system, where, in addition to your email address you would hand out a random sequence of characters as a passkey. This passkey would be embedded into a header field in the email. You could have as many of these passkeys as you like. Coworkers could have one, friends and family could have another. You could generate new ones for each mailing list you were on. If an email arrives without a passkey, you could safely ignore it. If a passkey is sniffed or leaked, you could change it without changing your email address.
For unsolicited emails, your web server could have a simple request system, either as a web-form or as a system like mailer daemons, wherein you could send it a request and it would email you back a one-off passkey for me. After that one email is sent, we would accept no new emails from that passkey.
This way I could still cold-email someone (by sending a request to them or their server,) and getting permission to email them, but everyone else I wanted could be preapproved.
I haven't spent much thought on this idea, so I haven't spotted all of the possible holes in it, but here are the advantages and disadvantages I see:
Advantages:
1) Minimal network and processor overhead.
No significant change in CPU usage as we are just checking a passkey. The only increase in network overhead would be on requests for one-off passkeys, but I think this would be more or less minimal.
2) Doesn't require implementation at an ISP level. This scheme could be handled entirely in the client, although ISP level implementation would probably make things a bit faster and easier.
I haven't heard of a suggestion like this yet, but if anyone is interested, I make this idea public domain, and promise not to patent it or sue anybody :)
[ link to this | view in chronology ]