This will be easy to fix. A hack to your NAT box source code (you are doing NAT with OpenBSD, Linux or some other open source system, right?) to remove the TTL decrement for NAT traffic (or re-increment it where the decrement can't tell the difference) would get around that aspect of the problem. I'd argue that one can NAT in a transparent "switch", which would not decrement TTL, so why not just make the OpenBSD or Linux box do that.
And for fun, add a randomizer to the initial TTL value. Thus instead of it starting at say 128, it could be a randomly chosen value between 100 and 140 (just to pick some arbitrary numbers).
If the spammer runs a normal MTA, the 550 codes are likely to result in a bounce, but it probably goes to a mailbox that discards it in some way. I'm sure they can't be bothered with cleaning up their lists.
If they are running spamware, those nasty programs that make a thousand concurrent connections and sends the same message to everyone in the list, it certainly can see that 550 code, but probably does nothing about it. They must justify that to themselves as "the address might still be good, but the server blocked me, so I'll just leave the address in for later when they stop blocking". In many cases the list is on CD, so it wouldn't be able to delete it and keeping a no-send list is probably more costly (to keep checking it in the future) than to just try addresses that can't be sent to.
I've seen lots of spam, usually from big spammer operations, which have return addresses that encode the victim address. So clearly they have some means to potentially process it. But they might also be doing that only to track complaints. And if they are doing that from spamware, it might not deal with the fact that it happens during delivery, and just handle it only when a bounce comes back.
I've already written my own protocol to replace SMTP. I set up three servers to send mail to each other. They've been busy at it all weekend testing it out. It looks like a great success. There's been no spam at all:-)
You'll never educate enough people to stop buying via spam for that to really ever slow it down. Besides, those who actually want to buy things from people they don't know, who sent them a deal they never asked for, is their right.
The problem is, for spammers to reach the 0.1% out there who might buy something from them, they end up pounding on our mail servers, and flooding our mail boxes. I do know that if spammers would pay attention to those "550" response codes they get on SMTP connections, and delete the address from their list as "undeliverable", 99% of the delivery attempts on my mail servers would cease. And that's where a substantial amount of the cost of spam comes from.
It seems the folks over at Novell have the answer to making the "immature" Linux OS more...
I paused at that statement. My first thought was where would they even find a copy of an immature Linux OS. But alas, not all is lost. It seems our friends over at ibiblio.org have archived a number of different versions of immature Linux, ready for download. Check it out:
You are suggesting a mail message rate quota. That's actually a good idea, if the ISP will do it. Few do. The question is what to do with an ISP that then refuses to play along. As you point out, they can be blocked. I do that already as do thousands of others. Then we face all the whiners citing unfairness, collateral damage, can't change ISP, etc.
The value of an open relay is almost nothing. The only thing I see it for is that very occaisional necessary anonymous email. Travelers no longer need it because all the major mail clients and server now can support authenticated SMTP. So just get an ISP that has a mail server with such support and use such a client, and you can email from anywhere. Be sure your ISP offers it on a port other than 25 because many ISPs don't let generic addresses (e.g. dialups and such) to access port 25 outside of their own network.
I'm not saying we need a law change. But I am saying we do end up having a law change, we should do it right. The risk of letting politicians do it without our "guidance" is foolhardy. The suggestions you make are good, and are already being done by many (at least the part about blocking ISPs that let spam leak out), and need to be done by more.
One of those ISPs that is not cutting off spammers is Rackspace. And their upstream backbone providers are not cutting them off, either. I'd love to see those bastards shut down and their officers put in prison.
Re:We do need a systems change though!
on
AOL Sues Spammers
·
· Score: 1
The throttling should be done as close to the source as possible. The law should be applied only there. If an ISP is outside the jurisdiction of that law, then it should be applied at the nearest point crossing the jurisdictional border (e.g the connection going out of the country).
And the law should only require the necessary minimum stoppage. For example if the problem is a high speed packet attack from one source to one victim network, then it is acceptable for the victim's address to be used to filter packets at the connection, where practical to do so (maybe only if one or two victim networks in the case high bandwidth trunks, if that). But that's just a direct attack scenario, not a spam situation. For spam, the victims are generally everyone, so cutting off the sender regardless of the destination, or the whole trunk, may be necessary.
We need to treat spam like a DDoS problem, where the victims are simply wide spread rather than focused on a few. What if several hundred thousand connected computers were making as many connection attempts as they could to random addresses and port 80? That could be a lot of traffic. And we've seen that before.
Re:We do need a systems change though!
on
AOL Sues Spammers
·
· Score: 1
And what if that ISP that takes the money doesn't do anything about the spam source? If the action to be taken is an action of law, then I certainly would agree that the action should be done against this ISP and not the backbone. But what if this bad ISP taking money from a spammer is outside the jurisdiction of the law? I would in this case consider it acceptable for the backbone ISP to be required to disconnect the bad ISP. Now what if this connection is actually a huge trunk going to another country, say for example the connection between a Caribbean Islands nation and the United States?
When it's a matter of law, I would say it can be done to control abuses (and not just spam... include other things like DDoS attacks, etc), but must be done in a minimum way to manage and control the abuse. For example if that other nation out of reach of the law is only attacking one single network somewhere in the US, and the owner of that network wants to invoke the cut-off provisions, then it would be acceptable for the "cut off" to be in the form of a filter that prevents packets coming via that trunk only, addressed to that network, to be blocked. Of course if the ISP operating that connection decides it would rather take down the whole thing that deal with all the filters that would have to be added, that should be their option. The point is, if some network is being attacked, it should be the responsibility of the ISP (backbone or otherwise) closest to the source of the attack (where identifiable), within the jurisdiction of the applicable law where those outside fail to voluntarily do that action to clear up the attack, then the action must be taken to block that attack, and the law can only require the minimum amount of action necessary to block it.
One aspect of the spam problem is not unlike a DDoS. Imagine what the cost would be to service 1 billion SMTP connection attempts every day. That's 360 gigabytes of traffic every day (60 byte packet, 6 SYNs sent if no connection is established), or 33.333333 megabits every second (assuming it is evenly distributed in time). And that's just the bandwidth cost assuming spam is filtered at the router near the server (e.g. the SYNs never reach the server). Servicing 1 billion SMTP connections at the server involves all the bandwidth to carry out as much of the SMTP connection as the server allows before cutting it off, which can be substantially higher if the server allows the DATA portion to be transmitted. At 1 billion a day, that's 11,574 per second. That's a LOT of added servers just to deal with and refuse spam. And again, that assumes an even distribution in time.
One cracker who "owns" thousands of machines that can be used to attack some network with a DDoS attack can certainly cause a huge problem. But the aggregate of spam is just as much of a problem for large companies like AOL. We shouldn't treat it as any less of a problem because it's not one single individual causing it. We can't ignore the problem just because the perpetrators are many, or because they and their ISP might be out of reach of the jurisdiction of the victim.
If all the various classes of objects that have a rotate method need to send a message to the update display method, why can't the inheritance mechanism provide for that by having an inherited rotate method that, instead of being replaced by a rotate method included in the inheriting class, just invoke them both? What would be needed is a special primitive to be used in the superior rotate method that indicates where the inferior rotate method is applied. Suppose that mechanism is an "inferior" statement. The superior rotate method might be as small as having code to first do "inferior" followed by "update display" and that's all. This would be more mechanical than AOP promises, but at least it would avoid having the display updated before the rotation.
I was originally going to propose this for 126/8, but this netblock seems more appropriate. ARIN should take 69/8 back and re-assign it specifically for the purpose of spammers and their hosting services. Make it illegal (like maybe a death penalty) for doing any spamming or hosting any spammers unless it's done from this block of address space.
The problem is Comcast is incompetent. Their so called *business account* static IP is still labeled as a dynamic one through their reverse DNS. That's how I block them (by reverse DNS name), and that's probably how AOL does, too. If Comcast can't fix it and make it look exactly like a real business account, then they are providing you with less than they claim, and this is fraud. Sue them or just switch. Or get dialup for the outbound mail and keep surfing via cable.
3. Use GPG to keep your mail from being read. If you really need to hide who it is you send mail to, use a secure tunnel (you don't need to talk to anyone who is not capable of doing that).
Speakeasy will do reverse DNS. I've come across more than one person who has had it done. Also ask them, if they submit dynamic IP lists, to be sure than your static IP is not included on that list.
The solution is not blacklisting DSL and cable connections(because, among other things, it's not easy to switch, unlike dialup.)
Then get a dedicated/static IP address and have reverse DNS properly configured on it. That's easy to do, so don't take any bullshit from your provider if they say they can't do it or don't understand what you are talking about. If they can't do that right and still advertise as an internet service, sue them for fraud. Or just work harder at switching ISP. Ever heard of colocating? Of course if you want it cheap, you get what you pay for.
Many networks have different addresses for hosts that send mail and hosts that receive mail. Requiring that the sender have an MX listing, and hence be a receiver, too, is stupid. Of course the sender could just not listen to port 25, but that still ends up with a system where mail going the other way doesn't work right. You need a different means to authenticate the sending MTA. Secure certificates would be workable over the existing SMTP with STARTTLS added. And it would be possible to gradually deploy that.
As for spammers buying domains... I know of at least one spammer that does that every day. Yes, a new domain name ever day. Spammers do make tons of money from all the gullible business types out there that are looking to expand their marketing and don't know the issues involved in email. Buying a domain a day is a drop in the bucket for a bigtime spammer.
In a way I agree with what you say. The last thing company executives need is some middle manager putting a spin on things, and distorting the message. But there need to be some limits, too. The thing is, having the CEO or CFO come wasting your time is not an issue I've encountered. The few times I've dealt with that level of management, they were good time management people and got to the point and didn't waste my time, either.
But the time of techies can be wasted, depending on what the job responsibility is. If your job is not to support all the desktop users in the company, then you do need a gatekeeper so you aren't dealing with the trivial problems and the endless stupid questions. That's what first level support is for. And that's not your manager's job, either.
Of course, if your job is first level support, then all the BS comes with the territory... live with it. But if you're a developer or network engineer or whatever, the important thing is to make sure your time is properly managed and the priorities are properly ordered. Either you do that or your manager does. Just be clear between you who does what.
This is one of the reasons I prefer to block spam on the basis of who (sender) or what (server, network, ISP's network) sent it. I never even see the content, so it's not about what the message is. It's about abuse of my time, my server's resources, and my network's bandwidth, for some activity that I did not give permission for the use of my property for. And yes, I do significantly whitelist. I have 4 Asian countries and 2 South American countries fully blacklisted (the whitelisting then lets specific people therein to send to me). I have several US and European ISPs fully blacklisted (and again, the whitelisting makes exceptions). It is possible that in time I might end up having to blacklist the entire network and then depend on whitelisting each individual.
It's not the fact that email is unsolicited that bothers me. It's the fact that unsolicited is combined with bulk (e.g. impersonal because the sender used a list rather than personally being aware of each recipient they are sending to by having typed it in manually for each message) that bothers me. That and I get hundreds a day.
It will not reduce the total volume of spam. Instead, it will actually increase it because it will be used by spammers as justification to fight the ISPs that try to disconnect them. Those ISPs, fearing being sued, will then let the spammers continue abusing everyone else's mail servers (those who don't have mail servers of their own will end up paying more to cover the increased costs of their own ISP having to upgrade the server capacity to deal with all the postage-due spam).
Right now, one major problem is that many ISPs are refusing to terminate spammers. That needs to be changed. The ISPs that let spammers abuse networks should be equally liable for the costs if they refuse to terminate the spammer immediately.
Defining spam is, of course, a major difficulty. The way I define it is when both of the following are met:
unsolicited: If I didn't ask for it, it's unsolicited. And that includes someone else asking and using my email address, whether done to annoy me or by mistake. If the mailer wants to protect themselves, they will verify the email address with the request first, not include any advertising in that verification, and identify where the request came from.
bulk: this one is hard to determine if you only get one. But the way I do define it is whether or not the person who initiated the sending of the email (not the one requesting it) used a mailing list rather than typing each address in manually.
I do agree that any bill that allows spammers to say "this isn't spam" or "this is legal" is a serious mistake. But we also do need to get it as right as possible the first time. Going back and amending a law is actually very rarely done because you end up with too many people saying "it's not a big problem anymore" and "let this law have 10 years to work itself out". Lawmakers are worse than programmers at fixing bugs.
If just 2 clicks is all it would take, then I would be happy. The fact is, it takes far more than just 2 clicks, because after I've deleted your spam, then there's spam from someone else and I have to delete that. Then more and more. I'll just continue to use the solution I use now, which is blocking 200 to 700 spams a day (and thus saving me as much as 1400 clicks). And yes, that does end up blocking some mail from non-spammers who are paying money to ISPs that refuse to remove spammers from their network. But that's justified because despite being blocked, they continue to abuse my mail server and waste my bandwidth.
So until there is a really workable solution, I'll just keep blocking bad ISPs.
Maybe your problem is that you're not getting as much spam as some other people. And maybe your mail server isn't being abused with spam addressed to hundreds of email addresses for users that don't even exist and never have. Someday your parents will let you out of your room and you can see what the real world is like.
Obviously you didn't get the sarcasm. Are you that autistic? Oh wait, I can't say that, I would be offending those with autism.
The point is that Sun's actions might well suggest it is coming from a company that does not already have an excellent 64-bit CPU in its hardware product lineup. And if they really wanted you to buy their hardware, why would they be promoting Linux only on other hardware besides their own? Of course I know they have a 64-bit CPU. I've used it. But it sure seems like some on Sun upper level management have forgotten about it.
Next time, try reading the post more carefully and understand what it meant, even if the sarcasm was subtle, because that is the nature of things on Slashdot. I see your ID number is fairly low compared to where things are at now on Slashdot, so it should mean you are fairly experienced with the subtlety and sarcasm here used to make a point. So try and show it, will ya.
Slashdot Mirror
Get source code. Hack away. Make it set the TTL to 128 when it's in the NAT part of the code. Bingo, problem solved.
This will be easy to fix. A hack to your NAT box source code (you are doing NAT with OpenBSD, Linux or some other open source system, right?) to remove the TTL decrement for NAT traffic (or re-increment it where the decrement can't tell the difference) would get around that aspect of the problem. I'd argue that one can NAT in a transparent "switch", which would not decrement TTL, so why not just make the OpenBSD or Linux box do that.
And for fun, add a randomizer to the initial TTL value. Thus instead of it starting at say 128, it could be a randomly chosen value between 100 and 140 (just to pick some arbitrary numbers).
... it doesn't automatically remove packets with the evil bit turned on.
Read it with Baghdad Bob's accent in mind.
If the spammer runs a normal MTA, the 550 codes are likely to result in a bounce, but it probably goes to a mailbox that discards it in some way. I'm sure they can't be bothered with cleaning up their lists.
If they are running spamware, those nasty programs that make a thousand concurrent connections and sends the same message to everyone in the list, it certainly can see that 550 code, but probably does nothing about it. They must justify that to themselves as "the address might still be good, but the server blocked me, so I'll just leave the address in for later when they stop blocking". In many cases the list is on CD, so it wouldn't be able to delete it and keeping a no-send list is probably more costly (to keep checking it in the future) than to just try addresses that can't be sent to.
I've seen lots of spam, usually from big spammer operations, which have return addresses that encode the victim address. So clearly they have some means to potentially process it. But they might also be doing that only to track complaints. And if they are doing that from spamware, it might not deal with the fact that it happens during delivery, and just handle it only when a bounce comes back.
I've already written my own protocol to replace SMTP. I set up three servers to send mail to each other. They've been busy at it all weekend testing it out. It looks like a great success. There's been no spam at all :-)
You'll never educate enough people to stop buying via spam for that to really ever slow it down. Besides, those who actually want to buy things from people they don't know, who sent them a deal they never asked for, is their right.
The problem is, for spammers to reach the 0.1% out there who might buy something from them, they end up pounding on our mail servers, and flooding our mail boxes. I do know that if spammers would pay attention to those "550" response codes they get on SMTP connections, and delete the address from their list as "undeliverable", 99% of the delivery attempts on my mail servers would cease. And that's where a substantial amount of the cost of spam comes from.
I paused at that statement. My first thought was where would they even find a copy of an immature Linux OS. But alas, not all is lost. It seems our friends over at ibiblio.org have archived a number of different versions of immature Linux, ready for download. Check it out:
There are others here.
You are suggesting a mail message rate quota. That's actually a good idea, if the ISP will do it. Few do. The question is what to do with an ISP that then refuses to play along. As you point out, they can be blocked. I do that already as do thousands of others. Then we face all the whiners citing unfairness, collateral damage, can't change ISP, etc.
The value of an open relay is almost nothing. The only thing I see it for is that very occaisional necessary anonymous email. Travelers no longer need it because all the major mail clients and server now can support authenticated SMTP. So just get an ISP that has a mail server with such support and use such a client, and you can email from anywhere. Be sure your ISP offers it on a port other than 25 because many ISPs don't let generic addresses (e.g. dialups and such) to access port 25 outside of their own network.
I'm not saying we need a law change. But I am saying we do end up having a law change, we should do it right. The risk of letting politicians do it without our "guidance" is foolhardy. The suggestions you make are good, and are already being done by many (at least the part about blocking ISPs that let spam leak out), and need to be done by more.
One of those ISPs that is not cutting off spammers is Rackspace. And their upstream backbone providers are not cutting them off, either. I'd love to see those bastards shut down and their officers put in prison.
The throttling should be done as close to the source as possible. The law should be applied only there. If an ISP is outside the jurisdiction of that law, then it should be applied at the nearest point crossing the jurisdictional border (e.g the connection going out of the country).
And the law should only require the necessary minimum stoppage. For example if the problem is a high speed packet attack from one source to one victim network, then it is acceptable for the victim's address to be used to filter packets at the connection, where practical to do so (maybe only if one or two victim networks in the case high bandwidth trunks, if that). But that's just a direct attack scenario, not a spam situation. For spam, the victims are generally everyone, so cutting off the sender regardless of the destination, or the whole trunk, may be necessary.
We need to treat spam like a DDoS problem, where the victims are simply wide spread rather than focused on a few. What if several hundred thousand connected computers were making as many connection attempts as they could to random addresses and port 80? That could be a lot of traffic. And we've seen that before.
And what if that ISP that takes the money doesn't do anything about the spam source? If the action to be taken is an action of law, then I certainly would agree that the action should be done against this ISP and not the backbone. But what if this bad ISP taking money from a spammer is outside the jurisdiction of the law? I would in this case consider it acceptable for the backbone ISP to be required to disconnect the bad ISP. Now what if this connection is actually a huge trunk going to another country, say for example the connection between a Caribbean Islands nation and the United States?
When it's a matter of law, I would say it can be done to control abuses (and not just spam ... include other things like DDoS attacks, etc), but must be done in a minimum way to manage and control the abuse. For example if that other nation out of reach of the law is only attacking one single network somewhere in the US, and the owner of that network wants to invoke the cut-off provisions, then it would be acceptable for the "cut off" to be in the form of a filter that prevents packets coming via that trunk only, addressed to that network, to be blocked. Of course if the ISP operating that connection decides it would rather take down the whole thing that deal with all the filters that would have to be added, that should be their option. The point is, if some network is being attacked, it should be the responsibility of the ISP (backbone or otherwise) closest to the source of the attack (where identifiable), within the jurisdiction of the applicable law where those outside fail to voluntarily do that action to clear up the attack, then the action must be taken to block that attack, and the law can only require the minimum amount of action necessary to block it.
One aspect of the spam problem is not unlike a DDoS. Imagine what the cost would be to service 1 billion SMTP connection attempts every day. That's 360 gigabytes of traffic every day (60 byte packet, 6 SYNs sent if no connection is established), or 33.333333 megabits every second (assuming it is evenly distributed in time). And that's just the bandwidth cost assuming spam is filtered at the router near the server (e.g. the SYNs never reach the server). Servicing 1 billion SMTP connections at the server involves all the bandwidth to carry out as much of the SMTP connection as the server allows before cutting it off, which can be substantially higher if the server allows the DATA portion to be transmitted. At 1 billion a day, that's 11,574 per second. That's a LOT of added servers just to deal with and refuse spam. And again, that assumes an even distribution in time.
One cracker who "owns" thousands of machines that can be used to attack some network with a DDoS attack can certainly cause a huge problem. But the aggregate of spam is just as much of a problem for large companies like AOL. We shouldn't treat it as any less of a problem because it's not one single individual causing it. We can't ignore the problem just because the perpetrators are many, or because they and their ISP might be out of reach of the jurisdiction of the victim.
If all the various classes of objects that have a rotate method need to send a message to the update display method, why can't the inheritance mechanism provide for that by having an inherited rotate method that, instead of being replaced by a rotate method included in the inheriting class, just invoke them both? What would be needed is a special primitive to be used in the superior rotate method that indicates where the inferior rotate method is applied. Suppose that mechanism is an "inferior" statement. The superior rotate method might be as small as having code to first do "inferior" followed by "update display" and that's all. This would be more mechanical than AOP promises, but at least it would avoid having the display updated before the rotation.
I was originally going to propose this for 126/8, but this netblock seems more appropriate. ARIN should take 69/8 back and re-assign it specifically for the purpose of spammers and their hosting services. Make it illegal (like maybe a death penalty) for doing any spamming or hosting any spammers unless it's done from this block of address space.
This is a good example of what can be done when you choose (or switch to, as the case may be), a good and competent ISP.
The problem is Comcast is incompetent. Their so called *business account* static IP is still labeled as a dynamic one through their reverse DNS. That's how I block them (by reverse DNS name), and that's probably how AOL does, too. If Comcast can't fix it and make it look exactly like a real business account, then they are providing you with less than they claim, and this is fraud. Sue them or just switch. Or get dialup for the outbound mail and keep surfing via cable.
1. Don't run an open relay.
2. Don't use Verizon, if they still do this.
3. Use GPG to keep your mail from being read. If you really need to hide who it is you send mail to, use a secure tunnel (you don't need to talk to anyone who is not capable of doing that).
Speakeasy will do reverse DNS. I've come across more than one person who has had it done. Also ask them, if they submit dynamic IP lists, to be sure than your static IP is not included on that list.
Then get a dedicated/static IP address and have reverse DNS properly configured on it. That's easy to do, so don't take any bullshit from your provider if they say they can't do it or don't understand what you are talking about. If they can't do that right and still advertise as an internet service, sue them for fraud. Or just work harder at switching ISP. Ever heard of colocating? Of course if you want it cheap, you get what you pay for.
Many networks have different addresses for hosts that send mail and hosts that receive mail. Requiring that the sender have an MX listing, and hence be a receiver, too, is stupid. Of course the sender could just not listen to port 25, but that still ends up with a system where mail going the other way doesn't work right. You need a different means to authenticate the sending MTA. Secure certificates would be workable over the existing SMTP with STARTTLS added. And it would be possible to gradually deploy that.
As for spammers buying domains ... I know of at least one spammer that does that every day. Yes, a new domain name ever day. Spammers do make tons of money from all the gullible business types out there that are looking to expand their marketing and don't know the issues involved in email. Buying a domain a day is a drop in the bucket for a bigtime spammer.
In a way I agree with what you say. The last thing company executives need is some middle manager putting a spin on things, and distorting the message. But there need to be some limits, too. The thing is, having the CEO or CFO come wasting your time is not an issue I've encountered. The few times I've dealt with that level of management, they were good time management people and got to the point and didn't waste my time, either.
But the time of techies can be wasted, depending on what the job responsibility is. If your job is not to support all the desktop users in the company, then you do need a gatekeeper so you aren't dealing with the trivial problems and the endless stupid questions. That's what first level support is for. And that's not your manager's job, either.
Of course, if your job is first level support, then all the BS comes with the territory ... live with it. But if you're a developer or network engineer or whatever, the important thing is to make sure your time is properly managed and the priorities are properly ordered. Either you do that or your manager does. Just be clear between you who does what.
This is one of the reasons I prefer to block spam on the basis of who (sender) or what (server, network, ISP's network) sent it. I never even see the content, so it's not about what the message is. It's about abuse of my time, my server's resources, and my network's bandwidth, for some activity that I did not give permission for the use of my property for. And yes, I do significantly whitelist. I have 4 Asian countries and 2 South American countries fully blacklisted (the whitelisting then lets specific people therein to send to me). I have several US and European ISPs fully blacklisted (and again, the whitelisting makes exceptions). It is possible that in time I might end up having to blacklist the entire network and then depend on whitelisting each individual.
It's not the fact that email is unsolicited that bothers me. It's the fact that unsolicited is combined with bulk (e.g. impersonal because the sender used a list rather than personally being aware of each recipient they are sending to by having typed it in manually for each message) that bothers me. That and I get hundreds a day.
It will not reduce the total volume of spam. Instead, it will actually increase it because it will be used by spammers as justification to fight the ISPs that try to disconnect them. Those ISPs, fearing being sued, will then let the spammers continue abusing everyone else's mail servers (those who don't have mail servers of their own will end up paying more to cover the increased costs of their own ISP having to upgrade the server capacity to deal with all the postage-due spam).
Right now, one major problem is that many ISPs are refusing to terminate spammers. That needs to be changed. The ISPs that let spammers abuse networks should be equally liable for the costs if they refuse to terminate the spammer immediately.
Defining spam is, of course, a major difficulty. The way I define it is when both of the following are met:
I do agree that any bill that allows spammers to say "this isn't spam" or "this is legal" is a serious mistake. But we also do need to get it as right as possible the first time. Going back and amending a law is actually very rarely done because you end up with too many people saying "it's not a big problem anymore" and "let this law have 10 years to work itself out". Lawmakers are worse than programmers at fixing bugs.
If just 2 clicks is all it would take, then I would be happy. The fact is, it takes far more than just 2 clicks, because after I've deleted your spam, then there's spam from someone else and I have to delete that. Then more and more. I'll just continue to use the solution I use now, which is blocking 200 to 700 spams a day (and thus saving me as much as 1400 clicks). And yes, that does end up blocking some mail from non-spammers who are paying money to ISPs that refuse to remove spammers from their network. But that's justified because despite being blocked, they continue to abuse my mail server and waste my bandwidth.
So until there is a really workable solution, I'll just keep blocking bad ISPs.
Maybe your problem is that you're not getting as much spam as some other people. And maybe your mail server isn't being abused with spam addressed to hundreds of email addresses for users that don't even exist and never have. Someday your parents will let you out of your room and you can see what the real world is like.
Obviously you didn't get the sarcasm. Are you that autistic? Oh wait, I can't say that, I would be offending those with autism.
The point is that Sun's actions might well suggest it is coming from a company that does not already have an excellent 64-bit CPU in its hardware product lineup. And if they really wanted you to buy their hardware, why would they be promoting Linux only on other hardware besides their own? Of course I know they have a 64-bit CPU. I've used it. But it sure seems like some on Sun upper level management have forgotten about it.
Next time, try reading the post more carefully and understand what it meant, even if the sarcasm was subtle, because that is the nature of things on Slashdot. I see your ID number is fairly low compared to where things are at now on Slashdot, so it should mean you are fairly experienced with the subtlety and sarcasm here used to make a point. So try and show it, will ya.