As of 10:10 AM, my mail server has refused 28 pieces of spam, today, as a result of Spamcop's DNSBL, which I use. So indeed they do have an RBL type service. Maybe you should try it out if you have a mail server.
There is no existing infrastructure to support making truly secure mail servers that can interchange many with anyone legitimate and refuse spam. Such an infrastructure would be the ultimate whitelist. We may well be headed in that direction and some day we might have that. Blacklists certainly won't work in the long term, but until a full whitelist solution is available, it's the best thing we have right now. The problem with whitelists is we have to make it be complete before we can start using it.
I use, and promote, IP blacklisting. Certainly it affects that peer to peer relationship. But so will IP whitelisting (inverse effect). The problem is that peer to peer doesn't really scale up as large as the internet is unless you have some kind of authenticatable identity and qualification infrastructure. Blacklisting sorta behaves that way. Whitelisting would be a lot closer.
Much of the problem is due to the fact that receiving mail is many times more costly than for spammers to send it. Things like IP listing aren't perfect solutions and no one I've seen suggests they are. But in terms of solving the cost shift problem, they are the best we have right now.
It's not just atheist left-wing liberals that are fighting for verifiably honest elections. That majority of Christian right-wing conservatives... once they are aware of the exact issues involved... do as well.
Oh wait, I just replied to a post that lost all its "Funny" moderation points due to an equal number of "Sad" moderation points. OK, which is it.
The complaints echo those that came up when lever machines were introduced in the 1920s, and again when punch cards came on the scene, said Doug Lewis, an expert at The Election Center in Houston, Texas.
The complaints about lever machines in the early 1900's did not come from mechanical engineers. Instead, they came from groups of people who did not understand these "confounded contraptions". The election officials could, or could allow anyone to, examine the insides and workings of these machines. There was no secrecy about it.
Ironically, the complaints about punch cards have, in part, come true. This is why we are doing this rush to computer voting in the first place, because the punch card system in Florida (and as it turns out, elsewhere, too) showed the faults in the system. But despite the flaws in punch card systems, there was no secrecy; they could be examined and the flaws could be seen and understood.
Both systems above were not only "open systems", but also had various audit trails incorporated. While not perfect, punch cards could be manually counted if machine counts were suspect. The flaw with Diebold and other electronic voting systems isn't that they are electronic, nor is it even that they might be connect to, or through, the internet. Instead, the flaw is that unlike their predecessors, these systems are closed, and have no audit trails.
Unlike past systems, where the concerns were raised by people that didn't know much about the technology they were based on, the issues being raised about electronic voting systems are being raised by people who fully understand this technology, the flaws that are inherint in the technology itself, and the methodologies needed to compensate for such flaws, and ensure reliable and correct operation despite such flawed technology. All the voting systems have flaws, and they always will. What sets the past systems apart from what vendors are trying to push on us today is that those past systems were known to be flawed to a certain degree, and they could be examined to verify that. What vendors of electronic machines are asking us to believe is that their systems are absolutely perfect and that no one ever needs to "look inside" to verify anything, and that no audit trails, and no recounts, will be needed.
It is not necessary to focus the IR to make it work. What is necessary is to make the IR from the signaling device stand out from the background IR noise. And this isn't deep IR, just near red IR, so it behaves like light but you can't see it. The way to make it distinguishable is to make it sufficiently strong, aimed forward, and pulsed or modulated. The receiver would not be looking for just an IR level, but for the specific pulsing or modulation pattern. Current technology could make these work 1-2 km distant.
GPS is the way to go. With the location of the vehicle being continuously transmitted to a central control computer, the traffic lights can be directed to favor the approaching emergency vehicle even before that vehicle is in a straight line to it. There are also other advantages to a GPS system which can help keep multiple emergency vehicles using separate roads to avoid congestions or worse (it happens).
The way to do this is to have the traffic control device generate a random 128-bit number every second and transmit that broadly by IR. The vehicle device would take that 128-bit random number, combine it with a 128-bit secret code, generate an MD5 checksum of that 256-bit combination, and send the 128-bit sum back. The traffic control device would perform the same process with each of the (not too many) known valid keys, and compare the incoming vehicle signal against those precomputed sums. If any match, it is most likely a vehicle with a valid code.
This technique is relatively simple. It's big fault is a shared secret key. But since vehicles can have the key installed in a shop, that's not really a big issue. Multiple keys provide for a window to slowly change over vehicle to new keys every few months. Since no information is being transmitted, a man-in-the-middle attacks would be relatively fruitless (you might intercept the IR from one road and redirect it in from another to fool the system) because it would be doable only when an emergency vehicle is approaching.
Many cities are starting to put GPS tracking in emergency vehicles (as well as non-emergency vehicles like buses), and it won't be long until that is tied in to make lights change as vehicles are approaching with no local signalling needed (the light could be going to yellow to give a safe transition to red while the emergency vehicle is still coming around a corner from a cross street a block away).
... an integrated cell phone (that can actually be held and used like one), an integrated 3 Mpix camera/scanner (if it can read handwriting, it can surely read a newspaper), an integrated full quality audio system (supporting MP3, OGG, FLAC, etc), infrared port, ethernet port, 256 MB of RAM, 40 GB of storage, and of course... run BSD/Linux.
The odds of defeating spam by legislation alone is extremely low, but that does not mean we should stand idly by and do nothing about it.
McCain is yet another stupid senator who prefers symbolic feel-good legislation over real laws that can be enforceable (at least in the USA). No, of course senators should not stand idly by and do nothing about it. But neither should they pass useless legislation, either. If he truly wants to solve the problem (as opposed to vote-getting fodder) then he and the others would pass some strong legislation with jail terms involved.
Yes, a web of trusted mail servers is needed. The problem is that there still needs to be some quick way to revoke the trust. You know spammers will set up decoy ISPs, get them whitelisted, and eventually use them to spam. However long the revokation process takes, that's how long they get to spam. And they won't stop at just one. Many spammers are known to have many colocation or high speed access accounts ready for when they get disconnected so they can rapidly shift over to green pastures and keep the pink blob rolling.
It looks like the day is coming where we "blacklist" 0.0.0.0/0 (the whole internet) and then whitelist what you trust, or what someone whom you trust trusts. DNS based whitelists may be where we go with this. But we do need to find a solution to the obvious problem of a whitelist which is that if the name servers go down (such as due to massive DDoS attack by spammers), mail stops flowing. While they did attack DNS based blacklists to cause them to either be unavailable so the spam would get through, or in some cases be permanently shut down, the could just as easily attack DNS based whitelists to make them something people won't want to use (because that attack cripples email entirely). Since DNS based whitelists are in a better legal position than blacklists, it may be easier to get a lot more companies on board and make it so widely distributed that DDoS attacks will be ineffective.
"Solutions" like this do little to stem the tide of spam, they only shift the burden to others.
Given that for every penny spent by spammers to send their junk, the cost imposed on recipients is several pennies (before even counting the costs of the time wasted just pressing delete if the spam isn't blocked), it is already the recipients who have the undue burden here. Of course senders really shouldn't be burdened, either, but then, we also shouldn't have spam but we do.
Spammers are constantly trying to make their junk look like legitimate mail. Senders of truly legitimate mail, however, will have to stay a step ahead of spammers and ensure that their mail is very distinguishable from spam. But as experience shows, things like the content of the message, and even that the sending mail server looks like a perfectly configured network, do not distinguish the sender very much at all. What AT&T is asking is that senders distinguish their mail servers to them at this point. By asking AT&T to whitelist your mail server, I presume they will grant you conditional trust. At this point, if you spam them, then they can remove you from the whitelist.
The real problem will be when every business, network, and even individual starts to do this. Imagine every time your IP address changes that you have to notify millions of other network administrators about it. What is needed is a central clearinghouse for this which is run by someone who can be trusted, and can be updated quickly. That would be like current spam blacklists, but inverted to be a whitelist instead. I've said as much as 5 years ago that we would be headed that way. It looks like AT&T has turned in that direction. Now we just have to make the whole thing manageable and scalable.
You might want to look into using NAT to work in IPv4 while presenting IPv6 (which in turn would be what you would tunnel over IPv4 on the wild commercial internet).
Then I suggest two internets. I've already suggested this very same idea with regard to the spam problem (let there be one with spam, and one without spam, and then the spammers will have their place to speak freely).
It would be more practical to just create a new internet apart from the existing one (though "circuits" in the new one might just be tunnels in the present one). Some have said "the internet was good before the MBAs came, so we should just kick them out". Certainly it is true, but it really isn't practical to change it now; it's just way too late. What is needed is a new one.
But wait...
We can create a "new" internet using the existing internet. If we just start a whole new set of root servers, and new top level domains, and make mail servers refuse any traffic from any addresses that don't properly validate a reverse DNS under the new name hierarchy, we would have pretty much good separation anyway, without the cost of a whole new infrastructure.
And I suggest we do this entirely with IPv6 only (starting with tunnels, migrating to raw circuits as backbones finally get IPv6 deployed). We don't actually have to use "their" root servers, so why should we.
The present root servers only serve that purpose because we (who have name servers) allow them to. There is a file that comes with recursive name servers that "seeds" them to know where the root servers are (you have to start with some IP addresses). Many people might not yet be aware, but there are separate servers for the "." zone (the root), and top level domains (TLDs) like ".com" (more correctly "com."). It is the root zone that delegates authority to the top level domain servers. By configuring your name server to be authoritative for the root zone, you can choose where each top level domain is delegated to.
What I proposed a few years ago, which seems even more important these days, is that name server operators (and anyone can operate their own for their own use, and the use of anyone they allow to use it) "take back the roots" and control which name servers they want to refer to for each top level (or lower) domain name. This would allow genuine competition in things like different policies for domains like "com" or "net", and the introduction of new names as soon as someone wants to offer them.
It would also have the effect of fragmenting the internet, as many have pointed out in my past postings of this proposal. But I say that's a good thing; I'd like to be fragmented from spammers, RIAA, etc.
Content filtering doesn't work if you don't have the content, yet. And by the time you do have the content, you already have most of the impact of the spam. You might as well just press delete, since at this point all that content filtering is doing for you is an automatic delete (unless, of course, you're silly enough to set up a spam folder for it all to be put into, which means you'll end up sifting through it for something important, anyway).
There is hope that spammers will just stop spamming if everyone just deletes the mail (even if automatically). But that is a false hope because it only takes a few dumb souls to respond, and the spammers succeed at their goals. Then they will keep on spamming, and they will keep on doing it on the cheap which means they won't clean their lists (because cleaning them costs more than just mass mailing to everyone).
This issue comes down to objective. What is it we are trying to accomplish? Are we trying to take spammers out of existance? Or are we trying to shed the costs that spammers are imposing on us? Adding on things like Bayesian filtering are increasing our costs, not just in the processing it takes, but also in the fact that we have to accept the data stream of every message to do that.
What makes you think that if SUN were to decide that it is a hardware company and focus on SPARC that it would have to fight Linux? If it did make that move, it would not be focusing on Solaris specifically, so Linux would still be viable, especially on the lower end machines.
SPARC is still a viable processor, but it needs work. Solaris is still a viable operating system, but it needs work. But if doing this won't work in business, then SUN just needs to be bought out, perhaps by IBM (then SPARC will probably become the "s-Series").
Licenses really can be revoked under the terms of the license itself. The terms a government issues a drivers license under would include the specific laws involved. They cannot just arbitrarily revoke a drivers' license, but they can under those specific laws. If you commit certain actions the law says you may lose your license for, it can be revoked.
Likewise, a private license for use of some property can also be revoked under the agreed terms. Generally, if the agreed terms are violated, the license can be revoked. If SGI and/or IBM did release UNIX intellectual property to the public, that would be such a violation. And we do know SCO is claiming that.
The issue now comes down to whether such a claim is valid. Did SGI take XFS from UNIX and release it publically. That cannot be the case, however, because there is no XFS in UNIX. SGI developed XFS themselves. Arguably, pieces of XFS might have gotten some UNIX code in there, but once pointed out, that can be removed. Did SCO perform due diligence in pointing that out? Not until recently have they started pointing at any specific violations (while still making vague and unsubstantiated claims that lots of other violations exist), and those are weak due to previous releases in other forms.
And how the hell do we know there isn't any violations in SCO's non-Linux closed-source product... violations of the GPL with code taken from Linux and put in there?
You can't take code based on a license you signed, change it a little and then give it away for free (as in the case of XFS from SGI). If SCO allowed companies to contribute derivative UNIX code to Linux and give it away for free, it would destroy the value of all other versions of UNIX, including SCO?s own, not to mention the versions of UNIX made by SUN, HP, IBM, SGI, Sequent, Hitachi, Fujitsu, Siemens, and every other one of the 6,000 other licensees. Why would SCO not have such a provision in their licenses? This line of thinking is absolutely ludicrous.
What is ludicrous is thinking that that an entirely new development (as in the case of XFS from SGI) can somehow be thought of as derivative from UNIX just because it might be added back in to it. Maybe I should be calling up the DEA about the heavy drug use going on in Utah. Just because SGI integrated code licensed from SCO with their own development does not transfer ownership of that code to SCO, unless there were specific terms of that in the license SGI signed. And if that was the case, SCO wouldn't be trying to claim XFS is derived from UNIX, but would instead be pointing clearly to that clause. It isn't there and SCO has no rights to XFS other than as SGI has licensed (GPL?).
Many big businesses all the time do cross-licensing where each ends up with rights to use intellectual property of the other. SCO somehow thinks they get to own everything (like their claim to the entirety of Linux, even though hundreds of developers unrelated to SCO did the actual work).
RPM is not the only packaging system to do that. Debian, Slackware, and Solaris have their own packaging systems that do it. Been there, done that (at least with the latter two).
The problem with C/R systems is that most of the spam these days has sender email addresses that are forged from the same spam list, or in the case of virus junk, forged from one of the other addresses found on the infected machine. C/R will then take this yet-unverified address and send mail to it. Because of the wide range of these address pairings, most will be people who don't know each other, and thus won't be whitelisted. That means nearly all spam sends, or attempts to send, some C/R message, nearly doubling the email load.
My solution is to restrict C/R to only those cases where other anti-spam methods, whatever you may choose, would have otherwise generated a bounce message. So in effect, C/R is just a new bounce message with a clue included.
Which is why I don't use it. I compile all the critical software, and a lot of other software, on my systems from the original source. Some packages even have local source mods (patches). The reason to use a binary packaging system in this case is that it forms a convenient way to compile once, and install on many systems. Unless doing a source compile on each machine, this ensures each machine has a checksum verifiable identical copy of every file. I don't need the dependency tracking for the purpose of re-distributing to all the servers. And it gets in the way of doing local compiles with local mods. So I use the simplest packaging method that gets the job done.
"Try to find the real IP," he said. "This host is in rackshack.net, the most antispam ISP."
My experience with rackshack.net (e.g. ev1.net) is quite the opposite. While one of their hosted spammers was making a 3 week long run of thousands of spam to my mail server, this was repeatedly reported to them, including by telephone call, and they did nothing about it... at least not for 3 weeks. That is why rackshack.net and ev1.net have earned a special place in my private blacklists to block their entire network. Only their CEO can make arrangements to get it unlisted now.
Slashdot Mirror
As of 10:10 AM, my mail server has refused 28 pieces of spam, today, as a result of Spamcop's DNSBL, which I use. So indeed they do have an RBL type service. Maybe you should try it out if you have a mail server.
There is no existing infrastructure to support making truly secure mail servers that can interchange many with anyone legitimate and refuse spam. Such an infrastructure would be the ultimate whitelist. We may well be headed in that direction and some day we might have that. Blacklists certainly won't work in the long term, but until a full whitelist solution is available, it's the best thing we have right now. The problem with whitelists is we have to make it be complete before we can start using it.
I use, and promote, IP blacklisting. Certainly it affects that peer to peer relationship. But so will IP whitelisting (inverse effect). The problem is that peer to peer doesn't really scale up as large as the internet is unless you have some kind of authenticatable identity and qualification infrastructure. Blacklisting sorta behaves that way. Whitelisting would be a lot closer.
Much of the problem is due to the fact that receiving mail is many times more costly than for spammers to send it. Things like IP listing aren't perfect solutions and no one I've seen suggests they are. But in terms of solving the cost shift problem, they are the best we have right now.
It's not just atheist left-wing liberals that are fighting for verifiably honest elections. That majority of Christian right-wing conservatives ... once they are aware of the exact issues involved ... do as well.
Oh wait, I just replied to a post that lost all its "Funny" moderation points due to an equal number of "Sad" moderation points. OK, which is it.
From the CNN article:
The complaints about lever machines in the early 1900's did not come from mechanical engineers. Instead, they came from groups of people who did not understand these "confounded contraptions". The election officials could, or could allow anyone to, examine the insides and workings of these machines. There was no secrecy about it.
Ironically, the complaints about punch cards have, in part, come true. This is why we are doing this rush to computer voting in the first place, because the punch card system in Florida (and as it turns out, elsewhere, too) showed the faults in the system. But despite the flaws in punch card systems, there was no secrecy; they could be examined and the flaws could be seen and understood.
Both systems above were not only "open systems", but also had various audit trails incorporated. While not perfect, punch cards could be manually counted if machine counts were suspect. The flaw with Diebold and other electronic voting systems isn't that they are electronic, nor is it even that they might be connect to, or through, the internet. Instead, the flaw is that unlike their predecessors, these systems are closed, and have no audit trails.
Unlike past systems, where the concerns were raised by people that didn't know much about the technology they were based on, the issues being raised about electronic voting systems are being raised by people who fully understand this technology, the flaws that are inherint in the technology itself, and the methodologies needed to compensate for such flaws, and ensure reliable and correct operation despite such flawed technology. All the voting systems have flaws, and they always will. What sets the past systems apart from what vendors are trying to push on us today is that those past systems were known to be flawed to a certain degree, and they could be examined to verify that. What vendors of electronic machines are asking us to believe is that their systems are absolutely perfect and that no one ever needs to "look inside" to verify anything, and that no audit trails, and no recounts, will be needed.
It is not necessary to focus the IR to make it work. What is necessary is to make the IR from the signaling device stand out from the background IR noise. And this isn't deep IR, just near red IR, so it behaves like light but you can't see it. The way to make it distinguishable is to make it sufficiently strong, aimed forward, and pulsed or modulated. The receiver would not be looking for just an IR level, but for the specific pulsing or modulation pattern. Current technology could make these work 1-2 km distant.
GPS is the way to go. With the location of the vehicle being continuously transmitted to a central control computer, the traffic lights can be directed to favor the approaching emergency vehicle even before that vehicle is in a straight line to it. There are also other advantages to a GPS system which can help keep multiple emergency vehicles using separate roads to avoid congestions or worse (it happens).
The way to do this is to have the traffic control device generate a random 128-bit number every second and transmit that broadly by IR. The vehicle device would take that 128-bit random number, combine it with a 128-bit secret code, generate an MD5 checksum of that 256-bit combination, and send the 128-bit sum back. The traffic control device would perform the same process with each of the (not too many) known valid keys, and compare the incoming vehicle signal against those precomputed sums. If any match, it is most likely a vehicle with a valid code.
This technique is relatively simple. It's big fault is a shared secret key. But since vehicles can have the key installed in a shop, that's not really a big issue. Multiple keys provide for a window to slowly change over vehicle to new keys every few months. Since no information is being transmitted, a man-in-the-middle attacks would be relatively fruitless (you might intercept the IR from one road and redirect it in from another to fool the system) because it would be doable only when an emergency vehicle is approaching.
Many cities are starting to put GPS tracking in emergency vehicles (as well as non-emergency vehicles like buses), and it won't be long until that is tied in to make lights change as vehicles are approaching with no local signalling needed (the light could be going to yellow to give a safe transition to red while the emergency vehicle is still coming around a corner from a cross street a block away).
... a shark fin attachment?
... an integrated cell phone (that can actually be held and used like one), an integrated 3 Mpix camera/scanner (if it can read handwriting, it can surely read a newspaper), an integrated full quality audio system (supporting MP3, OGG, FLAC, etc), infrared port, ethernet port, 256 MB of RAM, 40 GB of storage, and of course ... run BSD/Linux.
... if the control computer runs Windows.
The camera I want will:
It would be nice if it:
I guess I can dream for:
McCain is yet another stupid senator who prefers symbolic feel-good legislation over real laws that can be enforceable (at least in the USA). No, of course senators should not stand idly by and do nothing about it. But neither should they pass useless legislation, either. If he truly wants to solve the problem (as opposed to vote-getting fodder) then he and the others would pass some strong legislation with jail terms involved.
Yes, a web of trusted mail servers is needed. The problem is that there still needs to be some quick way to revoke the trust. You know spammers will set up decoy ISPs, get them whitelisted, and eventually use them to spam. However long the revokation process takes, that's how long they get to spam. And they won't stop at just one. Many spammers are known to have many colocation or high speed access accounts ready for when they get disconnected so they can rapidly shift over to green pastures and keep the pink blob rolling.
It looks like the day is coming where we "blacklist" 0.0.0.0/0 (the whole internet) and then whitelist what you trust, or what someone whom you trust trusts. DNS based whitelists may be where we go with this. But we do need to find a solution to the obvious problem of a whitelist which is that if the name servers go down (such as due to massive DDoS attack by spammers), mail stops flowing. While they did attack DNS based blacklists to cause them to either be unavailable so the spam would get through, or in some cases be permanently shut down, the could just as easily attack DNS based whitelists to make them something people won't want to use (because that attack cripples email entirely). Since DNS based whitelists are in a better legal position than blacklists, it may be easier to get a lot more companies on board and make it so widely distributed that DDoS attacks will be ineffective.
Given that for every penny spent by spammers to send their junk, the cost imposed on recipients is several pennies (before even counting the costs of the time wasted just pressing delete if the spam isn't blocked), it is already the recipients who have the undue burden here. Of course senders really shouldn't be burdened, either, but then, we also shouldn't have spam but we do.
Spammers are constantly trying to make their junk look like legitimate mail. Senders of truly legitimate mail, however, will have to stay a step ahead of spammers and ensure that their mail is very distinguishable from spam. But as experience shows, things like the content of the message, and even that the sending mail server looks like a perfectly configured network, do not distinguish the sender very much at all. What AT&T is asking is that senders distinguish their mail servers to them at this point. By asking AT&T to whitelist your mail server, I presume they will grant you conditional trust. At this point, if you spam them, then they can remove you from the whitelist.
The real problem will be when every business, network, and even individual starts to do this. Imagine every time your IP address changes that you have to notify millions of other network administrators about it. What is needed is a central clearinghouse for this which is run by someone who can be trusted, and can be updated quickly. That would be like current spam blacklists, but inverted to be a whitelist instead. I've said as much as 5 years ago that we would be headed that way. It looks like AT&T has turned in that direction. Now we just have to make the whole thing manageable and scalable.
You might want to look into using NAT to work in IPv4 while presenting IPv6 (which in turn would be what you would tunnel over IPv4 on the wild commercial internet).
Then I suggest two internets. I've already suggested this very same idea with regard to the spam problem (let there be one with spam, and one without spam, and then the spammers will have their place to speak freely).
It would be more practical to just create a new internet apart from the existing one (though "circuits" in the new one might just be tunnels in the present one). Some have said "the internet was good before the MBAs came, so we should just kick them out". Certainly it is true, but it really isn't practical to change it now; it's just way too late. What is needed is a new one.
But wait ...
We can create a "new" internet using the existing internet. If we just start a whole new set of root servers, and new top level domains, and make mail servers refuse any traffic from any addresses that don't properly validate a reverse DNS under the new name hierarchy, we would have pretty much good separation anyway, without the cost of a whole new infrastructure.
And I suggest we do this entirely with IPv6 only (starting with tunnels, migrating to raw circuits as backbones finally get IPv6 deployed). We don't actually have to use "their" root servers, so why should we.
The present root servers only serve that purpose because we (who have name servers) allow them to. There is a file that comes with recursive name servers that "seeds" them to know where the root servers are (you have to start with some IP addresses). Many people might not yet be aware, but there are separate servers for the "." zone (the root), and top level domains (TLDs) like ".com" (more correctly "com."). It is the root zone that delegates authority to the top level domain servers. By configuring your name server to be authoritative for the root zone, you can choose where each top level domain is delegated to.
What I proposed a few years ago, which seems even more important these days, is that name server operators (and anyone can operate their own for their own use, and the use of anyone they allow to use it) "take back the roots" and control which name servers they want to refer to for each top level (or lower) domain name. This would allow genuine competition in things like different policies for domains like "com" or "net", and the introduction of new names as soon as someone wants to offer them.
It would also have the effect of fragmenting the internet, as many have pointed out in my past postings of this proposal. But I say that's a good thing; I'd like to be fragmented from spammers, RIAA, etc.
Content filtering doesn't work if you don't have the content, yet. And by the time you do have the content, you already have most of the impact of the spam. You might as well just press delete, since at this point all that content filtering is doing for you is an automatic delete (unless, of course, you're silly enough to set up a spam folder for it all to be put into, which means you'll end up sifting through it for something important, anyway).
There is hope that spammers will just stop spamming if everyone just deletes the mail (even if automatically). But that is a false hope because it only takes a few dumb souls to respond, and the spammers succeed at their goals. Then they will keep on spamming, and they will keep on doing it on the cheap which means they won't clean their lists (because cleaning them costs more than just mass mailing to everyone).
This issue comes down to objective. What is it we are trying to accomplish? Are we trying to take spammers out of existance? Or are we trying to shed the costs that spammers are imposing on us? Adding on things like Bayesian filtering are increasing our costs, not just in the processing it takes, but also in the fact that we have to accept the data stream of every message to do that.
What makes you think that if SUN were to decide that it is a hardware company and focus on SPARC that it would have to fight Linux? If it did make that move, it would not be focusing on Solaris specifically, so Linux would still be viable, especially on the lower end machines.
SPARC is still a viable processor, but it needs work. Solaris is still a viable operating system, but it needs work. But if doing this won't work in business, then SUN just needs to be bought out, perhaps by IBM (then SPARC will probably become the "s-Series").
Licenses really can be revoked under the terms of the license itself. The terms a government issues a drivers license under would include the specific laws involved. They cannot just arbitrarily revoke a drivers' license, but they can under those specific laws. If you commit certain actions the law says you may lose your license for, it can be revoked.
Likewise, a private license for use of some property can also be revoked under the agreed terms. Generally, if the agreed terms are violated, the license can be revoked. If SGI and/or IBM did release UNIX intellectual property to the public, that would be such a violation. And we do know SCO is claiming that.
The issue now comes down to whether such a claim is valid. Did SGI take XFS from UNIX and release it publically. That cannot be the case, however, because there is no XFS in UNIX. SGI developed XFS themselves. Arguably, pieces of XFS might have gotten some UNIX code in there, but once pointed out, that can be removed. Did SCO perform due diligence in pointing that out? Not until recently have they started pointing at any specific violations (while still making vague and unsubstantiated claims that lots of other violations exist), and those are weak due to previous releases in other forms.
And how the hell do we know there isn't any violations in SCO's non-Linux closed-source product ... violations of the GPL with code taken from Linux and put in there?
What is ludicrous is thinking that that an entirely new development (as in the case of XFS from SGI) can somehow be thought of as derivative from UNIX just because it might be added back in to it. Maybe I should be calling up the DEA about the heavy drug use going on in Utah. Just because SGI integrated code licensed from SCO with their own development does not transfer ownership of that code to SCO, unless there were specific terms of that in the license SGI signed. And if that was the case, SCO wouldn't be trying to claim XFS is derived from UNIX, but would instead be pointing clearly to that clause. It isn't there and SCO has no rights to XFS other than as SGI has licensed (GPL?).
Many big businesses all the time do cross-licensing where each ends up with rights to use intellectual property of the other. SCO somehow thinks they get to own everything (like their claim to the entirety of Linux, even though hundreds of developers unrelated to SCO did the actual work).
RPM is not the only packaging system to do that. Debian, Slackware, and Solaris have their own packaging systems that do it. Been there, done that (at least with the latter two).
The problem with C/R systems is that most of the spam these days has sender email addresses that are forged from the same spam list, or in the case of virus junk, forged from one of the other addresses found on the infected machine. C/R will then take this yet-unverified address and send mail to it. Because of the wide range of these address pairings, most will be people who don't know each other, and thus won't be whitelisted. That means nearly all spam sends, or attempts to send, some C/R message, nearly doubling the email load.
My solution is to restrict C/R to only those cases where other anti-spam methods, whatever you may choose, would have otherwise generated a bounce message. So in effect, C/R is just a new bounce message with a clue included.
Which is why I don't use it. I compile all the critical software, and a lot of other software, on my systems from the original source. Some packages even have local source mods (patches). The reason to use a binary packaging system in this case is that it forms a convenient way to compile once, and install on many systems. Unless doing a source compile on each machine, this ensures each machine has a checksum verifiable identical copy of every file. I don't need the dependency tracking for the purpose of re-distributing to all the servers. And it gets in the way of doing local compiles with local mods. So I use the simplest packaging method that gets the job done.
From the article:
My experience with rackshack.net (e.g. ev1.net) is quite the opposite. While one of their hosted spammers was making a 3 week long run of thousands of spam to my mail server, this was repeatedly reported to them, including by telephone call, and they did nothing about it ... at least not for 3 weeks. That is why rackshack.net and ev1.net have earned a special place in my private blacklists to block their entire network. Only their CEO can make arrangements to get it unlisted now.