The admin of the mailing list can set any price he desires to post to it. Since an ML is a recipient multiplier and a fat target for spam, they might choose $0.20 or $0.50 for a message
I don't think it's a leagally tennable idea to make a mailing list charge for messages sent to it. For starters, by charging someone a fee, you implicitly accept a number of responsibilities for the prodcut or service.
You also cannot claim that someone is abusing your service when they paid you the money you asked for. Thus, bulk mailers no longer have to masquerade behind forged headers and such, they just proudly send mail to the largest 10 mailing lists they can find, pay their $2 fee and count their revenue stream....
Very bad, do not do.
And $0.25 isn't too much for a non-subscriber who wants driver help from linux-kernel
No not at all, but who's going to pay $0.25 to ANSWER? No one of course, so only private replies will be sent, but even then it's goign to cost SOMETHING.
Also, you're being US-centric. There are many countries that take part in US-based free software development lists and many other beneficial discussion venues who would be crushed by the exchange rate on a $0.25/per message fee! In some countries that would be enough to buy a meal, and I'm going to answer a technical question or contribute a patch... AND PAY FOR IT?!
Fee-based sending would be the death of electronic mail as we know it, and there are better solutions
You're assuming too much. You mention micro-payments... Would you require that I pay $0.01 per recipient to send a question to the Linux kernel mailing list? What if I send mail to "support@somesoftwarecompany.com" and that happens to point to their external support partner and several internal addresses?
Who collects this? If I have an account with an ISP, do they give me the micro-cash? Wow, I need to get on a lot of mailing lists and fast!
Does the ISP collect it? Wow, I can just see it... hmm, I yesterday the botte-cap-collectors@junkshop.com email list had 2 members, but now "perlscript0x0001@bigisp.net" through "perlscript0xffff@bigisp.net" are subscribed to the list... that's odd. Huh, I wonder who I should send the check to for the $650 that it just cost me to send the "bottle cap of the day" message out.
As long as there's a header that I can set to say "I will not pay the tax, please reject my mail," I'm a happy camper!
I will continue to send email to/from my friends who all run their own servers, and ISPs can go fly. If the IRS thinks that I'm going to pay them for mail that I send from my MTA to my friend's MTA that are both located in our own personal machine rooms, I'll set up UUCP mail and let them figure out if that counts....
Yeah, so sarcasm asside, this idea fits into a class that you should be looking for. Let me quote:
a tax would be an affront to some mythic libertarian "spirit of the internet"
No, a tax would be an unworkable mess that would have so many problems you cannot possibly measure them! Yes, the spirit of the Net is a network of peers who exchange packets at the IP level and let applications decide what to encapsulate, so there's some basic problems there, but then you get into What is mail? Should I tax ICMP? ICMP isn't even IP, it's a sister protocol, but if ICMP isn't charged for then I could just write SMTP/ICMP and encapsulate the protocol in ICMP datagrams (yuck, but it would work). If you tax ICMP, then you're charging me for things like my Linksys firewall rejecting network probes!
The Internet should turn into a penny post, with a levy of 1 cent per letter.
Define post. Define letter. Define pay (if I live in a community in India that's mostly barter-based and there's an email kiosk in the center of town, set up by volunteers....) Assume that the vast majority of my mail comes from a private residence and goes to private residences and businesses, not to public ISPs (which is the case) and try to figure out how we go about collecting a "tax".
I pay a tax for my connectivity, it's called ISP fees. If the US government wants to charge a tax to ISPs, they'll have to talk to the ISPs, but I assure you AOL will lobby against it pretty seriously, so you'd better have your facts in line detailing exactly how it will prevent spam from Russia while also not hurting the consumer.
Rather than punditing, I'm actually contributing to the solution. Please keep your "there oughta be a law" reactionary drivel out of my Internet.
You missed the point... YOU DO NOT HAVE TO UPGRADE PERL.... follow the instructions I gave. That will correctly upgrade just the relevant libraries.
However... WHAT poor history of backwards compatibility?! You mean the fact that 10% of the programs in the world broke when perl when from major version 4 or major version 5 over 10 years ago? Or did I miss some compatibility breakage in the last 10 years?
Compatibility is a major point of pride for Perl, and unless you're relying on unintentional subtelties in the language (read, bugs), I haven't heard about a break in such compatibility. My programs that use the Perl internals from C from 8 years ago don't compile cleanly, but the ONLY reason that's true is that the *C* compiler won't take my broken semi-ANSI C anymore, other than that it works like a charm!
Adding a reply-to is one thing. My mailer claims that I'm ajs@.com, even though it's sending mail from a system, and through an MTA totally un-related to my company. It does this by setting the From address both in the headers and in the Envelope (e.g. the SMTP "MAIL From:" command).
That's called forgery, and it's a perfectly legitimate form of forgery use by most popular mailers these days.
The Register is a rag. Can we please stop quoting from it for anything important?
For simple, Bayes-only systems Paul Ghram has seen false positive rates around 0.03%, and SpamAssassin sees only slightly more than that on it's large database of mail, much of which is often in the database because it's pathologically spam-like.
Systems like Razor2, Bayes and blacklists make the system even more accurate, though often not in ways that are easy for a benchmark to detect (you need to leave SA running long enough for bayes to get trained by the rest of SA; Razor2 is time-sensitive and blacklists change in quality over time).
It was probably a fair number of versions ago. SA now has a daemon-mode called "spamd", since it turns out that most of the startup cost is in parsing the configuration (e.g. all of the rules), and compiling the Perl, of course.
Once you have spamd in use, you cut your CPU usage amazingly (made it usable for my company), and your memory access patterns are much more reasonable for the OS to deal with. Memory is still used liberally, but that will probably change when later versions of Perl start doing CoW more automatically, since a lot of SA's memory usage is simply read-only copies of parts of the message.
Actually, you don't want to do that. If someone says "sluts", then it's a fair indicator of spam, and that word will be weighted appropriately by Bayes. However, if they say "5LUTS", it's MUCH MORE likely to be spam!
Obfuscation in most cases is self-defeating, and only people who thinkg that avoiding this or than specific rule is going to help them bother.
Ooops, in the beginning of that message, I meant "anti-spam too dependent"... sorry if I implied there's an anti-spam-tool universal config file, though IMHO, there should be....
Get used to a mailbox full of... whatever you want, including nothing.
Spam tools are currently at the point tht detection of spam is a near-certainty and the probabilities for false-positives (e.g. good mail getting called spam) are measured in the 0.00n-0.0n% range (that is n in 100,000 to n in 10,000) which can almost always be improved on locally by the user through various means that are anti-spam-tool independant.
SpamAssassin is currently my tool of choice. It's very flexible, can be used with any UNIXish mailer and is just getting frighteningly better over time.
SA's recent addition of Razor2, a Bayesian filter and improved handling DNS blacklists (which SA weights so you can apply them withour worrying about slicing large and useful parts of the Internet out of your field of view) have reduced many concerns that folks had before about active abuse of SA's rule-base in the past. The speed with which this system applies hundreds of tests to a message is also quite stunning, and a major boost to Perl's tacit reputation as a "slow" language.
The biggest problem with SA right now is probably the inability to scale up to the mid-range ISPs and medium-sized business without SERIOUS harware allocation due to the heavyweight neature of its testing. That's my personal mission for SA over the next year or so. My goal is to make SA a reasonable option for anyone that has to process orders of magnitude more mail than your average ISP (e.g. AOL).
When the upcoming 2.54 comes out, I HIGHLY recommend checking it out. You can install SA on most UNIX-like systems, as long as they have Perl installed by typing (as root)
perl -MCPAN -e shell
following the configuration process if you have not done so for Perl before, and then typing
install Mail::SpamAssassin
After that it's just a matter of how you want to configure your MTA to talk to SA. I recommend using SA in "spamd" mode with sendmail and procmail. If you already use sendmail with procmail delivery, you just have to change your.procmailrc by adding rules to invoke SA, and there are good examples of that on the SA site. You can also use qmail (officially qmail doesn't support this kind of thing, but if you use the standard set of patches that most every has to apply, it's reported to work fine) and postfix (though postfix has some complexity when it comes to setting up any kind of uni-directional filtering).
A bunch of folks got me wrong here, and I just want to clarify:
There are two classes of people that one can address in relation to this article: the people who put LFS together (LFS is a documentation set on how to build a Linux system from scratch) and the people who use LFS to build their own systems.
What I was trying to suggest (and apparently didn't do a good job of) was that that SECOND class of people would do much better for themselves by taking joe random distribution (let's say Red Hat, just because they're an easy target, not because they are better or worse in these respects than anyone else) and customizing it by fixing the long-standing problems that have existed since before Linux.
It used to be amazing that you had a system where you could wonder what "ls" did, and so you typed "man ls" and you found out.
That was nice, but those days are now long ago, and we should be expecting more from our systems documentation. Same thing goes for the other things I pointed out (I wasn't saying: go fix ssh/sudo/pam, I was saying that the broken integration between them was a good example of a class of problem that PACKAGES don't fix because they feel it's someone else's problem).
Instead of that, though, we get thousands of people hitting Linux for the first time, many of whom are competent programmers or tech writers and instead of saying: here are all of the things that we should be looking to spend time on doing as a community, we push them in the direction (and by we, I include these new people as well) of building their own Linux installation from scratch.... educational? Yes. The best bang-for-the-perspon-hour-spent? Not even close. Try sitting down and understanding the rat's nest of documentation formats on your average Linux system (there are at least 5 "standard" documentation systems that I can think of, and they only interoperate with eachother at the minimum level possible) and after a few days or weeks, you'll probably know more than I do in a few areas. PLUS, you'll be poised to fix some rather substatial problems.
If you're a programmer, same goes for the authentication mess.
I'm not saying LFS is bad, heck *I* would have been tempted to write it, but I see these many, many endemic problems in the Linux world and I see the new folks to that world being told, "try building your own distribution, it's cool!"
Remember, if we don't lead new members of the community down the road of "scratch your own itches", they're going to continue to think of software as a feudal system where they should wait for the next release and see what the software maintainers have deigned to bless them with THIS TIME.
LFS is not a true distro, it is the means to make a distro from the program sources, which is a lot more than `make install`, believe me! (you must use *BSD, lucky you;-).)
I do get that LFS is not a real distro per se, but a set of docs on how to make one. I just wish that such vim (no pun intended) and zeal were applied to fixing the problems that UNIX/Solaris/HPUX/BSD/Linux/etc have had for decades rather than crafting yet another from-scratch compilation of things that don't work well together.
In answer to your assertion, I primarily use Linux at home and at work, though I use Windows/XP for gaming at home and I use whatever I have to to get work done.
I have friends who use Free- and NetBSD so I'm somewhat familliar with them (and I used to use BSD a lot in the late 80s (BSD propper) and early 90s (SunOS3 and 4)).
surely man already does this? my man pages are valid for any command, library call or setup file on my system
Not mine. I've tried every variant of Linux I can get my hands on. Here's an example from my system, just trying a few of the "/etc/p*" files:
man pam_smb.conf man pine.conf man printconf.local man profile man protocols
How do I find out what program "profile" is documented under? Granted, that's an easy one, and I already know the answer, but many people don't know what a borne shell is, much less that bash IS one.
FreeBSD actually made a point of thise, and they were doing a good job for a while. I have no idea how that's doing at this point, though.
You make the point that paths can be edited... well, yes, but the WHOLE system needs to know that you can have files in multiple locations. For decades now,/opt has been the correct place for third party software, and still I see distribution vendors all inventing their own ideas (Red Hat just wants everyone to install in/usr, debian made some noises in the/opt direction and then gave up in favor of the Red Hat model, the other distributions don't appear to have even thought this far ahead. It *is* a distribution's job to worry about how sofware can be added to the system in a sane way and impose those standards.
You claim that a distribution cannot manage user authentication, but then who exactly DOES? The sudo folks say it's pam's job. The pam folks say it's ssh's job. ssh says it's sudo's job....
In the end, it's GOT to be the distribution that sets their foot down and says "here is the way you will authenticate a user, and here is the way that you will pass authentication data around." The fact that SSH had to roll it's own was a sad result of the state of user authentication at the time, not a desirable situation. Should MY remote access program use SSH's keys or create it's own? Should I maybe have an API for that? Should that API be part of the standard suite of getpw* API calls? WHOAH NOW! That's the glibc folks!
Packaging a distribution is about creating a working system out of the parts provided and any other glue that needs to be added, not about typing "make install" and walking away.
On the point of what to call the system, I've never understood why people put the name of the kernel in the distribution name. It's kind of like calling a computer an IBM PC Clone....why? Why not be your own thing and put your acknowledgements in the documentation where they belong? Eh, I guess most folks don't agree with me here, so oh well....
I really love this kind of thing, and I honestly hope that AOL decides to use it (though, I doubt that will happen because AOL has made it clear that they were burned badly by popups in the past).
Why is this good? Because those of us who hate these things with a passion have already blocked them (tweaking may be required on sites that agree to pop-up on-click), but there's a pain-threshold problem that leads MOST people to avoid blocking suck things. Once the ads start disrupting sessions so badly that no one can stand it, all of the browsers out there will simply not allow this foolishness.
The next step is to start browsing a derivative of the Web that is extracted, reviewed, filtered and THEN delivered to the user... someone could make a whole lot of money. Heck, several companies could (which would be better that any one company doing it, of course).
Thankfully, and for the most part, people mod based on thinking about what I've said, not what responders plead for....
LFS is exactly what you have argued needs done
Great!
it is a set of build instructions and text on how a system works, you build EVERYTHING yourself, from source! you are in COMPLETE control over what goes in and what doesnt, you are in complete control over what the system is used for
Uh... huh. And this accomplishes what I suggested HOW?
Understand that, yes, LFS is not itself a distribution per se, but it represents a lot of effort in going through and building distributions in order to learn and generate the documentation. Why? What need does it fill? Is it just the enthusiast, "hey, let's write a HOWTO on building bat-guano-based case mods!" or is there really a need that these people had?
That's what I was bringing into question, not the specifics of LFS or BLFS.
All that said, I can appreciate the accedemic merit of what they suggest, to wit:
The most important reason for LFS's existence is teaching people how a Linux system works internally. Building an LFS system teaches you about all that makes Linux tick, how things work together, and depend on each other. And most importantly, how to customize it to your own taste and needs.
But, I still feel that it would be more important and useful to the person who wants to know more about how these things work if someone who was skilled at creating documentation did so in the form of one, universally-consistent set of man-pages for what already exists in a given distribution. THEN adding additional distributions or docs on how to build your own would make sense. Hence, that was my first point in the original posting.
BTW: Since it's a set of intrustructions on how to get and use parts, I don't think you should be calling it GNU/Linux since that implies, for example, that you will not use the BSD file utilities, the Intel C compiler and many other components that are not GNU. Remember GNU's Not Linux!;-)
Instead of inventing YET ANOTHER WEB SERVER DISTRO (yes, I've been tempted too), can we please focus our efforts on the things that are wrong, broken and unusuable in EVERY DISTRO ON THE PLANET?
Here are some suggestions for your distro-crafting efforts (no implied priorities):
There should be a way to say "fetch documentation for x" where x is a path name to any non-user file (and a few user files). man is the "right place" to do this, although if you wanted to take the time to re-engineer info so that it could take any program name or path name as an argument and find the right documentation AND had an initial dir.info that wasn't so geard toward "so you've installed EMACS and the GNU tools on an existing UNIX" then it might be a useable replacement for man (and info has the benefit of being a bit easier to convert into other forms like GUI-viewer, print and HTML-based representations because it's based on a more generalized markup language (texi) which is in turn based on a more powerful typesetter (\TeX). I'm a long time (15ish years) user of UNIX and UNIX-like systems, and I still want this!
A set of management tools for pam that runs the spectrum from adding a user to choosing a password hashing format to setting up an LDAP server based on an existing source (local files, an external database, etc). In the UNIX tradition (and for good and valid reasons that you can find by searching USENET, and I won't go into here) it should be command-line driven, but I would not complain at all about a GUI tool
A heirarchical installation model that allows for a/usr,/opt and/usr/local which are applied to all system paths and configurations in reverse order (e.g. default paths all start with/usr/local/bin) and which package maintainers have well defined conventions for using according to historical precident (/usr is for distribution-native packages,/opt is for third-party packages and/usr/local is for site-local items that are created and installed by the maintainer of the system). If I put GNOME3.0pre-alpha97 into my/etc/apt/sources or whatever the equivalent is, and install it, it should go into/opt so that un-installing it puts my system back where it started. If I hack my own copy of Perl and install it, it should go into/usr/local so that it's clear that this is my hacked version and not something installed from the official distribution.
sudo, ssh, and pam all have different views on what it means to authenticate. These views need to be merged at the distribution level into a single means of authenticating. This is a hairy problem, and may involve feeding back into all three projects, but if I don't have a password because I use a pam-based smart card and ssh-agent for remote key exchange then I can't use sudo (which requires a password). sudo is well within its rights to require periodic re-authentication, but that needs a mechansism (through support in it and the infrastructure of the os including pam and ssh) to feed that re-authentication request all the way back to my smart-card interface....
So, if distributions are seeking to solve problems like these, great. If they're not, and they're just another way to customize Red Hat or Debian or install from source or put your files on an FTP server, then I have to ask if the authors of these tools are even scratching their own itch?!
Exactly, so for example, when I've written such invoices, the fact that I claimed to be "ajs@ajs.com", but was in fact sending the mail from work (or visa versa) means that I was committing a crime by Virginia's standards.
Worse, I'm interpreting what I think is the *intent* here, but technically the fabrication (e.g. creation) of any headerer information (you know, header information, that thing "normal" mail doesn't have...) would seem to meet the criteria, so any message I've ever sent that generated $1000 in revenue would be criminal spam.
Hi, my name is Aaron and I'm a spammer. [insert reply posts here with, "Hi, Aaron!"] My career as a spammer started out like most people's. I thought it was ok to send business email, but then I got hooked on adding "headers"... that's when my dog left me and my beer all went flat! But I've admitted that I'm powerless in the face of my addiction, and I've asked my higher power (ISP) for help. Since I've been blocking outbound port 25 I've only had one relapse at an Internet cafe. I've been a recovering spammer for 2 years now, and I'd like to thank you all for this lovely medallion!;-)
consciously (with intent) alter either e-mail header or other routing information (a technical characteristics common to most unsolicited bulk mail, but not present in normal e-mail messages); and
Have you ever seen such hogwash?! What, pray are, "a technical characteristics"?! Since when are headers and routing information common to "unsolicited bulk mail", but not "normal e-mail messages"?!
attempt to send either 10,000 messages within a 24/hr period or 100,000 in a 30-day period OR the sender must generate $1,000 in revenue from a specific transmission, or $50,000 from total transmissions.
Ok, so where do I trun myself in? I've certainly generated $1,000 from a specific transmission (we in the spammer game call it an "invoice") and I (just like tens of thousands of other evil spammers like me) forge headers and alter routing information. For example, I have mailing list managers that alter headers and routing information and then take that single modified message and send it to DOZENS of users! I also send mail from my laptop at home and claim to be me at work and visa versa!
Before tonight I didn't know I was a spammer, but if Virginia says I'm a spammer, I must be one! Is there a reward for turning my evil spammer ass in?
"What I'm getting tired of having to point out is that signal to noise on [insert your favorite human communication vector] is inversly proportional to the number of people who are allowed to speak. Through true freedom of speach comes noise. Through the application of intelligent filtering you can interpret this noisy spectrum just as you would any other"
"I just don't accept this."
That's your perogative...
"Noise is a result of bad manners and selfishness."
but if you're going to disagree with me, you should do so, your above statement was essentially my point.
"Most people voluntarily refrain from bad manners and selfishness."
To the best (worst?) of my experience, they do NOT.
Go find an example of an intelligent discourse that happened without a) ignoring/filtering massive amounts of noise b) censoring those who were abusive or c) hiding the discourse form public access (about 100 participants is really pushing the limit, which is why USENET broke down every time a newsgroup got to a certain threshold of popularity). The examples I know of are all in one of these categories, but I'd be glad to entertain others if you can counter-propose.
"Slashdot to some extent protects itself from the effects of the tiny, destructive minority who for reasons of egotism or spite seek to destroy the information systems they use."
That minority aren't actually a majority. How many moderators moderate to "agree" or "disagree" rather than to sort of signal from noise? For the answer to that, go check out how many pro-Microsoft comments which are otherwise quite valid comments are moderated down in an article where they are on-topic.
How many posters post a jab or insult rather than discussing?
How unreadable is Slashodt in 0/Nested/Recent mode? I can answer that one because I had moderator points today, and I insist on moderating without regard to how popular or un-rated something is, though I ignore -1s simply to get through my contribution before I need to go do more work. The signal-to-noise on an un-censored Slashdot is about as bad as USENET, which is why Slashdot has to do exactly what I said: they perform intelligent noise filtering.
"Real-life social fora (such as bars) protect themselves from antisocial egotists by, er, physical persuasion. Usenet has no such mechanisms for self protection."
And that is USENET's ultimate failing. Building a USENET with multiply-rooted trust/reputation/reviewing would be fairly easy to do as these things go, but mailing lists, weblogs and blogs supplanted a lot of the pressure to do that a long time ago.
"[... a good example from your personal history of signal-to-noise and mobs...] For twenty years Usenet has been a vey important part of my social life, but like Spaf I now feel that it is dying. And I think that is extremely sad. I think it's a crashing indictment of modern standards of behaviour and manners that people are prepared to willfully and casually destroy something which has been so valuable to so many."
You have a great example, but understand that that sort of behavior is common. It was the norm in globally-popular groups like soc.*, talk.*, alt.sex (ah, I remember when alt.sex was a useful newsgroup for actually discussing sex...) and many other groups even as early as 1990. Granted, most people are not so callous, but still the majority of people in an oncensored environment with 100+ participants will contribute noise in an overwhelming ratio to signal.
Then again, as communications companies start getting more restrictive about what is and is not valid communication (e.g. AOL's filtering of residential mail), I have to think that perhaps it IS time to start looking at a USENET-like beast for the modern day. There's some updating that would be unfortunate: USENET worked over store-and-forward net
Indeed, I keep running into this in various quarters. Someone will say, "this netblock spews more spam than content," or "this user posts more noise than signal to (USENET/Slashdot/mailing-list-de-jour/etc)" or the like. What I'm getting tired of having to point out is that signal to noise on [insert your favorite human communication vector] is inversly proportional to the number of people who are allowed to speak. Through true freedom of speach comes noise. Through the application of intelligent filtering you can interpret this noisy spectrum just as you would any other.
The problem is that too many people are convinced that rational, intelligent discourse cannot happen through a noisy vector and they get mad at those who add noise for their failure to adequately filter the medium. Oh well.
thought it was apt-get install man, packages required: light, water-land, animals, birds, fish, plants, earth, etc... and he downloaded and installed for 6 days, on the 7th he said "oh, its finally done."
Hmm, I think there was something about crashing on the 7th day... Of course, I may be mis-translating;-)
Yes they do, but censoring is not the problem. The problem is that AOL is segregating the Net.
If AOL decides not to allow mail with the word "potatoe" in it, that's their problem and I'll let Mr. Quayle send all his mail encrypted to get past their stupidity if he wants to, or just get another ISP.
The real problem is that AOL has decided that a large chunk of the valid mail sources in the world are, in fact, NOT valid mail providers! This means that vast numbers of AOL users are now not on the Internet-propper vis email, but rather some AOL-private-subset of the Internet that includes many spammers, but excludes many valid users!
AOL's technical folks, if you're listening: Change your policies! Weight blacklists (even your own, internally) based on how often you get valid non-spam that matches them. If you're not up for doing that analysis, feel free to pinch the data from SpamAssassin, as the GA that scores all of SA's tests does this weighting for you. Just take all of the SA scores for blacklist tests, re-normalize them to 1, and apply those weights.
Now, you can safely generate a blacklist score for every message (by averaging the weighted binary results, e.g. score1=(blaklist1(ip)?1:0)*weight1...) and bounce the connection (even in your usual RFC-non-compliant way) if it's higher than some threshold, e.g. 0.75.
Don't apply bad statistics to a problem of signal-to-noise. I can assure you that ends badly for all concerned!
First off, the article is WAY behind the times on anti-spam techniques. SpamAssassin's statistical techniques far outstrip the simplistic features discussed. For example, it mentions obfuscation techniques, and yet SA is known to detect almost all of them one way or another, and even when it doesn't it catches the mail because it's in Razor2, comes from a BLed site, has obviously forged bits, doesn't look like valid mail to Bayes, etc, etc, etc.
Second, the article is also a bit naive on several points regarding blacklists. Many blacklists are good and useful, many are not. But taken as a whole, they present a spectrum of data that can be interpreted through a number of classical techniques that are applied to noisy data sources. Trusting any one BL or a small list is almost always a mistake, you need to build a sample set and determine who you trust and how much. SA does this, but it would be easy enough to build a BL-only SA-like tool for high-speed analysis on high volume ISPs and pipe-providers.
I'm getting worried that the problem of spam erradication is starting to look like the most divisive problem the net has faced to date. There are an awful lot of angry people, and those pitchforks and torches are starting to point in some very "infrastructurish" directions. Articles like this one, really don't help much....
What makes you think this supreme court is interested in protecting the pirvacy of ordinary citizens?
In a way, it's not and it shouldn't be.
The job of the US Supreme Court is to review decisions of lower courts and determine when and if the decision is in violation of the constitution or (as a secondary concern) the rest of the body of US law.
Thsi is a balance against the authority invested in congress to make new laws and the executive to enforce them.
What I want to see is the US Supreme Court determine that the DMCA is, in fact, not a constitutionally valid law. Privacy is only one reason (and a tenuous one) upon which this is true. The most important two reasons are the fact that the DMCA harms the public domain, contrary to the mandate of copyright in the Constitution and it also gives powers to copyright holders that the Constitution grants to the executive (e.g. law enforcement). These aspects of the DMCA need to be recognized by the court as invalid, and a new law will have to be crafted which repairs these problems.
Either that or we could all grow up and realize that copyright law works just fine as is...
Slashdot Mirror
The admin of the mailing list can set any price he desires to post to it. Since an ML is a recipient multiplier and a fat target for spam, they might choose $0.20 or $0.50 for a message
I don't think it's a leagally tennable idea to make a mailing list charge for messages sent to it. For starters, by charging someone a fee, you implicitly accept a number of responsibilities for the prodcut or service.
You also cannot claim that someone is abusing your service when they paid you the money you asked for. Thus, bulk mailers no longer have to masquerade behind forged headers and such, they just proudly send mail to the largest 10 mailing lists they can find, pay their $2 fee and count their revenue stream....
Very bad, do not do.
And $0.25 isn't too much for a non-subscriber who wants driver help from linux-kernel
No not at all, but who's going to pay $0.25 to ANSWER? No one of course, so only private replies will be sent, but even then it's goign to cost SOMETHING.
Also, you're being US-centric. There are many countries that take part in US-based free software development lists and many other beneficial discussion venues who would be crushed by the exchange rate on a $0.25/per message fee! In some countries that would be enough to buy a meal, and I'm going to answer a technical question or contribute a patch... AND PAY FOR IT?!
Fee-based sending would be the death of electronic mail as we know it, and there are better solutions
You're assuming too much. You mention micro-payments... Would you require that I pay $0.01 per recipient to send a question to the Linux kernel mailing list? What if I send mail to "support@somesoftwarecompany.com" and that happens to point to their external support partner and several internal addresses?
Who collects this? If I have an account with an ISP, do they give me the micro-cash? Wow, I need to get on a lot of mailing lists and fast!
Does the ISP collect it? Wow, I can just see it... hmm, I yesterday the botte-cap-collectors@junkshop.com email list had 2 members, but now "perlscript0x0001@bigisp.net" through "perlscript0xffff@bigisp.net" are subscribed to the list... that's odd. Huh, I wonder who I should send the check to for the $650 that it just cost me to send the "bottle cap of the day" message out.
As long as there's a header that I can set to say "I will not pay the tax, please reject my mail," I'm a happy camper!
I will continue to send email to/from my friends who all run their own servers, and ISPs can go fly. If the IRS thinks that I'm going to pay them for mail that I send from my MTA to my friend's MTA that are both located in our own personal machine rooms, I'll set up UUCP mail and let them figure out if that counts....
Yeah, so sarcasm asside, this idea fits into a class that you should be looking for. Let me quote:
a tax would be an affront to some mythic libertarian "spirit of the internet"
No, a tax would be an unworkable mess that would have so many problems you cannot possibly measure them! Yes, the spirit of the Net is a network of peers who exchange packets at the IP level and let applications decide what to encapsulate, so there's some basic problems there, but then you get into What is mail? Should I tax ICMP? ICMP isn't even IP, it's a sister protocol, but if ICMP isn't charged for then I could just write SMTP/ICMP and encapsulate the protocol in ICMP datagrams (yuck, but it would work). If you tax ICMP, then you're charging me for things like my Linksys firewall rejecting network probes!
The Internet should turn into a penny post, with a levy of 1 cent per letter.
Define post. Define letter. Define pay (if I live in a community in India that's mostly barter-based and there's an email kiosk in the center of town, set up by volunteers....) Assume that the vast majority of my mail comes from a private residence and goes to private residences and businesses, not to public ISPs (which is the case) and try to figure out how we go about collecting a "tax".
I pay a tax for my connectivity, it's called ISP fees. If the US government wants to charge a tax to ISPs, they'll have to talk to the ISPs, but I assure you AOL will lobby against it pretty seriously, so you'd better have your facts in line detailing exactly how it will prevent spam from Russia while also not hurting the consumer.
Rather than punditing, I'm actually contributing to the solution. Please keep your "there oughta be a law" reactionary drivel out of my Internet.
You missed the point... YOU DO NOT HAVE TO UPGRADE PERL.... follow the instructions I gave. That will correctly upgrade just the relevant libraries.
However... WHAT poor history of backwards compatibility?! You mean the fact that 10% of the programs in the world broke when perl when from major version 4 or major version 5 over 10 years ago? Or did I miss some compatibility breakage in the last 10 years?
Compatibility is a major point of pride for Perl, and unless you're relying on unintentional subtelties in the language (read, bugs), I haven't heard about a break in such compatibility. My programs that use the Perl internals from C from 8 years ago don't compile cleanly, but the ONLY reason that's true is that the *C* compiler won't take my broken semi-ANSI C anymore, other than that it works like a charm!
Adding a reply-to is one thing. My mailer claims that I'm ajs@.com, even though it's sending mail from a system, and through an MTA totally un-related to my company. It does this by setting the From address both in the headers and in the Envelope (e.g. the SMTP "MAIL From:" command).
That's called forgery, and it's a perfectly legitimate form of forgery use by most popular mailers these days.
The Register is a rag. Can we please stop quoting from it for anything important?
For simple, Bayes-only systems Paul Ghram has seen false positive rates around 0.03%, and SpamAssassin sees only slightly more than that on it's large database of mail, much of which is often in the database because it's pathologically spam-like.
Systems like Razor2, Bayes and blacklists make the system even more accurate, though often not in ways that are easy for a benchmark to detect (you need to leave SA running long enough for bayes to get trained by the rest of SA; Razor2 is time-sensitive and blacklists change in quality over time).
It was probably a fair number of versions ago. SA now has a daemon-mode called "spamd", since it turns out that most of the startup cost is in parsing the configuration (e.g. all of the rules), and compiling the Perl, of course.
Once you have spamd in use, you cut your CPU usage amazingly (made it usable for my company), and your memory access patterns are much more reasonable for the OS to deal with. Memory is still used liberally, but that will probably change when later versions of Perl start doing CoW more automatically, since a lot of SA's memory usage is simply read-only copies of parts of the message.
Actually, you don't want to do that. If someone says "sluts", then it's a fair indicator of spam, and that word will be weighted appropriately by Bayes. However, if they say "5LUTS", it's MUCH MORE likely to be spam!
Obfuscation in most cases is self-defeating, and only people who thinkg that avoiding this or than specific rule is going to help them bother.
Ooops, in the beginning of that message, I meant "anti-spam too dependent"... sorry if I implied there's an anti-spam-tool universal config file, though IMHO, there should be....
Spam tools are currently at the point tht detection of spam is a near-certainty and the probabilities for false-positives (e.g. good mail getting called spam) are measured in the 0.00n-0.0n% range (that is n in 100,000 to n in 10,000) which can almost always be improved on locally by the user through various means that are anti-spam-tool independant.
SpamAssassin is currently my tool of choice. It's very flexible, can be used with any UNIXish mailer and is just getting frighteningly better over time.
SA's recent addition of Razor2, a Bayesian filter and improved handling DNS blacklists (which SA weights so you can apply them withour worrying about slicing large and useful parts of the Internet out of your field of view) have reduced many concerns that folks had before about active abuse of SA's rule-base in the past. The speed with which this system applies hundreds of tests to a message is also quite stunning, and a major boost to Perl's tacit reputation as a "slow" language.
The biggest problem with SA right now is probably the inability to scale up to the mid-range ISPs and medium-sized business without SERIOUS harware allocation due to the heavyweight neature of its testing. That's my personal mission for SA over the next year or so. My goal is to make SA a reasonable option for anyone that has to process orders of magnitude more mail than your average ISP (e.g. AOL).
When the upcoming 2.54 comes out, I HIGHLY recommend checking it out. You can install SA on most UNIX-like systems, as long as they have Perl installed by typing (as root)following the configuration process if you have not done so for Perl before, and then typingAfter that it's just a matter of how you want to configure your MTA to talk to SA. I recommend using SA in "spamd" mode with sendmail and procmail. If you already use sendmail with procmail delivery, you just have to change your
Good luck!
A bunch of folks got me wrong here, and I just want to clarify:
There are two classes of people that one can address in relation to this article: the people who put LFS together (LFS is a documentation set on how to build a Linux system from scratch) and the people who use LFS to build their own systems.
What I was trying to suggest (and apparently didn't do a good job of) was that that SECOND class of people would do much better for themselves by taking joe random distribution (let's say Red Hat, just because they're an easy target, not because they are better or worse in these respects than anyone else) and customizing it by fixing the long-standing problems that have existed since before Linux.
It used to be amazing that you had a system where you could wonder what "ls" did, and so you typed "man ls" and you found out.
That was nice, but those days are now long ago, and we should be expecting more from our systems documentation. Same thing goes for the other things I pointed out (I wasn't saying: go fix ssh/sudo/pam, I was saying that the broken integration between them was a good example of a class of problem that PACKAGES don't fix because they feel it's someone else's problem).
Instead of that, though, we get thousands of people hitting Linux for the first time, many of whom are competent programmers or tech writers and instead of saying: here are all of the things that we should be looking to spend time on doing as a community, we push them in the direction (and by we, I include these new people as well) of building their own Linux installation from scratch.... educational? Yes. The best bang-for-the-perspon-hour-spent? Not even close. Try sitting down and understanding the rat's nest of documentation formats on your average Linux system (there are at least 5 "standard" documentation systems that I can think of, and they only interoperate with eachother at the minimum level possible) and after a few days or weeks, you'll probably know more than I do in a few areas. PLUS, you'll be poised to fix some rather substatial problems.
If you're a programmer, same goes for the authentication mess.
I'm not saying LFS is bad, heck *I* would have been tempted to write it, but I see these many, many endemic problems in the Linux world and I see the new folks to that world being told, "try building your own distribution, it's cool!"
Remember, if we don't lead new members of the community down the road of "scratch your own itches", they're going to continue to think of software as a feudal system where they should wait for the next release and see what the software maintainers have deigned to bless them with THIS TIME.
LFS is not a true distro, it is the means to make a distro from the program sources, which is a lot more than `make install`, believe me! (you must use *BSD, lucky you ;-).)
I do get that LFS is not a real distro per se, but a set of docs on how to make one. I just wish that such vim (no pun intended) and zeal were applied to fixing the problems that UNIX/Solaris/HPUX/BSD/Linux/etc have had for decades rather than crafting yet another from-scratch compilation of things that don't work well together.
In answer to your assertion, I primarily use Linux at home and at work, though I use Windows/XP for gaming at home and I use whatever I have to to get work done.
I have friends who use Free- and NetBSD so I'm somewhat familliar with them (and I used to use BSD a lot in the late 80s (BSD propper) and early 90s (SunOS3 and 4)).
Not mine. I've tried every variant of Linux I can get my hands on. Here's an example from my system, just trying a few of the "/etc/p*" files:How do I find out what program "profile" is documented under? Granted, that's an easy one, and I already know the answer, but many people don't know what a borne shell is, much less that bash IS one.
FreeBSD actually made a point of thise, and they were doing a good job for a while. I have no idea how that's doing at this point, though.
You make the point that paths can be edited... well, yes, but the WHOLE system needs to know that you can have files in multiple locations. For decades now,
You claim that a distribution cannot manage user authentication, but then who exactly DOES? The sudo folks say it's pam's job. The pam folks say it's ssh's job. ssh says it's sudo's job....
In the end, it's GOT to be the distribution that sets their foot down and says "here is the way you will authenticate a user, and here is the way that you will pass authentication data around." The fact that SSH had to roll it's own was a sad result of the state of user authentication at the time, not a desirable situation. Should MY remote access program use SSH's keys or create it's own? Should I maybe have an API for that? Should that API be part of the standard suite of getpw* API calls? WHOAH NOW! That's the glibc folks!
Packaging a distribution is about creating a working system out of the parts provided and any other glue that needs to be added, not about typing "make install" and walking away.
On the point of what to call the system, I've never understood why people put the name of the kernel in the distribution name. It's kind of like calling a computer an IBM PC Clone....why? Why not be your own thing and put your acknowledgements in the documentation where they belong? Eh, I guess most folks don't agree with me here, so oh well....
I really love this kind of thing, and I honestly hope that AOL decides to use it (though, I doubt that will happen because AOL has made it clear that they were burned badly by popups in the past).
Why is this good? Because those of us who hate these things with a passion have already blocked them (tweaking may be required on sites that agree to pop-up on-click), but there's a pain-threshold problem that leads MOST people to avoid blocking suck things. Once the ads start disrupting sessions so badly that no one can stand it, all of the browsers out there will simply not allow this foolishness.
The next step is to start browsing a derivative of the Web that is extracted, reviewed, filtered and THEN delivered to the user... someone could make a whole lot of money. Heck, several companies could (which would be better that any one company doing it, of course).
Thankfully, and for the most part, people mod based on thinking about what I've said, not what responders plead for....
LFS is exactly what you have argued needs done
Great!
it is a set of build instructions and text on how a system works, you build EVERYTHING yourself, from source! you are in COMPLETE control over what goes in and what doesnt, you are in complete control over what the system is used for
Uh... huh. And this accomplishes what I suggested HOW?
Understand that, yes, LFS is not itself a distribution per se, but it represents a lot of effort in going through and building distributions in order to learn and generate the documentation. Why? What need does it fill? Is it just the enthusiast, "hey, let's write a HOWTO on building bat-guano-based case mods!" or is there really a need that these people had?
That's what I was bringing into question, not the specifics of LFS or BLFS.
All that said, I can appreciate the accedemic merit of what they suggest, to wit:But, I still feel that it would be more important and useful to the person who wants to know more about how these things work if someone who was skilled at creating documentation did so in the form of one, universally-consistent set of man-pages for what already exists in a given distribution. THEN adding additional distributions or docs on how to build your own would make sense. Hence, that was my first point in the original posting.
BTW: Since it's a set of intrustructions on how to get and use parts, I don't think you should be calling it GNU/Linux since that implies, for example, that you will not use the BSD file utilities, the Intel C compiler and many other components that are not GNU. Remember GNU's Not Linux!
Here are some suggestions for your distro-crafting efforts (no implied priorities):
- There should be a way to say "fetch documentation for x" where x is a path name to any non-user file (and a few user files). man is the "right place" to do this, although if you wanted to take the time to re-engineer info so that it could take any program name or path name as an argument and find the right documentation AND had an initial dir.info that wasn't so geard toward "so you've installed EMACS and the GNU tools on an existing UNIX" then it might be a useable replacement for man (and info has the benefit of being a bit easier to convert into other forms like GUI-viewer, print and HTML-based representations because it's based on a more generalized markup language (texi) which is in turn based on a more powerful typesetter (\TeX). I'm a long time (15ish years) user of UNIX and UNIX-like systems, and I still want this!
- A set of management tools for pam that runs the spectrum from adding a user to choosing a password hashing format to setting up an LDAP server based on an existing source (local files, an external database, etc). In the UNIX tradition (and for good and valid reasons that you can find by searching USENET, and I won't go into here) it should be command-line driven, but I would not complain at all about a GUI tool
- A heirarchical installation model that allows for a
/usr, /opt and /usr/local which are applied to all system paths and configurations in reverse order (e.g. default paths all start with /usr/local/bin) and which package maintainers have well defined conventions for using according to historical precident (/usr is for distribution-native packages, /opt is for third-party packages and /usr/local is for site-local items that are created and installed by the maintainer of the system). If I put GNOME3.0pre-alpha97 into my /etc/apt/sources or whatever the equivalent is, and install it, it should go into /opt so that un-installing it puts my system back where it started. If I hack my own copy of Perl and install it, it should go into /usr/local so that it's clear that this is my hacked version and not something installed from the official distribution. - sudo, ssh, and pam all have different views on what it means to authenticate. These views need to be merged at the distribution level into a single means of authenticating. This is a hairy problem, and may involve feeding back into all three projects, but if I don't have a password because I use a pam-based smart card and ssh-agent for remote key exchange then I can't use sudo (which requires a password). sudo is well within its rights to require periodic re-authentication, but that needs a mechansism (through support in it and the infrastructure of the os including pam and ssh) to feed that re-authentication request all the way back to my smart-card interface....
So, if distributions are seeking to solve problems like these, great. If they're not, and they're just another way to customize Red Hat or Debian or install from source or put your files on an FTP server, then I have to ask if the authors of these tools are even scratching their own itch?!Exactly, so for example, when I've written such invoices, the fact that I claimed to be "ajs@ajs.com", but was in fact sending the mail from work (or visa versa) means that I was committing a crime by Virginia's standards.
;-)
Worse, I'm interpreting what I think is the *intent* here, but technically the fabrication (e.g. creation) of any headerer information (you know, header information, that thing "normal" mail doesn't have...) would seem to meet the criteria, so any message I've ever sent that generated $1000 in revenue would be criminal spam.
Hi, my name is Aaron and I'm a spammer. [insert reply posts here with, "Hi, Aaron!"] My career as a spammer started out like most people's. I thought it was ok to send business email, but then I got hooked on adding "headers"... that's when my dog left me and my beer all went flat! But I've admitted that I'm powerless in the face of my addiction, and I've asked my higher power (ISP) for help. Since I've been blocking outbound port 25 I've only had one relapse at an Internet cafe. I've been a recovering spammer for 2 years now, and I'd like to thank you all for this lovely medallion!
Have you ever seen such hogwash?! What, pray are, "a technical characteristics"?! Since when are headers and routing information common to "unsolicited bulk mail", but not "normal e-mail messages"?!Ok, so where do I trun myself in? I've certainly generated $1,000 from a specific transmission (we in the spammer game call it an "invoice") and I (just like tens of thousands of other evil spammers like me) forge headers and alter routing information. For example, I have mailing list managers that alter headers and routing information and then take that single modified message and send it to DOZENS of users! I also send mail from my laptop at home and claim to be me at work and visa versa!
Before tonight I didn't know I was a spammer, but if Virginia says I'm a spammer, I must be one! Is there a reward for turning my evil spammer ass in?
I'd add a smily, but this is just creepy!
"I just don't accept this."
...] For twenty years Usenet has been a vey important part of my social life, but like Spaf I now feel that it is dying. And I think that is extremely sad. I think it's a crashing indictment of modern standards of behaviour and manners that people are prepared to willfully and casually destroy something which has been so valuable to so many."
That's your perogative...
"Noise is a result of bad manners and selfishness."
but if you're going to disagree with me, you should do so, your above statement was essentially my point.
"Most people voluntarily refrain from bad manners and selfishness."
To the best (worst?) of my experience, they do NOT.
Go find an example of an intelligent discourse that happened without a) ignoring/filtering massive amounts of noise b) censoring those who were abusive or c) hiding the discourse form public access (about 100 participants is really pushing the limit, which is why USENET broke down every time a newsgroup got to a certain threshold of popularity). The examples I know of are all in one of these categories, but I'd be glad to entertain others if you can counter-propose.
"Slashdot to some extent protects itself from the effects of the tiny, destructive minority who for reasons of egotism or spite seek to destroy the information systems they use."
That minority aren't actually a majority. How many moderators moderate to "agree" or "disagree" rather than to sort of signal from noise? For the answer to that, go check out how many pro-Microsoft comments which are otherwise quite valid comments are moderated down in an article where they are on-topic.
How many posters post a jab or insult rather than discussing?
How unreadable is Slashodt in 0/Nested/Recent mode? I can answer that one because I had moderator points today, and I insist on moderating without regard to how popular or un-rated something is, though I ignore -1s simply to get through my contribution before I need to go do more work. The signal-to-noise on an un-censored Slashdot is about as bad as USENET, which is why Slashdot has to do exactly what I said: they perform intelligent noise filtering.
"Real-life social fora (such as bars) protect themselves from antisocial egotists by, er, physical persuasion. Usenet has no such mechanisms for self protection."
And that is USENET's ultimate failing. Building a USENET with multiply-rooted trust/reputation/reviewing would be fairly easy to do as these things go, but mailing lists, weblogs and blogs supplanted a lot of the pressure to do that a long time ago.
"[... a good example from your personal history of signal-to-noise and mobs
You have a great example, but understand that that sort of behavior is common. It was the norm in globally-popular groups like soc.*, talk.*, alt.sex (ah, I remember when alt.sex was a useful newsgroup for actually discussing sex...) and many other groups even as early as 1990. Granted, most people are not so callous, but still the majority of people in an oncensored environment with 100+ participants will contribute noise in an overwhelming ratio to signal.
Then again, as communications companies start getting more restrictive about what is and is not valid communication (e.g. AOL's filtering of residential mail), I have to think that perhaps it IS time to start looking at a USENET-like beast for the modern day. There's some updating that would be unfortunate: USENET worked over store-and-forward net
Indeed, I keep running into this in various quarters. Someone will say, "this netblock spews more spam than content," or "this user posts more noise than signal to (USENET/Slashdot/mailing-list-de-jour/etc)" or the like. What I'm getting tired of having to point out is that signal to noise on [insert your favorite human communication vector] is inversly proportional to the number of people who are allowed to speak. Through true freedom of speach comes noise. Through the application of intelligent filtering you can interpret this noisy spectrum just as you would any other.
The problem is that too many people are convinced that rational, intelligent discourse cannot happen through a noisy vector and they get mad at those who add noise for their failure to adequately filter the medium. Oh well.
thought it was apt-get install man,
;-)
packages required: light, water-land, animals, birds, fish, plants, earth, etc...
and he downloaded and installed for 6 days, on the 7th he said "oh, its finally done."
Hmm, I think there was something about crashing on the 7th day... Of course, I may be mis-translating
Yes they do, but censoring is not the problem. The problem is that AOL is segregating the Net.
If AOL decides not to allow mail with the word "potatoe" in it, that's their problem and I'll let Mr. Quayle send all his mail encrypted to get past their stupidity if he wants to, or just get another ISP.
The real problem is that AOL has decided that a large chunk of the valid mail sources in the world are, in fact, NOT valid mail providers! This means that vast numbers of AOL users are now not on the Internet-propper vis email, but rather some AOL-private-subset of the Internet that includes many spammers, but excludes many valid users!
AOL's technical folks, if you're listening: Change your policies! Weight blacklists (even your own, internally) based on how often you get valid non-spam that matches them. If you're not up for doing that analysis, feel free to pinch the data from SpamAssassin, as the GA that scores all of SA's tests does this weighting for you. Just take all of the SA scores for blacklist tests, re-normalize them to 1, and apply those weights.
Now, you can safely generate a blacklist score for every message (by averaging the weighted binary results, e.g. score1=(blaklist1(ip)?1:0)*weight1...) and bounce the connection (even in your usual RFC-non-compliant way) if it's higher than some threshold, e.g. 0.75.
Don't apply bad statistics to a problem of signal-to-noise. I can assure you that ends badly for all concerned!
First off, the article is WAY behind the times on anti-spam techniques. SpamAssassin's statistical techniques far outstrip the simplistic features discussed. For example, it mentions obfuscation techniques, and yet SA is known to detect almost all of them one way or another, and even when it doesn't it catches the mail because it's in Razor2, comes from a BLed site, has obviously forged bits, doesn't look like valid mail to Bayes, etc, etc, etc.
Second, the article is also a bit naive on several points regarding blacklists. Many blacklists are good and useful, many are not. But taken as a whole, they present a spectrum of data that can be interpreted through a number of classical techniques that are applied to noisy data sources. Trusting any one BL or a small list is almost always a mistake, you need to build a sample set and determine who you trust and how much. SA does this, but it would be easy enough to build a BL-only SA-like tool for high-speed analysis on high volume ISPs and pipe-providers.
I'm getting worried that the problem of spam erradication is starting to look like the most divisive problem the net has faced to date. There are an awful lot of angry people, and those pitchforks and torches are starting to point in some very "infrastructurish" directions. Articles like this one, really don't help much....
What makes you think this supreme court is interested in protecting the pirvacy of ordinary citizens?
In a way, it's not and it shouldn't be.
The job of the US Supreme Court is to review decisions of lower courts and determine when and if the decision is in violation of the constitution or (as a secondary concern) the rest of the body of US law.
Thsi is a balance against the authority invested in congress to make new laws and the executive to enforce them.
What I want to see is the US Supreme Court determine that the DMCA is, in fact, not a constitutionally valid law. Privacy is only one reason (and a tenuous one) upon which this is true. The most important two reasons are the fact that the DMCA harms the public domain, contrary to the mandate of copyright in the Constitution and it also gives powers to copyright holders that the Constitution grants to the executive (e.g. law enforcement). These aspects of the DMCA need to be recognized by the court as invalid, and a new law will have to be crafted which repairs these problems.
Either that or we could all grow up and realize that copyright law works just fine as is...