You still haven't identified what network you are referring to. And you're still hiding behind "Anonymous Coward". Maybe your network got listed for having a well known spam gang online (those listings never get delisted until the owner states that the spammer is gone and will never be allowed back). Maybe you stated this, but forgot to say what network was involved (like you did in this post to Slashdot). Or maybe your network is still supporting spammers and deserves to remain listed. I don't know which it is since I don't know what network you are talking about. And maybe you are a real spammer. Maybe you are just talking out your arse.
Before the SoBig virus, each mail server receiving mail would, in the course of a day (about how long DNS black list records would be cached), get SMTP connections from a certain set of other mail servers. Most of those mail servers would be the ones from which email regularly comes in. Although people would have lots of email addresses in their address books, and even more in other files, most only regularly exchange mail with a small subset.
Enter the SoBig virus. It gathers up email addresses, not only from the address book, but also from email contents, web cache, documents, and just about everything else. Then it sends email to them in a probably uniform distribution of selection. The number of different domains being sent to from one computer in a day is now much larger than normal (in addition to the increased traffic). At the receiving mail servers, the number of different mail servers the SoBig spam is coming from is also much larger than normal. Now mail servers are getting mail from just about every mail server that has any user with any instance of a user email address that names that receiving server.
With the same mail servers sending mail over and over, the receiving server's DNS cache will have hits very frequently. With an increase in diversity of mail servers trying to deliver the SoBig spam, the number of cache misses goes up. Each cache miss means a query that recurses back to the DNS blacklist servers. Thus the query load on those servers goes up, effectively a DDoS.
Additionally, most DNS servers out there are "open recursive name servers". That means they let anyone, anywhere, do a recursive lookup. Spammers can drive even more load on the DNS blacklists by sending out DNS queries (with forged source addresses, of course, so they don't have to deal with the bandwidth of the answers) to those open recursive name servers, forcing more and more queries to focus in on the authoritative servers for the DNS blacklists.
This attack can be successful because spammers have far more network access from a wide variety of places than there are authoritative name servers for DNS blacklists (the ultimate target). And since recursive DNS lookup only has that server for a source address, all the DNS blacklists will see are queries from those open servers.
One way to address some of this problem is to close off recursive lookups. But given that millions of networks are run by incompetent or non-existant administrators, that isn't likely to happen on the scale needed to prevent the abuse. And it won't stop lookups by the receiving mail servers trying to check out all the different SMTP connections due to the spam from the viruses.
Blacklists will most likely end up having to be done by a means other than DNS, unless blacklist operators can manage to acquire sufficient bandwidth and server power to ride out the loads (which could very well be even greater than the GTLD servers that host "com" and "net" would see). Some form of distributing a static list file will probably happen. And, unfortunately, that means whoever gets listed will have a much harder time getting out of all those distributed lists, as many people won't be updating them as often as they should. The original reason to use DNS was to have a relatively quick means to remove a listing and have it take effect throughout the internet. By breaking the DNS mechanism, the ability to remove a listing is what suffers the most.
What I hope will end up happening is that spammer networks and generic (dialup, cable modem, DHCP, etc) addresses get listed in distributed files, and the more transient cases still get handled by DNS. The listings in DNS would be the ones that won't be so important to big time spammers, so they would be less attractive targets of attack, and if attacked anyway, would not open up the major points spammers find easy to use (e.g. their own networks and the generic networks where open proxies are found all over the place).
Any ISP can get out of SPEWS; it's not hard. The clueless won't know how to, and will instead just blame others for their troubles. Or maybe they just prefer to keep spammers to keep the revenue, and hope not too many other customers leave (hence the blame game to try to convince the customers that they, the ISP, is not at fault for helping to pollute the internet).
I use SPEWS, and choose to use it, because it really is having an effect. Many ISPs have turned back from the dark side as a result of SPEWS. Many ISPs have gotten a clued-in person put into their abuse department as a result of SPEWS. I watch SPEWS listings regularly and see that most listings do get removed, eventually. Show me a case where an ISP really did get rid of all services to all spammers without delay (or if there was a delay, did so at a point in time back from today equal to that delay) and is still listed in SPEWS.
Since you didn't deny that your ISP was harboring spammers, am I to assume there is no basis for such a denial?
SPEWS does remove listings when the problem clears up. In the case of a first time spammer, this is automatic... as soon as the spamming stops for a while (or earlier if a notice is given), the listing drops off. In the case of hosting one of the about 200 notorius spam gang members, it does require further steps, including verified termination and posting on NANAE about the takedown. If there is a pattern of harboring spammers, such as having any spam gang on your net 3 times or more, or having the same one come back after termination, then listings get "sticky" and stay much longer (and rightfully so, since there is now evidence that a major spammer might show up again).
Tell me the IP address of the sending mail server, or the SPEWS record number, and I'll look things up (I archive some of the SPEWS data, so I can see some things, as well as the trend over the past year, even the web site is down again).
SPEWS pressures ISPs to terminate spammers. It works for many ISPs who have cleaned up their act. Some will terminate the spammers now immediately. Some still wait for a small SPEWS listing, but will do so then. A few are still totally clueless and let the listings keep growing and growing until it becomes a serious problem. Those are the ISPs to stay away from. Are you using a clueless ISP?
I presume your ISP was harboring spammers. That's assuming you are not a spammer. ISPs that harbor spammers do get a chance to terminate them (unless it is a well known spam gang). If they don't, it's probably because the ISP needs a financial incentive to do so. SPEWS provides that. All customers of such ISPs are indirectly supporting the harbored spammers when they pay their ISP bill.
You don't have to use SPEWS if you don't want to. The opportunity to know and understand how SPEWS works, so those who do choose to use it, should read and understand what it means. If blocking ISPs that harbor spammers is not what you want to do, then don't use SPEWS. No one is twisting your arm.
SPEWS has been responsible for getting quite many spammers, who would not otherwise have been by other DNSBLs, kicked off their ISPs, and their spamming abuse activities stopped or reduced for a while. And this is what has pissed off a lot of spammers.
Of course, a lot of customers of the listed ISPs never tried to understand, and assumed they were being accused of being a spammer. What they should have done is pressured their ISP to remove the spammer(s).
Such a strategy is not needed. It's relatively easy (except under certain PPPoE systems) to hijack someone else's address, when their computer is not turned on. Forging their NIC's MAC address is one way, but even that's not necessary in many cases. This is how people have had their cable internet service terminated for spamming, when in fact they were out of town at the time with their computer turned off and unplugged. The ISPs don't want to admit that their DHCP records only mean what IP was assigned, not what IP was actually used, or even what MAC address was actually used.
Then, there might be an open proxy involved. If I wanted to hide where I was coming from, I would use one of those open proxies (hundreds of spams a day hitting my mail servers reveal an ever growing list of ready to exploit open proxies). A proxy-NAT can translate all attempts to use the internet into traffic sent to that proxy server. UDP might be harder to do, but TCP is easy. Now I don't know if there are any open proxies running on MACs, so that may not be the case in this story, but I would not be surprised if the next erroneous victim is someone who happened to have an open proxy running, either because it was some defective software they chose to use, or because their computer was infected by something that set it up (probably by and for some spammer).
There are other root servers, too. The following command (if you have dig) will show you:
dig . ns
And I'm not referring to whether or not any government entity takes the root servers back from Verisign. I'm saying that we can take them back. It is we who "delegate" the root zone to them in the first place. We just have to take on the work of running it ourselves, or delegate to whoever of our choosing is willing to do that work.
PV: I hope but I don't think so. I've heard that the patch works well, but VeriSign could bypass the patch. It could make synthesized responses look more like delegations. I don't think it will do that. VeriSign's spokesperson, Brian O'Shaughnessy, suggested that if people don't want this, they're free to block it. It's really meant to be a service for the supposedly inconvenienced web surfers. VeriSign maintains that its search page is more useful than 404 error messages. If VeriSign bypassed the patch, it would have to escalate things and retract these statements about how folks were free to block the wildcard.
What? How the hell do you get an HTTP 404 error message if there's no server to even connect to?
Verisign can break Vixie's patch. All they have to do is set up a separate name server which pretends to be a.com and.net server, with the very same wildcarded A-record. Now just put in wildcarded NS-records in the actual.com and.net zones in the real GTLD servers (in place of the existing wildcarded A-record). There, now it really looks like a real delegation to a different name server, just like real domains have. The new delegated wildcard server gets the query next, due to the delegation (that looks like a delegation, hence fools the patch), and due to its wildcard (and it doesn't need any other data from the.com or.net zones, since it doesn't get delegated to for real domains), it will answer with an A record of Verisign's choosing. If Verisign wants to keep doing what they are doing, they can defeat this patch by that method.
Then we'll have to make DNS servers filter out specific delegations (as opposed to filtering out non-delegation records where there should be only delegations). Verisign could rotate those delegations daily and fool efforts to block it.
Why not just take back the roots? The only reason Verisign can do what they do is because the GTLD servers they control are delegated to by the root servers (not sure who controls those anymore, but it can't be good). And those root servers are configured in the hint file of name servers all over the internet. So who controls those? We (who have our own name servers) do.
It's a little harder, but not a lot harder, to just run your own root zone. The biggest thing is to gather up all the NS records and associated A records for each TLD. That's a small list (relatively speaking), so it could be done via a few hundred dig commands to the root servers. Or it can be downloaded. Now once you have that data, you replace the.com and.net zones with your own. Of course that begs the question, replace it with what?
If enough people with enough server/network power get together, they can make their own independent "realm" of domain name space, starting with a replacement root zone (as has been done in the past to add new TLDs), and a replacement for both.com and.net.
I can just hear the complaints now (and I've heard them before): "But this will fragment the internet". My answer is: Yes!!!! yes it will! all the better. Imagine being in a whole different name space realm away from spammers and evil corporations. And maybe you can meet me in the.mp3 TLD.
Certain jobs create value in our economy. Others merely divert value around. Telemarketing, for the most part, is the latter. It doesn't add to the economy; it just shifts it around.
Those who don't buy the stuff hawked by telemarketers aren't going to be burning that money in the fireplace because there's nothing left to do with it. Instead, they will spend it on something else, perhaps at an online web store, or at a local store they can visit in person. And they'll have more time to do that, too. It means people shift jobs around and instead of working for someone whose business model takes time away from others, they will be working for someone else whose business model does not.
All of the negatives due to telemarketing will be compensated by similar positives in other areas. But the one thing not carried over is the harrassment endured by those who don't want the telemarketing phone calls disturbing them and taking up their time. Who knows, maybe the next person an unemployed telemarketer doesn't call will be someone who is starting up a decent business that doesn't take from others in order to make a profit. Getting rid of the whole telemarketing industry, I believe, will be an eventual improvement in the economy.
Every system will be cracked. This one is no different. It does not matter how strong the encryption is. It won't be the encryption that matters anyway.
Unlike things like classified documents that government agencies such as the CIA or NSA deal with, where they have very tight controls on who accesses the documents, the media industry has a fundamental problem: they have to let people actually hear and see the content or those people will quit paying for it. That's part of the "analog hole". If you can hear ir or see it, you can record it again. It doesn't matter of the quality of that re-recording is less than perfect, because most people (e.g. everyone but a few perfectionist geeks) already accept slight reduction of quality in the form of lossy compression, and most of them accept even more reduction of quality when dealing with pirated (e.g. free) stuff. This is not about making perfect digital rips. What the digital revolution did is make the Nth generation as good as the 2nd generation. Once the content leaks (1st generation to 2nd generation), it gets re-digitized, and all generations of pirate distribution are now just as good as that 2nd generation, but without the DRM.
Watermarking can help, because the leaked content still has to be presented. But there is sufficient means to do that (e.g. play music through speakers and display video through CRTs, etc), that this is going to be a weak form of protection against the distribution of leaked content. And the distribution itself is going to be easy, because once you have it as a file, it can go anywhere, and during distribution, additional encryption can be added to hide any watermarking that may be visible to copying mechanisms and network sniffers.
This is not a technical problem to be solved. It is really a social, legal, and market problem. It's a people problem.
First of all, as long as some people are "left out", e.g. music and movies won't play on their computer because it isn't running software from Microsoft, then that immediately creates the incentives to make tools, both for cracking and distributing, for those who aren't even considered by the industry to be in their market. And many will justify this under the idea that if the media industry didn't consider them to be "in the market" in the first place (e.g. isn't allowing their DRM to work on BSD, Linux, etc), then there isn't any loss to the industry (e.g. why would they expect me to pay for something I cannot hear or see).
Even the best solution, which would be to stop worrying about copying, and concentrate on the playing process (e.g. make all the content presentation work from sealed hardware which knows what content it is allowed to decrypt via time-controlled certificates), can't prevent the leak. But if the industry stops trying to squeeze everyone so hard, and makes it practical to have and play content, then incentives to steal content will... never go away, but will... be much less attractive.
The model I see as best workable is one which not only works without requiring proprietary software on computers and networks, but also takes advantage of P2P networks as well (thus reducing the actual distribution costs to the industry).
A hardware chip would have the means to decrypt the media. It could be part of an internal computer device, such as a sound card, or an external device, such as built in to a video display. It would have an identification key, which would be used to purchase playback certificates. Playback certificates, which would work only on that single device, would have restrictions as to the time frame to allow playback, as well as what content categories and/or producers to allow. You could buy a certificate to allow playing only one song on only one day. Or you could buy a certificate to play that one song forever. Or you could buy a certificate to play any song for one day.
The best way to market this would be to sell certificates for finite periods
We don't need ISO for language codes. Besides, two letter codes are too limiting. SIL has organized a very thorough set of three letter codes (usable according to their terms) for every language as part of the Ethnologue project, including artificial languages and sign languages.
As for country codes, I'm sure we can make something up. Just ask the leader of each country what they'd like for us to use for their country, work out the collisions, and compile our own standard (and issue an RFC).
What kind of error checking do you think is needed? I'm sure there is much we could agree on, but maybe there is some we don't. One of the things I want to be sure of is that the system comes up despite errors. Applications should know how to deal with failures in services, for example a mail server that came up OK after the DNS server failed to come up should either sit there and do nothing, or even take itself back down, because of the lack of DNS. I have SSH configured to come up regardless of any other service, and be functional even without DNS. I want the system to come up if at all possible, so I can SSH in, instead of have to drive to the office to grab the console.
But I do check for errors to make sure messages are meaningful. The individual service scripts are still pretty much like those of SYSV; they just have a different location and naming strategy. But I'll let you look for yourself. Here is a copy of the scripts I put up for public access about a year ago. My current running copies have been updated a little bit since then, but not majorly so. If there is interest I could make a new set for general access.
Back in 1999 I rewrote all the init scripts entirely from scratch. I did this after having spent a few years before hacking at init scripts in BSD/OS, OpenBSD, Redhat, Slackware, and Solaris. I experienced all the crankiness of these systems (Redhat and Solaris were the worst) and this time decided to avoid all that. I gave the scripts entirely different names so as not to conflict with existing scripts (was Slackware at this time). That way I could switch between them with just a change of/etc/inittab. It took a few hours, but I had a running fully functional system by the end of the day, and have been running on those scripts, as subsequently better debugged and tweaked, ever since. They booted up noticeably faster than even the Slackware scripts (which were about as fast as the OpenBSD scripts).
Irontically, I didn't do this to get the boot speed. The init scripts are fast enough now that the kernel initialization time is longer, anyway. What I did this for was because I hated having a bunch of separate directories with symlinks in them for each run level. I didn't like having to use specialized tools to manipulate the system (I wanted to routinely use the tools I would have available if I were running from a rescue floppy trying to fix it). That meant doing things with a basic set of shell commands. Yet I didn't want to abandon having separate scripts for each service/daemon being started (or stopped as the case may be). What I ended up doing was creating a single subdirectory for all the individual service scripts, and making the script name have a pattern that included both the startup sequence (stop sequence simply ran backwards), as well as the run levels. Here's what the names in/etc/sys on my system look like:
000.12345.net_lo
020.--345.video_120x58
040.--345.keymap
060.-2345.mouse
100.-2345.net_eth0
101.-2345.net_eth1
190.-2345.gw
200.--345.random
220.-2345.syslog
240.--345.at
260.--345.cron
300.-2345.dns
320.-2345.nsd
400.-2345.ssh_main
410.-2345.ssh_alt
520.--345.inet
540.-2345.ntp
600.--345.mail
620.--345.http
640.--345.rsync
660.-----.pop3
700.----5.xfs
780.--345.ftp
800.--345.cache
950.----5.xdm
Figuring out which run level each service starts in is left as an exercise for the reader. BTW, I think most of the speed comes from the fact that I didn't add a lot of fat to my script system. That's easier to do when you do your own design.
What does it mean to have 2 million telemarketers out of work? Well, if those 2 million people are not putting in their 40 hours a week, then they won't be taking up a total of 40 hours of time each week from a few hundred other people. Imagine what might happen with 80,000,000 more hours of time become available to other people at work, at home, and at the dinner table. Imagine the increased productivity happening at work. Imagine the opportunity to get the home and garden chores done. Imagine being able to actually talk and bond with your family at dinner time. Oh the horror!
When I saw this story on Slashdot, I was trying to think back to having experienced any radio effects back on 27 August, but I couldn't recall any. Then I read the article and saw that it was really a 1998 event only being written about just now, 5 years later. From an academic study perspective, that's fine. The article is about these effects in general and the study being made of them. The 27 August 1998 event was merely an example of one that played a significant role. And as they report, there have been 10 of these since, and the potential for much larger ones.
Microsoft thinks open source is anti-competitive? That's certainly not the case. There are multiple vendors of Linux, including big players like IBM, Novell, Redhat, SGI, Sun, and SuSE. And there are multitudes of small players. And if Linux isn't the best for you, there are other fully interoperable alternatives such as FreeBSD, NetBSD, OpenBSD that are open source, and still more like AIX and Solaris, that are proprietary. Looks like plenty of competition to me.
The problem is Microsoft doesn't want to be in a posititon of having to choose between losing sales or losing a lock on customers. Even if Microsoft were to have been an early adopter of Linux, they would never be able to gain a total market domination in it. And they know this. Microsoft's big fear is having to scale back to what a competitive market really means.
You have to trust something. That which is trusted has to operate in a way that if it were made to do the wrong things, it would do the wrong things. Trust is the belief that it is not going to the wrong things. That which is not trusted has to be operated in a way that restricts its ability to do wrong things. But you cannot operate everything in the restrictive way because you have to trust the very mechanisms of restriction itself. And that generally means the kernel of the operating system, and the most of the hardware, have to be trusted to do the right things.
But the biggest issue is how do you establish that trust? Are you going to personally inspect every line of source code, and understand what it does? Are you going to inspect the engineering of the CPU and associated hardware that can influence how the CPU operates? Because we generally cannot do this on things as complex as computers or software, we have to establish trust by some proxy. If we know someone, and trust them, who has done all that, then we might trust the system. But there really isn't likely to be very many people around who can do that, and perhaps none at all. So somehow we have aggregate that trust proxy, and conclude on the basis of some combination of information, that something is trustable. But this isn't genuine trust. We cannot be certain that something is truly trustworthy just because someone says it is, or that a combination of others say it is.
Ultimately, we have to accept, and learn to deal with, the fact that trust is imperfect. We have to trust not that something cannot do the wrong thing, but that it is highly unlikely to do the wrong thing, and have contingency plans to be able to deal with it doing the wrong thing, which includes knowing that it did the wrong thing (it might try to hide that fact from you). The level we have to use to establish that trust will thus depend on the real and potential costs of the contingency (such as cleaning up the mess it leaves behind, restoring data, etc).
In order to reduce your contingency costs, you have to establish a greater criteria of trust. But the trust has a cost as well (for example hiring several computer scientists to inspect and analyze the code, as well as performing background checks on them to make sure they have no other motives, and even this has costs). It's all a balancing act. And where the optimal balance is will depend on many factors. As your contingency costs increase (a military has very high contingency costs, as it could mean losing to an opponent), your level of trust establishment needs to increase as well.
A standard for security has to address the fact that trust is imperfect, and that different entities will have different contingency costs. So it has to be flexible over a wide range of optimal levels of trust. If it is too rigid, it cannot be universally adopted, and will end up not being in common use (though it might find a niche use in areas matching its trust metrics). Those who are developing such a standard will at the very least need to state up front what the goal is. Is this something they expect to be usable in both a military high command setting, and in a casual home user setting? Unfortunately, I see none of this in the base document at the BOSS working group site.
Slashdot Mirror
You still haven't identified what network you are referring to. And you're still hiding behind "Anonymous Coward". Maybe your network got listed for having a well known spam gang online (those listings never get delisted until the owner states that the spammer is gone and will never be allowed back). Maybe you stated this, but forgot to say what network was involved (like you did in this post to Slashdot). Or maybe your network is still supporting spammers and deserves to remain listed. I don't know which it is since I don't know what network you are talking about. And maybe you are a real spammer. Maybe you are just talking out your arse.
Before the SoBig virus, each mail server receiving mail would, in the course of a day (about how long DNS black list records would be cached), get SMTP connections from a certain set of other mail servers. Most of those mail servers would be the ones from which email regularly comes in. Although people would have lots of email addresses in their address books, and even more in other files, most only regularly exchange mail with a small subset.
Enter the SoBig virus. It gathers up email addresses, not only from the address book, but also from email contents, web cache, documents, and just about everything else. Then it sends email to them in a probably uniform distribution of selection. The number of different domains being sent to from one computer in a day is now much larger than normal (in addition to the increased traffic). At the receiving mail servers, the number of different mail servers the SoBig spam is coming from is also much larger than normal. Now mail servers are getting mail from just about every mail server that has any user with any instance of a user email address that names that receiving server.
With the same mail servers sending mail over and over, the receiving server's DNS cache will have hits very frequently. With an increase in diversity of mail servers trying to deliver the SoBig spam, the number of cache misses goes up. Each cache miss means a query that recurses back to the DNS blacklist servers. Thus the query load on those servers goes up, effectively a DDoS.
Additionally, most DNS servers out there are "open recursive name servers". That means they let anyone, anywhere, do a recursive lookup. Spammers can drive even more load on the DNS blacklists by sending out DNS queries (with forged source addresses, of course, so they don't have to deal with the bandwidth of the answers) to those open recursive name servers, forcing more and more queries to focus in on the authoritative servers for the DNS blacklists.
This attack can be successful because spammers have far more network access from a wide variety of places than there are authoritative name servers for DNS blacklists (the ultimate target). And since recursive DNS lookup only has that server for a source address, all the DNS blacklists will see are queries from those open servers.
One way to address some of this problem is to close off recursive lookups. But given that millions of networks are run by incompetent or non-existant administrators, that isn't likely to happen on the scale needed to prevent the abuse. And it won't stop lookups by the receiving mail servers trying to check out all the different SMTP connections due to the spam from the viruses.
Blacklists will most likely end up having to be done by a means other than DNS, unless blacklist operators can manage to acquire sufficient bandwidth and server power to ride out the loads (which could very well be even greater than the GTLD servers that host "com" and "net" would see). Some form of distributing a static list file will probably happen. And, unfortunately, that means whoever gets listed will have a much harder time getting out of all those distributed lists, as many people won't be updating them as often as they should. The original reason to use DNS was to have a relatively quick means to remove a listing and have it take effect throughout the internet. By breaking the DNS mechanism, the ability to remove a listing is what suffers the most.
What I hope will end up happening is that spammer networks and generic (dialup, cable modem, DHCP, etc) addresses get listed in distributed files, and the more transient cases still get handled by DNS. The listings in DNS would be the ones that won't be so important to big time spammers, so they would be less attractive targets of attack, and if attacked anyway, would not open up the major points spammers find easy to use (e.g. their own networks and the generic networks where open proxies are found all over the place).
Any ISP can get out of SPEWS; it's not hard. The clueless won't know how to, and will instead just blame others for their troubles. Or maybe they just prefer to keep spammers to keep the revenue, and hope not too many other customers leave (hence the blame game to try to convince the customers that they, the ISP, is not at fault for helping to pollute the internet).
I use SPEWS, and choose to use it, because it really is having an effect. Many ISPs have turned back from the dark side as a result of SPEWS. Many ISPs have gotten a clued-in person put into their abuse department as a result of SPEWS. I watch SPEWS listings regularly and see that most listings do get removed, eventually. Show me a case where an ISP really did get rid of all services to all spammers without delay (or if there was a delay, did so at a point in time back from today equal to that delay) and is still listed in SPEWS.
Since you didn't deny that your ISP was harboring spammers, am I to assume there is no basis for such a denial?
And email addresses to go with each number.
Where do you live?
SPEWS does remove listings when the problem clears up. In the case of a first time spammer, this is automatic ... as soon as the spamming stops for a while (or earlier if a notice is given), the listing drops off. In the case of hosting one of the about 200 notorius spam gang members, it does require further steps, including verified termination and posting on NANAE about the takedown. If there is a pattern of harboring spammers, such as having any spam gang on your net 3 times or more, or having the same one come back after termination, then listings get "sticky" and stay much longer (and rightfully so, since there is now evidence that a major spammer might show up again).
Tell me the IP address of the sending mail server, or the SPEWS record number, and I'll look things up (I archive some of the SPEWS data, so I can see some things, as well as the trend over the past year, even the web site is down again).
Hi spammer lover.
SPEWS pressures ISPs to terminate spammers. It works for many ISPs who have cleaned up their act. Some will terminate the spammers now immediately. Some still wait for a small SPEWS listing, but will do so then. A few are still totally clueless and let the listings keep growing and growing until it becomes a serious problem. Those are the ISPs to stay away from. Are you using a clueless ISP?
I presume your ISP was harboring spammers. That's assuming you are not a spammer. ISPs that harbor spammers do get a chance to terminate them (unless it is a well known spam gang). If they don't, it's probably because the ISP needs a financial incentive to do so. SPEWS provides that. All customers of such ISPs are indirectly supporting the harbored spammers when they pay their ISP bill.
You don't have to use SPEWS if you don't want to. The opportunity to know and understand how SPEWS works, so those who do choose to use it, should read and understand what it means. If blocking ISPs that harbor spammers is not what you want to do, then don't use SPEWS. No one is twisting your arm.
SPEWS has been responsible for getting quite many spammers, who would not otherwise have been by other DNSBLs, kicked off their ISPs, and their spamming abuse activities stopped or reduced for a while. And this is what has pissed off a lot of spammers.
Of course, a lot of customers of the listed ISPs never tried to understand, and assumed they were being accused of being a spammer. What they should have done is pressured their ISP to remove the spammer(s).
All 3 name servers for that domain are down. Not a good sign for something intended to be DNS related.
Such a strategy is not needed. It's relatively easy (except under certain PPPoE systems) to hijack someone else's address, when their computer is not turned on. Forging their NIC's MAC address is one way, but even that's not necessary in many cases. This is how people have had their cable internet service terminated for spamming, when in fact they were out of town at the time with their computer turned off and unplugged. The ISPs don't want to admit that their DHCP records only mean what IP was assigned, not what IP was actually used, or even what MAC address was actually used.
Then, there might be an open proxy involved. If I wanted to hide where I was coming from, I would use one of those open proxies (hundreds of spams a day hitting my mail servers reveal an ever growing list of ready to exploit open proxies). A proxy-NAT can translate all attempts to use the internet into traffic sent to that proxy server. UDP might be harder to do, but TCP is easy. Now I don't know if there are any open proxies running on MACs, so that may not be the case in this story, but I would not be surprised if the next erroneous victim is someone who happened to have an open proxy running, either because it was some defective software they chose to use, or because their computer was infected by something that set it up (probably by and for some spammer).
There are other root servers, too. The following command (if you have dig) will show you:
And I'm not referring to whether or not any government entity takes the root servers back from Verisign. I'm saying that we can take them back. It is we who "delegate" the root zone to them in the first place. We just have to take on the work of running it ourselves, or delegate to whoever of our choosing is willing to do that work.
What? How the hell do you get an HTTP 404 error message if there's no server to even connect to?
Verisign can break Vixie's patch. All they have to do is set up a separate name server which pretends to be a .com and .net server, with the very same wildcarded A-record. Now just put in wildcarded NS-records in the actual .com and .net zones in the real GTLD servers (in place of the existing wildcarded A-record). There, now it really looks like a real delegation to a different name server, just like real domains have. The new delegated wildcard server gets the query next, due to the delegation (that looks like a delegation, hence fools the patch), and due to its wildcard (and it doesn't need any other data from the .com or .net zones, since it doesn't get delegated to for real domains), it will answer with an A record of Verisign's choosing. If Verisign wants to keep doing what they are doing, they can defeat this patch by that method.
Then we'll have to make DNS servers filter out specific delegations (as opposed to filtering out non-delegation records where there should be only delegations). Verisign could rotate those delegations daily and fool efforts to block it.
Why not just take back the roots? The only reason Verisign can do what they do is because the GTLD servers they control are delegated to by the root servers (not sure who controls those anymore, but it can't be good). And those root servers are configured in the hint file of name servers all over the internet. So who controls those? We (who have our own name servers) do.
It's a little harder, but not a lot harder, to just run your own root zone. The biggest thing is to gather up all the NS records and associated A records for each TLD. That's a small list (relatively speaking), so it could be done via a few hundred dig commands to the root servers. Or it can be downloaded. Now once you have that data, you replace the .com and .net zones with your own. Of course that begs the question, replace it with what?
If enough people with enough server/network power get together, they can make their own independent "realm" of domain name space, starting with a replacement root zone (as has been done in the past to add new TLDs), and a replacement for both .com and .net.
I can just hear the complaints now (and I've heard them before): "But this will fragment the internet". My answer is: Yes!!!! yes it will! all the better. Imagine being in a whole different name space realm away from spammers and evil corporations. And maybe you can meet me in the .mp3 TLD.
Certain jobs create value in our economy. Others merely divert value around. Telemarketing, for the most part, is the latter. It doesn't add to the economy; it just shifts it around.
Those who don't buy the stuff hawked by telemarketers aren't going to be burning that money in the fireplace because there's nothing left to do with it. Instead, they will spend it on something else, perhaps at an online web store, or at a local store they can visit in person. And they'll have more time to do that, too. It means people shift jobs around and instead of working for someone whose business model takes time away from others, they will be working for someone else whose business model does not.
All of the negatives due to telemarketing will be compensated by similar positives in other areas. But the one thing not carried over is the harrassment endured by those who don't want the telemarketing phone calls disturbing them and taking up their time. Who knows, maybe the next person an unemployed telemarketer doesn't call will be someone who is starting up a decent business that doesn't take from others in order to make a profit. Getting rid of the whole telemarketing industry, I believe, will be an eventual improvement in the economy.
Every system will be cracked. This one is no different. It does not matter how strong the encryption is. It won't be the encryption that matters anyway.
Unlike things like classified documents that government agencies such as the CIA or NSA deal with, where they have very tight controls on who accesses the documents, the media industry has a fundamental problem: they have to let people actually hear and see the content or those people will quit paying for it. That's part of the "analog hole". If you can hear ir or see it, you can record it again. It doesn't matter of the quality of that re-recording is less than perfect, because most people (e.g. everyone but a few perfectionist geeks) already accept slight reduction of quality in the form of lossy compression, and most of them accept even more reduction of quality when dealing with pirated (e.g. free) stuff. This is not about making perfect digital rips. What the digital revolution did is make the Nth generation as good as the 2nd generation. Once the content leaks (1st generation to 2nd generation), it gets re-digitized, and all generations of pirate distribution are now just as good as that 2nd generation, but without the DRM.
Watermarking can help, because the leaked content still has to be presented. But there is sufficient means to do that (e.g. play music through speakers and display video through CRTs, etc), that this is going to be a weak form of protection against the distribution of leaked content. And the distribution itself is going to be easy, because once you have it as a file, it can go anywhere, and during distribution, additional encryption can be added to hide any watermarking that may be visible to copying mechanisms and network sniffers.
This is not a technical problem to be solved. It is really a social, legal, and market problem. It's a people problem.
First of all, as long as some people are "left out", e.g. music and movies won't play on their computer because it isn't running software from Microsoft, then that immediately creates the incentives to make tools, both for cracking and distributing, for those who aren't even considered by the industry to be in their market. And many will justify this under the idea that if the media industry didn't consider them to be "in the market" in the first place (e.g. isn't allowing their DRM to work on BSD, Linux, etc), then there isn't any loss to the industry (e.g. why would they expect me to pay for something I cannot hear or see).
Even the best solution, which would be to stop worrying about copying, and concentrate on the playing process (e.g. make all the content presentation work from sealed hardware which knows what content it is allowed to decrypt via time-controlled certificates), can't prevent the leak. But if the industry stops trying to squeeze everyone so hard, and makes it practical to have and play content, then incentives to steal content will ... never go away, but will ... be much less attractive.
The model I see as best workable is one which not only works without requiring proprietary software on computers and networks, but also takes advantage of P2P networks as well (thus reducing the actual distribution costs to the industry).
A hardware chip would have the means to decrypt the media. It could be part of an internal computer device, such as a sound card, or an external device, such as built in to a video display. It would have an identification key, which would be used to purchase playback certificates. Playback certificates, which would work only on that single device, would have restrictions as to the time frame to allow playback, as well as what content categories and/or producers to allow. You could buy a certificate to allow playing only one song on only one day. Or you could buy a certificate to play that one song forever. Or you could buy a certificate to play any song for one day.
The best way to market this would be to sell certificates for finite periods
We don't need ISO for language codes. Besides, two letter codes are too limiting. SIL has organized a very thorough set of three letter codes (usable according to their terms) for every language as part of the Ethnologue project, including artificial languages and sign languages.
As for country codes, I'm sure we can make something up. Just ask the leader of each country what they'd like for us to use for their country, work out the collisions, and compile our own standard (and issue an RFC).
If that's an enlarged screenshot ... fear the original size.
What kind of error checking do you think is needed? I'm sure there is much we could agree on, but maybe there is some we don't. One of the things I want to be sure of is that the system comes up despite errors. Applications should know how to deal with failures in services, for example a mail server that came up OK after the DNS server failed to come up should either sit there and do nothing, or even take itself back down, because of the lack of DNS. I have SSH configured to come up regardless of any other service, and be functional even without DNS. I want the system to come up if at all possible, so I can SSH in, instead of have to drive to the office to grab the console.
But I do check for errors to make sure messages are meaningful. The individual service scripts are still pretty much like those of SYSV; they just have a different location and naming strategy. But I'll let you look for yourself. Here is a copy of the scripts I put up for public access about a year ago. My current running copies have been updated a little bit since then, but not majorly so. If there is interest I could make a new set for general access.
Back in 1999 I rewrote all the init scripts entirely from scratch. I did this after having spent a few years before hacking at init scripts in BSD/OS, OpenBSD, Redhat, Slackware, and Solaris. I experienced all the crankiness of these systems (Redhat and Solaris were the worst) and this time decided to avoid all that. I gave the scripts entirely different names so as not to conflict with existing scripts (was Slackware at this time). That way I could switch between them with just a change of /etc/inittab. It took a few hours, but I had a running fully functional system by the end of the day, and have been running on those scripts, as subsequently better debugged and tweaked, ever since. They booted up noticeably faster than even the Slackware scripts (which were about as fast as the OpenBSD scripts).
Irontically, I didn't do this to get the boot speed. The init scripts are fast enough now that the kernel initialization time is longer, anyway. What I did this for was because I hated having a bunch of separate directories with symlinks in them for each run level. I didn't like having to use specialized tools to manipulate the system (I wanted to routinely use the tools I would have available if I were running from a rescue floppy trying to fix it). That meant doing things with a basic set of shell commands. Yet I didn't want to abandon having separate scripts for each service/daemon being started (or stopped as the case may be). What I ended up doing was creating a single subdirectory for all the individual service scripts, and making the script name have a pattern that included both the startup sequence (stop sequence simply ran backwards), as well as the run levels. Here's what the names in /etc/sys on my system look like:
Figuring out which run level each service starts in is left as an exercise for the reader. BTW, I think most of the speed comes from the fact that I didn't add a lot of fat to my script system. That's easier to do when you do your own design.
A good reason to send spammers to prison would be that it creates an even greater incentive for other offenders to stay out of prison.
What does it mean to have 2 million telemarketers out of work? Well, if those 2 million people are not putting in their 40 hours a week, then they won't be taking up a total of 40 hours of time each week from a few hundred other people. Imagine what might happen with 80,000,000 more hours of time become available to other people at work, at home, and at the dinner table. Imagine the increased productivity happening at work. Imagine the opportunity to get the home and garden chores done. Imagine being able to actually talk and bond with your family at dinner time. Oh the horror!
When I saw this story on Slashdot, I was trying to think back to having experienced any radio effects back on 27 August, but I couldn't recall any. Then I read the article and saw that it was really a 1998 event only being written about just now, 5 years later. From an academic study perspective, that's fine. The article is about these effects in general and the study being made of them. The 27 August 1998 event was merely an example of one that played a significant role. And as they report, there have been 10 of these since, and the potential for much larger ones.
Microsoft thinks open source is anti-competitive? That's certainly not the case. There are multiple vendors of Linux, including big players like IBM, Novell, Redhat, SGI, Sun, and SuSE. And there are multitudes of small players. And if Linux isn't the best for you, there are other fully interoperable alternatives such as FreeBSD, NetBSD, OpenBSD that are open source, and still more like AIX and Solaris, that are proprietary. Looks like plenty of competition to me.
The problem is Microsoft doesn't want to be in a posititon of having to choose between losing sales or losing a lock on customers. Even if Microsoft were to have been an early adopter of Linux, they would never be able to gain a total market domination in it. And they know this. Microsoft's big fear is having to scale back to what a competitive market really means.
You have to trust something. That which is trusted has to operate in a way that if it were made to do the wrong things, it would do the wrong things. Trust is the belief that it is not going to the wrong things. That which is not trusted has to be operated in a way that restricts its ability to do wrong things. But you cannot operate everything in the restrictive way because you have to trust the very mechanisms of restriction itself. And that generally means the kernel of the operating system, and the most of the hardware, have to be trusted to do the right things.
But the biggest issue is how do you establish that trust? Are you going to personally inspect every line of source code, and understand what it does? Are you going to inspect the engineering of the CPU and associated hardware that can influence how the CPU operates? Because we generally cannot do this on things as complex as computers or software, we have to establish trust by some proxy. If we know someone, and trust them, who has done all that, then we might trust the system. But there really isn't likely to be very many people around who can do that, and perhaps none at all. So somehow we have aggregate that trust proxy, and conclude on the basis of some combination of information, that something is trustable. But this isn't genuine trust. We cannot be certain that something is truly trustworthy just because someone says it is, or that a combination of others say it is.
Ultimately, we have to accept, and learn to deal with, the fact that trust is imperfect. We have to trust not that something cannot do the wrong thing, but that it is highly unlikely to do the wrong thing, and have contingency plans to be able to deal with it doing the wrong thing, which includes knowing that it did the wrong thing (it might try to hide that fact from you). The level we have to use to establish that trust will thus depend on the real and potential costs of the contingency (such as cleaning up the mess it leaves behind, restoring data, etc).
In order to reduce your contingency costs, you have to establish a greater criteria of trust. But the trust has a cost as well (for example hiring several computer scientists to inspect and analyze the code, as well as performing background checks on them to make sure they have no other motives, and even this has costs). It's all a balancing act. And where the optimal balance is will depend on many factors. As your contingency costs increase (a military has very high contingency costs, as it could mean losing to an opponent), your level of trust establishment needs to increase as well.
A standard for security has to address the fact that trust is imperfect, and that different entities will have different contingency costs. So it has to be flexible over a wide range of optimal levels of trust. If it is too rigid, it cannot be universally adopted, and will end up not being in common use (though it might find a niche use in areas matching its trust metrics). Those who are developing such a standard will at the very least need to state up front what the goal is. Is this something they expect to be usable in both a military high command setting, and in a casual home user setting? Unfortunately, I see none of this in the base document at the BOSS working group site.