It is easy to see who is collecting the money. It is hard to see who is sending the spam. Under a system where one could get fined for benefiting from spam, there would be an incentive for the competition to hire spammers to get a company fined. This possibility should be kept in mind, so that any prosecution must demonstrate that some of the money eventually goes to spammers.
Still, there should be some enabling legislation allowing lawsuits against companies selling this stuff. Mainly to allow discovery to follow the money to whomever is sending the spam. If we could dry up the market of people paying for spam, the spammers would disappear.
You can configure tmda.net the way that you want. There are several others that offer the service itself rather than the software.
Note: you can also set it up to allow email from people who respond to a challenge. Then at least you know that a real person had to take the time to send you that email.
I get about a hundred spams a day. If I did not use filtering, I would probably have to spend around an hour going through them. Why should I have to give up an hour of my day just to use email? This was supposed to be the easy communication method. Why do I have to face the possibility of a false positive causing me to miss legitimate email?
Also, what about the damage to me when someone who would have liked to receive my email accidentally deletes it because he doesn't recognize my new email address? I have actually already lost a contracting job because of this. The delete key is not always a positive.
Further, what about the fact that 2/3 of all traffic is spam. Why do I have to pay my ISP to provide services to deliver email to me that I don't want? How is the delete key going to get back my money?
A global opt-out list with one way encryption is still susceptible to dictionary attacks. No longer will spammers have to dictionary attack ISPs one by one (fixable by silently dropping email with no valid recipient now), they will be able to do so all at once.
A global opt-in list is different. It would be a mapping of email address to allowed email address pattern (presumably a domain). If your domain is on the list, bulk emails that include that email address will go through. Otherwise, they don't. Note: unfortunately, legitimate list servers would have to use this as well. At least now their lists will be able to get through if someone really opted in.
You mention that Linford "has an excellent countersuit." I would agree, but I am unsure if you are claiming that he has already filed one or that he could file one.
I think that not only the defendants of the case should countersue but that those who use the SBL and those who are protected by the SBL should join the suit (as a class action) against the negative effects that could be caused by hindering Spamhaus's work. I also think that anyone who owns part of this corporation should be named as a defendant in the suit. Clearly the corporation is an attempt to hide the actual principals and protect the from liability. I'm not sure of the legal basis, but I think that that protection should be voided by their active participation.
Hopefully the discovery phase will dig up some of their actual illegal behavior (forging headers, hacking boxes to send email from them), so that the courts can prosecute them. It would be great if it could be proved that some of the product distributors who benefit from this advertising could be shown to have actively participated as well. Cut off the funding for spam.
Seriously, if some lawyer wanted to take this task on, I (and many others, I'm sure) would be happy to help with the preparation of requests for useful data and interpretation of the data once it is received. Just post a response here and I will be happy to post one of my spamcatcher accounts. Just give me an idea of what the email will look like so that I don't accidentally delete it with my spam...
How do I tell the difference between spam and commericial email? To do so, I have to give them information showing that my email is active. I refuse to trust someone who has not given me any reason to trust them. I look forward to the development of a real system: for example, an actual trusted source which maintains an opt-in list for email. Then I might be willing to acknowledge the potential existence of non-spam commercial email.
In regards to your last point, who are the members behind the lawsuit? I think the fact that they are anonymous says it all about whether or not they are legitimate business people.
Also, I think that if RTFC (read the complaint) that it is pretty obvious that it is issued by someone who really does not know enough to be involved in a legitimate emailing business. Further, parts of it are clearly fraudulent and libelous. If these people had any real legal leg on which to stand, they would not have to make stuff up to file the lawsuit.
I hope that the lawyer who filed the lawsuit is disbarred for abuse of his position as an officer of the court. I hope that he and his buddies are sued for libel, harassment, and other damages to the point that when they get out of jail from their perjury charges that they will be penniless.
The sheer chutzpah of this lawsuit deserves an unequivocal response.
Start by disbarring the lawyer for abuse of his position as an officer of the court. Follow with criminal case for perjury. Top off with civil suits for libel and harassment.
It is pretty clear that some of the information in the lawsuit is made up. Completely, from whole cloth. For example, the claim that Spamhous's DNS registration information is incorrect seems to be an utter falsehood. The claim that the defendants converted IP addresses and servers to their own use is ridiculous.
Some Florida lawyer could make a lot of money by going after this guy with a class action suit where all of us who receive spam claim damages from his harassing our legitimate efforts to stop spam. Not to mention what Spamhaus should be able to collect for defending itself against this frivolous lawsuit.
I am also very curious what ramifications can be made from the fact that the group behind this apparently chose to incorporate entirely to issue this lawsuit. If so, it would seem to me that their corporate registration is fraudulent. If so, they should be prosecuted for that. Further, they should also lose the normal liability protection of the corporation and be eligible to be listed as co-defendants in the civil suits mentioned above. IMO. IANAL.
Yes, but his response does not make that clear. It should say something along the lines of:
Neither Spamhaus nor any of the Defendants named had ever heard of EMarketersAmerica prior to this SLAPP suit being filed. Thus, we could not have intended harm against the Plaintiff EMarketersAmerica. Further, we have seen no proof that the plaintiff has suffered any harm.
I suspect that EMarketersAmerica was hoping that no one would respond in the court so that they would win by default. Then, using that court decision, they could go after ISPs that use the SBL.
There is no need for certificates. Just use DNS. Make a new DNS record that holds the address of an email server that is valid to send email for that domain. Refuse email sent from IPs that do not have authorization in DNS. Then, if a domain sends spam, you can block it (currently, there is no point, since the domain may not be owned by the spammer) as well as the sending IP. If this is done quickly enough, the spammer will not be able to send enough email to cover domain registration costs.
I finally managed to get Acrobat to run (it hid a dialog box, so it was hanging and I couldn't see why). In the overview section of http://www.whitehouse.gov/omb/budget/fy2004/pdf/hi st.pdf, I found that the surpluses (+) and deficits (-) were as follows (in billions of US$):
In general, most states are required to balance their budget each year. That's the problem here. California projects that with the budget they would have a deficit. However, they can't actually run a deficit, so they either need to increase revenue or cut spending. When the recession started, they were probably running a surplus.
The federal deficit has gone from about $60B in 2000 to over $300B now (not sure how much over). You can probably find more info at http://www.omb.gov under one of the budget links.
California merchants already had to collect sales tax. What this law says is that any company that does any business in the state of California must collect sales tax, even if they don't sell in California.
And it does affect the rest of us when *our* states start passing similar laws. Btw, it's worth noting that you are probably already required to pay (use) tax on products bought outside your state (not the merchant, *you*; the merchant never pays sales tax; they just collect it from the consumer for the government). That's the law in most states with a sales tax.
What this mainly means is that states are going to push their abilities to the limit. California today; any number of other states tomorrow.
They don't necessarily make money from the business income. Most of the business income tax will be paid in the state in which they are headquartered, not the state of the sale. That's why they are so aggressive about this now. Half the parties who must pay this are from other states (i.e. can't vote against them).
Don't tax you; don't tax me; Tax that other guy behind the tree.
Btw, if we want to reduce multiple taxation in the US, why don't we replace sales and business income taxes with a VAT (value added tax, which taxes the difference between revenues and costs per item)? It accomplishes the goals of both taxes more smoothly and is harder to evade.
I don't think that FUD is the right phrase, maybe scare tactics instead. Someone could use that kind of attack to do those things. However, as you note, they could also do the same thing with email (replace contaminated letter with virus). That's the whole point. I've already faced the problem of someone accidentally deleting an email from me because they thought it was spam (didn't recognize the account from which I sent it after I changed accounts).
Spam does me real damage five ways: I pay added costs to support delivery of the spam to me (not a cost of postal junk mail, which is sender paid; in fact, postal junk mail actually helps keep my postage down due to economies of scale); my time recognizing and deleting spam; the opportunity cost of missing a legitimate email because it looks like spam; the opportunity cost of my email not being read because someone thinks it's spam; the opportunity cost of not being able to post an email address on the web for fear of spam. Not to mention the fact that spam drowns out the possibility of legitimate use of email for lists and marketing purposes (opt-in lists, etc.).
There are a couple posts on how this could be accomplished at the command line as well. One person noted that there is already a kernel patch to allow what seems to be a directory to the user can still be the contents of multiple directories in the underlying file system.
A real database file system would also support this.
They do filter postal junk mail--if you ask
on
How to Become A Spammer
·
· Score: 4, Interesting
If you ask the Post Office to filter out the junk mail, they will. This is not 100% effective, but about 90% of postal junk mail is added on a per address basis by the post office. They can and will stop delivering that if requested.
Also, back when I only got a few spams a week, I used to read them. I never bought anything from them, but I would look at ones I found interesting. The problem is that we have gone from five to ten spams a week to hundreds. My yahoo account (which I mainly use for site registrations) collects hundreds of emails each week in its bulk (spam) folder.
There are several costs to me of that volume. One, I have to spend a certain amount of time checking for legitimate email. Two, what if I incorrectly classify a real email as spam. Three, I don't feel comfortable publishing my email address now, since I don't want to get more spam. In the normal course of business, I would want to publish my email (how much time is spent on taking anti-spam kludges out of email; how much server time is spent trying to send email to these invalid addresses). Four, since spam is sent indiscriminately, it drowns out legitimate uses; if it is a product in which I would be interested, I would like to learn about it. Unfortunately, very little spam is targeted towards my interests (science fiction, fantasy, etc.). Five, when I send email, I am subject to it being indiscriminately deleted because I am not a recognized sender.
Two thirds of the email traffic overall is spam. Without it (and the computationally intense filtering created by it), we could easily cut the infrastructure in half. Think about it. Half the email servers in use could become web servers, etc. instead.
By contrast, postal junk mail does not increase your delivery costs. In fact, postal junk mail fees pay a good portion of the cost of maintaining mail delivery to people. If postal junk mail stopped tomorrow, the post office would have to raise postage to cover the fact that they would then be running the same delivery routes with less mail. Even if there are disposal costs, these are offset by the savings in postage.
There are very few anti-spam laws in the US. The few that do exist are state laws rather than federal laws. Most anti-spam prosecutions are based on fraud and damage claims. Further, in the US, it is not really possible to shut down a group talking about doing something. It's not illegal to discuss how the law could be broken.
Hmm...I point out problems with *COMPATIBILITY* across distros, and you respond saying that I could roll my own. A true statement but irrelevant. I don't want to roll my own--I want to use distros that are standards compliant; particularly since I move between distros frequently.
It's not about keeping things from being easy. It's about making things easy by providing a common interface. The whole point of my post was that you can still make things easy *WITHOUT* taking away what is there now. Build on the current system rather than throw it out. Note that GoboLinux still has to include symlinks to simulate the standard file system. My point is simply that that is backwards. It would make far more sense to change how the file system is viewed rather than try to change the fundamental structure.
It is true that open source software means that I could rewrite the source code for any package so that it would work on the system that I am using. However, I don't want to waste my time rewriting source code. Also, have you considered the impact of having all the techies/geeks on a separate platform from the one that most users use? Yes, it would mean that all the open source software would get written for a different platform than the one that most people use. Who would have to recompile then? Yes, it's the very people for whom you were trying to make it easier before this. Now you have them rewriting source code. That's EASIER?!?
There is no reason to make the underlying directory structure match the one that is displayed in the GUI interface. Since most users will only use the GUI, they will only see the simple version.
Have you ever looked at the underlying file system for MS Windows? It's a mess. First, the GUI names for things do not match the command line names (Program Files becomes progra~1; My Documents becomes mydocu~1; etc.). Second, program files and libraries can be scattered all over the place (libraries might be in that app's directory, a related apps directory, the Windows\system directory, etc.). Third, configuration information is stored in a bizarre format in one big file (the Registry). Yet, MS Windows is widely regarded as being simple. Why? Because the average user will never care about that stuff so long as they don't have to interact with it directly. Most people install the app to the default location (\Program Files\apporvendorname\...); save to the default location (My Documents); and only use the configuration tools provided by the app (which then manipulate the registry as necessary). They never see how complicated the underlying file structure is.
There are a large number of reasons to keep as many things as possible the same across distros. The biggest is app availability. No one in their right mind will try to write software that will be portable across distros if they can just write for one. That's why initiatives like Linux Standard Base, File Hierarchy Standard, and United Linux exist, to create standards which people can use to develop. GoboLinux recognizes this, which is why they include legacy symlinks.
I posted three reasons why that was a bad idea, and you only responded to one. It's not a geek/techie thing (note that by definition, people who create their own distro are techies; however, the Gobo techies prefer the 'simple' interface). Most techies use their boxes as the only user; thus, file permissions aren't very important (unless the box gets partially hacked). The big difference will come when someone hooks their computer to a LAN at home or at work and needs to work with others. Now, all of a sudden all those file permission security features become important. Not just to keep your box from getting cracked, but to keep others from *accidentally* hosing your box.
Under your system, you now have two entirely different file system structures: one for someone who only wants the basics; one for someone who wants network file sharing.
Under my system, desktop users would still get a simple interface. In fact, they could see the GoboLinux directory structure in their GUI file manager. However, if they had to call a techie in to change something fundamental about their box (or maybe just to troubleshoot a problem), there is still the same file system hierarchy used everywhere else.
Doing things this way is strictly better, since you can port applications written to run on a server platform to a workstation or desktop platform (or vice versa) without having to rewrite the file system interface.
I think that this operates rather backwardly. Instead of making/bin a symlink to some new directory, it would make more sense to make a conglomerate directory that includes the contents of/bin,/usr/bin, etc. One can do this comparatively easily in a GUI environment (or in a database filesystem--it's just a matter of query structure).
There are several problems with symlinking all */bin directories to another directory. First, some of these directories are put in different places for good reason--/usr/bin for system apps,/usr/local/bin for locally installed versions that may clash with system apps, ~/bin for user apps. The/opt structure exists to separate out packages so that they don't conflict with other apps (like GamBas and Gaby do by default). If you put them all in the same directory, you are stuck with name clash again. Further,/bin,/sbin, and ~/bin usually have different file permissions. For most desktop users, this is unnecessary, but do we really want a different underlying file system structure for desktop distros than for server distros?
I would rather that all versions of Linux retain the same underlying file structure. Any changes that need to be made to make it easier for people to understand are better made at the view level rather than the functional level.
That said, I do think that it is good that people are starting to think about how to make file systems more understandable for newbies. I just don't want to throw out the baby with the bathwater.
Keep the good; replace the bad; add enhancements. That's improvement.
The biggest reason why SMTP servers don't make users login is that it wouldn't matter. So long as *any* computer on the internet is authorized to send email as me, it doesn't matter if the one server that I actually use requires a login (particularly since most spam does not originate with a legitimate mail server; instead, it is sent by spam software using open relays and proxies).
In order to make this work, we also have to come up with a way of verifying the server (blacklists aren't enough; open relays and proxies get blacklisted now; spammers just switch machines). What I would suggest is adding a new type of record in DNS (call it an SMTP record for now). This record would verify that a particular IP is allowed to send email for the domain of the sender. This would eliminate the effectiveness of open relays and proxies. To get mail through, spammers would have to reveal their identity.
Note that this system still does not require any special certificates, just enhancements to what already exists.
I would also recommend running wire wherever you can and using wireless for mobile devices (laptops, PDAs, etc.). However, I disagree with the idea of putting a Wireless card in the desktop.
I would suggest that you go with a wireless broadband router instead. Most of those that I've seen also include regular wired ports. Plug your wired system into those and use the wireless for mobile devices. That way, you don't need to have your desktop on to use your laptop's connection. Also, it saves all the peer to peer manual connection setup.
I would also recommend using encryption for privacy reasons but YMMV.
You can buy support for MySQL. It will still be cheaper than going with the Oracle solution, and now your boss will be happy because she can use her business degree and put together a spreadsheet.
Also, the parent of this post should go back and look at the post to which it responds. It is the boss who is insisting on TCO (which is not 0 for OSS, although one facet of it can be: cost of software). The best way to handle this is to give her what she (and presumably her bosses) wants. Go to www.mysql.com and have them price out a support contract (and ask them if they have TCO numbers, which they should). Point out that with MySQL you now have two support options: call the vendor or debug it yourself. With proprietary software, you can easily get in a situation where only the vendor can see enough to do proper debugging. Thus, proprietary software has *less* support.
Red Hat's primary business is support, unlike MS which regards its primary business as writing code. The biggest difference between commercial open source support and proprietary support is that there is *more* support for open source software. Why? Because open source code is supportable by more than just the original vendor. You want support? You can hire the original coder or a third party. You can choose to debug the code yourself, add features, or change features. You have options.
What options do you have with proprietary software? Well, you can guess at what's causing the problem and change configurations. If the problem is an actual crash or something, you can reboot, reinstall the offending program, reinstall the OS. If none of that works, you can call the vendor (who will start by having you follow those three steps, along with applying patches, blame the hardware, etc.). The vendor may or may not be able to help you. Further, it is entirely up to them whether they give you real support or not (for example, if behavior is considered to be a feature, you cannot make a software vendor change the behavior). If they choose not, then there is no recourse for you (other than switching software).
A university where I worked considered switching to one of those MS license all your software from us and we'll give you a really great deal. As part of that, they considered moving the yellow page servers to the MS product. The deal was sold, they were ready to start. They asked MS to make a tool that would convert a flat text file generated from the information stored in the previous software's format into the MS format and MS refused. They had a nice point and click interface, and they expected the university to manually retype 60 *thousand* accounts with it. An overnight batch job would have become a multi-month project. Yellow pages info now resides on OpenVMS boxes with a custom written interface that took a couple of weeks to design.
Not accepting mail that purports to be from your own address prevents mail forwarding loops.
If you are using IMAP or web mail, you can set it up to save email that you send to yourself. The blacklist will keep you from receiving the email, but you will still have the copy in the sent folder. Alternately, you can send to a variant of your email address that does not require the challenge/response (the same kind of thing you do with automated mailers like Amazon's).
Unless they default to not allowing email from your own email address, which is sensible behavior anyway.
Btw, for anyone who thinks they have a way to beat the challenge/response system, check out tmda.net (http://tmda.net/faq.cgi). Every potential workaround that someone has suggested is discussed there.
I still think that best way to address the spam problem globally (C/R is an individual response) would be to add a new type of record to DNS that holds authorized mail senders for a domain. Under the current system, any mail server (even one included with a virus that is running on a personal computer) can send email with *any* From: email address. Under this system, only a limited number of email servers could send email for a particular address. Those servers can also demand authentication to send email (already supported in SMTP).
This would eliminate the current problems with open proxies and relays. People could still spam, but they would have to use their own identity to do so. All of a sudden, blacklists are effective again.
Slashdot Mirror
It is easy to see who is collecting the money. It is hard to see who is sending the spam. Under a system where one could get fined for benefiting from spam, there would be an incentive for the competition to hire spammers to get a company fined. This possibility should be kept in mind, so that any prosecution must demonstrate that some of the money eventually goes to spammers.
Still, there should be some enabling legislation allowing lawsuits against companies selling this stuff. Mainly to allow discovery to follow the money to whomever is sending the spam. If we could dry up the market of people paying for spam, the spammers would disappear.
You can configure tmda.net the way that you want. There are several others that offer the service itself rather than the software.
Note: you can also set it up to allow email from people who respond to a challenge. Then at least you know that a real person had to take the time to send you that email.
I get about a hundred spams a day. If I did not use filtering, I would probably have to spend around an hour going through them. Why should I have to give up an hour of my day just to use email? This was supposed to be the easy communication method. Why do I have to face the possibility of a false positive causing me to miss legitimate email?
Also, what about the damage to me when someone who would have liked to receive my email accidentally deletes it because he doesn't recognize my new email address? I have actually already lost a contracting job because of this. The delete key is not always a positive.
Further, what about the fact that 2/3 of all traffic is spam. Why do I have to pay my ISP to provide services to deliver email to me that I don't want? How is the delete key going to get back my money?
A global opt-out list with one way encryption is still susceptible to dictionary attacks. No longer will spammers have to dictionary attack ISPs one by one (fixable by silently dropping email with no valid recipient now), they will be able to do so all at once.
A global opt-in list is different. It would be a mapping of email address to allowed email address pattern (presumably a domain). If your domain is on the list, bulk emails that include that email address will go through. Otherwise, they don't. Note: unfortunately, legitimate list servers would have to use this as well. At least now their lists will be able to get through if someone really opted in.
You mention that Linford "has an excellent countersuit." I would agree, but I am unsure if you are claiming that he has already filed one or that he could file one.
I think that not only the defendants of the case should countersue but that those who use the SBL and those who are protected by the SBL should join the suit (as a class action) against the negative effects that could be caused by hindering Spamhaus's work. I also think that anyone who owns part of this corporation should be named as a defendant in the suit. Clearly the corporation is an attempt to hide the actual principals and protect the from liability. I'm not sure of the legal basis, but I think that that protection should be voided by their active participation.
Hopefully the discovery phase will dig up some of their actual illegal behavior (forging headers, hacking boxes to send email from them), so that the courts can prosecute them. It would be great if it could be proved that some of the product distributors who benefit from this advertising could be shown to have actively participated as well. Cut off the funding for spam.
Seriously, if some lawyer wanted to take this task on, I (and many others, I'm sure) would be happy to help with the preparation of requests for useful data and interpretation of the data once it is received. Just post a response here and I will be happy to post one of my spamcatcher accounts. Just give me an idea of what the email will look like so that I don't accidentally delete it with my spam...
How do I tell the difference between spam and commericial email? To do so, I have to give them information showing that my email is active. I refuse to trust someone who has not given me any reason to trust them. I look forward to the development of a real system: for example, an actual trusted source which maintains an opt-in list for email. Then I might be willing to acknowledge the potential existence of non-spam commercial email.
In regards to your last point, who are the members behind the lawsuit? I think the fact that they are anonymous says it all about whether or not they are legitimate business people.
Also, I think that if RTFC (read the complaint) that it is pretty obvious that it is issued by someone who really does not know enough to be involved in a legitimate emailing business. Further, parts of it are clearly fraudulent and libelous. If these people had any real legal leg on which to stand, they would not have to make stuff up to file the lawsuit.
I hope that the lawyer who filed the lawsuit is disbarred for abuse of his position as an officer of the court. I hope that he and his buddies are sued for libel, harassment, and other damages to the point that when they get out of jail from their perjury charges that they will be penniless.
The sheer chutzpah of this lawsuit deserves an unequivocal response.
Start by disbarring the lawyer for abuse of his position as an officer of the court. Follow with criminal case for perjury. Top off with civil suits for libel and harassment.
It is pretty clear that some of the information in the lawsuit is made up. Completely, from whole cloth. For example, the claim that Spamhous's DNS registration information is incorrect seems to be an utter falsehood. The claim that the defendants converted IP addresses and servers to their own use is ridiculous.
Some Florida lawyer could make a lot of money by going after this guy with a class action suit where all of us who receive spam claim damages from his harassing our legitimate efforts to stop spam. Not to mention what Spamhaus should be able to collect for defending itself against this frivolous lawsuit.
I am also very curious what ramifications can be made from the fact that the group behind this apparently chose to incorporate entirely to issue this lawsuit. If so, it would seem to me that their corporate registration is fraudulent. If so, they should be prosecuted for that. Further, they should also lose the normal liability protection of the corporation and be eligible to be listed as co-defendants in the civil suits mentioned above. IMO. IANAL.
Yes, but his response does not make that clear. It should say something along the lines of:
Neither Spamhaus nor any of the Defendants named had ever heard of EMarketersAmerica prior to this SLAPP suit being filed. Thus, we could not have intended harm against the Plaintiff EMarketersAmerica. Further, we have seen no proof that the plaintiff has suffered any harm.
I suspect that EMarketersAmerica was hoping that no one would respond in the court so that they would win by default. Then, using that court decision, they could go after ISPs that use the SBL.
There is no need for certificates. Just use DNS. Make a new DNS record that holds the address of an email server that is valid to send email for that domain. Refuse email sent from IPs that do not have authorization in DNS. Then, if a domain sends spam, you can block it (currently, there is no point, since the domain may not be owned by the spammer) as well as the sending IP. If this is done quickly enough, the spammer will not be able to send enough email to cover domain registration costs.
I finally managed to get Acrobat to run (it hid a dialog box, so it was hanging and I couldn't see why). In the overview section of http://www.whitehouse.gov/omb/budget/fy2004/pdf/hi st.pdf, I found that the surpluses (+) and deficits (-) were as follows (in billions of US$):
2000: +236
2001: +127
2002: -158
2003: -304 (estimated)
In general, most states are required to balance their budget each year. That's the problem here. California projects that with the budget they would have a deficit. However, they can't actually run a deficit, so they either need to increase revenue or cut spending. When the recession started, they were probably running a surplus.
The federal deficit has gone from about $60B in 2000 to over $300B now (not sure how much over). You can probably find more info at http://www.omb.gov under one of the budget links.
California merchants already had to collect sales tax. What this law says is that any company that does any business in the state of California must collect sales tax, even if they don't sell in California.
And it does affect the rest of us when *our* states start passing similar laws. Btw, it's worth noting that you are probably already required to pay (use) tax on products bought outside your state (not the merchant, *you*; the merchant never pays sales tax; they just collect it from the consumer for the government). That's the law in most states with a sales tax.
What this mainly means is that states are going to push their abilities to the limit. California today; any number of other states tomorrow.
They don't necessarily make money from the business income. Most of the business income tax will be paid in the state in which they are headquartered, not the state of the sale. That's why they are so aggressive about this now. Half the parties who must pay this are from other states (i.e. can't vote against them).
Don't tax you; don't tax me;
Tax that other guy behind the tree.
Btw, if we want to reduce multiple taxation in the US, why don't we replace sales and business income taxes with a VAT (value added tax, which taxes the difference between revenues and costs per item)? It accomplishes the goals of both taxes more smoothly and is harder to evade.
I don't think that FUD is the right phrase, maybe scare tactics instead. Someone could use that kind of attack to do those things. However, as you note, they could also do the same thing with email (replace contaminated letter with virus). That's the whole point. I've already faced the problem of someone accidentally deleting an email from me because they thought it was spam (didn't recognize the account from which I sent it after I changed accounts).
Spam does me real damage five ways: I pay added costs to support delivery of the spam to me (not a cost of postal junk mail, which is sender paid; in fact, postal junk mail actually helps keep my postage down due to economies of scale); my time recognizing and deleting spam; the opportunity cost of missing a legitimate email because it looks like spam; the opportunity cost of my email not being read because someone thinks it's spam; the opportunity cost of not being able to post an email address on the web for fear of spam. Not to mention the fact that spam drowns out the possibility of legitimate use of email for lists and marketing purposes (opt-in lists, etc.).
There are a couple posts on how this could be accomplished at the command line as well. One person noted that there is already a kernel patch to allow what seems to be a directory to the user can still be the contents of multiple directories in the underlying file system.
A real database file system would also support this.
If you ask the Post Office to filter out the junk mail, they will. This is not 100% effective, but about 90% of postal junk mail is added on a per address basis by the post office. They can and will stop delivering that if requested.
Also, back when I only got a few spams a week, I used to read them. I never bought anything from them, but I would look at ones I found interesting. The problem is that we have gone from five to ten spams a week to hundreds. My yahoo account (which I mainly use for site registrations) collects hundreds of emails each week in its bulk (spam) folder.
There are several costs to me of that volume. One, I have to spend a certain amount of time checking for legitimate email. Two, what if I incorrectly classify a real email as spam. Three, I don't feel comfortable publishing my email address now, since I don't want to get more spam. In the normal course of business, I would want to publish my email (how much time is spent on taking anti-spam kludges out of email; how much server time is spent trying to send email to these invalid addresses). Four, since spam is sent indiscriminately, it drowns out legitimate uses; if it is a product in which I would be interested, I would like to learn about it. Unfortunately, very little spam is targeted towards my interests (science fiction, fantasy, etc.). Five, when I send email, I am subject to it being indiscriminately deleted because I am not a recognized sender.
Two thirds of the email traffic overall is spam. Without it (and the computationally intense filtering created by it), we could easily cut the infrastructure in half. Think about it. Half the email servers in use could become web servers, etc. instead.
By contrast, postal junk mail does not increase your delivery costs. In fact, postal junk mail fees pay a good portion of the cost of maintaining mail delivery to people. If postal junk mail stopped tomorrow, the post office would have to raise postage to cover the fact that they would then be running the same delivery routes with less mail. Even if there are disposal costs, these are offset by the savings in postage.
There are very few anti-spam laws in the US. The few that do exist are state laws rather than federal laws. Most anti-spam prosecutions are based on fraud and damage claims. Further, in the US, it is not really possible to shut down a group talking about doing something. It's not illegal to discuss how the law could be broken.
Hmm...I point out problems with *COMPATIBILITY* across distros, and you respond saying that I could roll my own. A true statement but irrelevant. I don't want to roll my own--I want to use distros that are standards compliant; particularly since I move between distros frequently.
It's not about keeping things from being easy. It's about making things easy by providing a common interface. The whole point of my post was that you can still make things easy *WITHOUT* taking away what is there now. Build on the current system rather than throw it out. Note that GoboLinux still has to include symlinks to simulate the standard file system. My point is simply that that is backwards. It would make far more sense to change how the file system is viewed rather than try to change the fundamental structure.
It is true that open source software means that I could rewrite the source code for any package so that it would work on the system that I am using. However, I don't want to waste my time rewriting source code. Also, have you considered the impact of having all the techies/geeks on a separate platform from the one that most users use? Yes, it would mean that all the open source software would get written for a different platform than the one that most people use. Who would have to recompile then? Yes, it's the very people for whom you were trying to make it easier before this. Now you have them rewriting source code. That's EASIER?!?
There is no reason to make the underlying directory structure match the one that is displayed in the GUI interface. Since most users will only use the GUI, they will only see the simple version.
Have you ever looked at the underlying file system for MS Windows? It's a mess. First, the GUI names for things do not match the command line names (Program Files becomes progra~1; My Documents becomes mydocu~1; etc.). Second, program files and libraries can be scattered all over the place (libraries might be in that app's directory, a related apps directory, the Windows\system directory, etc.). Third, configuration information is stored in a bizarre format in one big file (the Registry). Yet, MS Windows is widely regarded as being simple. Why? Because the average user will never care about that stuff so long as they don't have to interact with it directly. Most people install the app to the default location (\Program Files\apporvendorname\...); save to the default location (My Documents); and only use the configuration tools provided by the app (which then manipulate the registry as necessary). They never see how complicated the underlying file structure is.
There are a large number of reasons to keep as many things as possible the same across distros. The biggest is app availability. No one in their right mind will try to write software that will be portable across distros if they can just write for one. That's why initiatives like Linux Standard Base, File Hierarchy Standard, and United Linux exist, to create standards which people can use to develop. GoboLinux recognizes this, which is why they include legacy symlinks.
I posted three reasons why that was a bad idea, and you only responded to one. It's not a geek/techie thing (note that by definition, people who create their own distro are techies; however, the Gobo techies prefer the 'simple' interface). Most techies use their boxes as the only user; thus, file permissions aren't very important (unless the box gets partially hacked). The big difference will come when someone hooks their computer to a LAN at home or at work and needs to work with others. Now, all of a sudden all those file permission security features become important. Not just to keep your box from getting cracked, but to keep others from *accidentally* hosing your box.
Under your system, you now have two entirely different file system structures: one for someone who only wants the basics; one for someone who wants network file sharing.
Under my system, desktop users would still get a simple interface. In fact, they could see the GoboLinux directory structure in their GUI file manager. However, if they had to call a techie in to change something fundamental about their box (or maybe just to troubleshoot a problem), there is still the same file system hierarchy used everywhere else.
Doing things this way is strictly better, since you can port applications written to run on a server platform to a workstation or desktop platform (or vice versa) without having to rewrite the file system interface.
I think that this operates rather backwardly. Instead of making /bin a symlink to some new directory, it would make more sense to make a conglomerate directory that includes the contents of /bin, /usr/bin, etc. One can do this comparatively easily in a GUI environment (or in a database filesystem--it's just a matter of query structure).
/usr/local/bin for locally installed versions that may clash with system apps, ~/bin for user apps. The /opt structure exists to separate out packages so that they don't conflict with other apps (like GamBas and Gaby do by default). If you put them all in the same directory, you are stuck with name clash again. Further, /bin, /sbin, and ~/bin usually have different file permissions. For most desktop users, this is unnecessary, but do we really want a different underlying file system structure for desktop distros than for server distros?
There are several problems with symlinking all */bin directories to another directory. First, some of these directories are put in different places for good reason--/usr/bin for system apps,
I would rather that all versions of Linux retain the same underlying file structure. Any changes that need to be made to make it easier for people to understand are better made at the view level rather than the functional level.
That said, I do think that it is good that people are starting to think about how to make file systems more understandable for newbies. I just don't want to throw out the baby with the bathwater.
Keep the good; replace the bad; add enhancements. That's improvement.
The biggest reason why SMTP servers don't make users login is that it wouldn't matter. So long as *any* computer on the internet is authorized to send email as me, it doesn't matter if the one server that I actually use requires a login (particularly since most spam does not originate with a legitimate mail server; instead, it is sent by spam software using open relays and proxies).
In order to make this work, we also have to come up with a way of verifying the server (blacklists aren't enough; open relays and proxies get blacklisted now; spammers just switch machines). What I would suggest is adding a new type of record in DNS (call it an SMTP record for now). This record would verify that a particular IP is allowed to send email for the domain of the sender. This would eliminate the effectiveness of open relays and proxies. To get mail through, spammers would have to reveal their identity.
Note that this system still does not require any special certificates, just enhancements to what already exists.
I would also recommend running wire wherever you can and using wireless for mobile devices (laptops, PDAs, etc.). However, I disagree with the idea of putting a Wireless card in the desktop.
I would suggest that you go with a wireless broadband router instead. Most of those that I've seen also include regular wired ports. Plug your wired system into those and use the wireless for mobile devices. That way, you don't need to have your desktop on to use your laptop's connection. Also, it saves all the peer to peer manual connection setup.
I would also recommend using encryption for privacy reasons but YMMV.
You can buy support for MySQL. It will still be cheaper than going with the Oracle solution, and now your boss will be happy because she can use her business degree and put together a spreadsheet.
Also, the parent of this post should go back and look at the post to which it responds. It is the boss who is insisting on TCO (which is not 0 for OSS, although one facet of it can be: cost of software). The best way to handle this is to give her what she (and presumably her bosses) wants. Go to www.mysql.com and have them price out a support contract (and ask them if they have TCO numbers, which they should). Point out that with MySQL you now have two support options: call the vendor or debug it yourself. With proprietary software, you can easily get in a situation where only the vendor can see enough to do proper debugging. Thus, proprietary software has *less* support.
Red Hat's primary business is support, unlike MS which regards its primary business as writing code. The biggest difference between commercial open source support and proprietary support is that there is *more* support for open source software. Why? Because open source code is supportable by more than just the original vendor. You want support? You can hire the original coder or a third party. You can choose to debug the code yourself, add features, or change features. You have options.
What options do you have with proprietary software? Well, you can guess at what's causing the problem and change configurations. If the problem is an actual crash or something, you can reboot, reinstall the offending program, reinstall the OS. If none of that works, you can call the vendor (who will start by having you follow those three steps, along with applying patches, blame the hardware, etc.). The vendor may or may not be able to help you. Further, it is entirely up to them whether they give you real support or not (for example, if behavior is considered to be a feature, you cannot make a software vendor change the behavior). If they choose not, then there is no recourse for you (other than switching software).
A university where I worked considered switching to one of those MS license all your software from us and we'll give you a really great deal. As part of that, they considered moving the yellow page servers to the MS product. The deal was sold, they were ready to start. They asked MS to make a tool that would convert a flat text file generated from the information stored in the previous software's format into the MS format and MS refused. They had a nice point and click interface, and they expected the university to manually retype 60 *thousand* accounts with it. An overnight batch job would have become a multi-month project. Yellow pages info now resides on OpenVMS boxes with a custom written interface that took a couple of weeks to design.
Not accepting mail that purports to be from your own address prevents mail forwarding loops.
If you are using IMAP or web mail, you can set it up to save email that you send to yourself. The blacklist will keep you from receiving the email, but you will still have the copy in the sent folder. Alternately, you can send to a variant of your email address that does not require the challenge/response (the same kind of thing you do with automated mailers like Amazon's).
Unless they default to not allowing email from your own email address, which is sensible behavior anyway.
Btw, for anyone who thinks they have a way to beat the challenge/response system, check out tmda.net (http://tmda.net/faq.cgi). Every potential workaround that someone has suggested is discussed there.
I still think that best way to address the spam problem globally (C/R is an individual response) would be to add a new type of record to DNS that holds authorized mail senders for a domain. Under the current system, any mail server (even one included with a virus that is running on a personal computer) can send email with *any* From: email address. Under this system, only a limited number of email servers could send email for a particular address. Those servers can also demand authentication to send email (already supported in SMTP).
This would eliminate the current problems with open proxies and relays. People could still spam, but they would have to use their own identity to do so. All of a sudden, blacklists are effective again.