Slashdot Mirror

I strongly approve.

The RIAA assumes that each copy of each song is worth a dollar and is independently covered by copyright violation fines. This couldn't be farther from the truth. People end up with freely obtained music that they would never (in any world) pay for. Separately, the immature behavior of the RIAA (primarily their scare tactics and markup) couples with the enormity of copyleft content now freely available to spell a significantly reduced value (supply and demand). We're heading towards a new media paradigm that just doesn't have room for the RIAA.

I think by calculating the value as perceived by the RIAA, we have this on display for all to see. The press and the courts will have no choice but to see this for the fear-mongering death flails of a dying industry.

Talk about shooting themselves in the foot — they may have just blown off their whole leg — and the ground they stood on.

If a major player, usually seen as a freemail provider like google or yahoo, but certainly also any large corporation or government agency, were to simply start reporting their spam, the problem would go away.

Beef up and aid services like KnujOn and SpamCop and remove the ease of sending spam and (more importantly) the profitability. But that only goes so far -- it nails the pseudo-legit spammers, but it only slightly hampers the straight-up criminal ones (while eliminating their competition).

The next step is escalation; like Blue Security, create a do-not-email list (using hashed emails for privacy) and then after a lack of response from SpamCop's reports, utilize the opt-out requirement of the CAN-SPAM law to essentially flood the spammer with unsubscribe requests. I've detailed this proposal, along with how to decentralize it to make it immune to the DDoS that stopped Blue Software, on my website at http://khopesh.com/wiki/Ending_spam

I've actually proposed something very similar to this before, called a Solicited Bulk Realtime List, which would be an elaborate DNSBL-style spamtrap whose purpose is determining which lists play fair (no-unsubscribe vs opt-out vs opt-in vs confirmed-opt-in) regardless of solicitations. Such an index would enable users to safely unsubscribe, and perhaps more importantly, its widespread adoption would force all "list" emailers, be they spammers or not, to better implement subscription management.

SBRL would also enable the ability for a filter to set a threshold for new list mail. Let's say I completely block any "list" mail that the SBRL can't confirm unsusbscribe works, and then I count a day's incoming confirmed-opt-in emails plus twice the number of the remaining emails (opt-in/opt-out). Anything over my threshold gets digested just like a mailman list with the digest feature (a collection of all of them that came in over the day) rather than direct delivery.

An IT-grade implementation could have new addresses start at a high threshold (e.g. 10) and then lessen by one per business day until it hits the default threshold, e.g. 3.

Keep the thing updated, and set auto-updates to do dry-runs and email you what they could do. ... I actually have a nice shell script for that ... ask me and I'll post it online for you.

Yes, please post it or email it ... I've got a dozen or so Debian servers that could benefit from it regardless of the new storage box. Thanks in advance.

I run this from a bash script /etc/cron.daily/apt-update which delays 30-60 minutes and then runs the main script. Note that $RANDOM, and the hash function need bash and won't work in dash/sh. The cron script's code looks like this: sleep $(($RANDOM % 30 + 30))m && /usr/local/sbin/apt-update -m ... I'm not even going to try to put my apt-update script here as a slashdot comment.

This is my first public release of apt-update, released under the GPL. Also note there are other similar solutions, like apticron and cron-apt, both of which are in the Debian stable repository, but both of which seemed more code than is needed (and they are primarily for actually performing the upgrades, which is dangerous).

On RHEL/CentOS, Fedora, and other APT-capable distributions, this script will work fine. There is one snag; the script searches for "security" in the dry-run install ... DAG/Dries/RPMForge, FreshRPMS, CentOS, and ATrpms don't have a specially reserved source for security the way Debian does, so this won't work. Also of note, Axel Thrimm's atrpms package for most Fedora/RHEL derivates includes a script called "check4updates" which was the inspiration for my script. ... it is a bit more basic, but it uses what it can find of up2date, yum, apt, and smart.

Even the reporting page appears to have Cross-Site Scripting (XSS). Here's a screenshot as proof.

hmm... i think i just reported myself as a phisher by following my own link...

i made a site similar to this a few years (five?) ago and updated it for 3rd edtion D&D last year:
http://khopesh.com/dnd/sim3e.html

your link is interesting and very similar, although I don't like the yes/no aspect of it.