Unfortunately, the actual cost of providing that kind of customer support add up. The typical home user is very expensive to support: each has unique problems, especially in the Linux world. By keeping the cash price high, RedHat forces a lot of casual users into the "learn it yourselves" and "look it up on Google" world, which frankly works quite well.
Training up and adding twice as much staff to support a cheaper distro might not be a good business decision for RedHat.
You can build a disk image, and a little wrapper on an installation CD or for PXE to partition and install that OS, but it's a lot of work to set up.
The huge divide between Debian stable and Debian testing matches is even greater than that between RHES and Fedora Core, with all the problems that causes.
Penguin Computing? They tend to always have some funky little hardware feature just plain wrong, like weird mounting that barks your knuckles or cheap screws that strip their heads the third time you have to remount a machine.
Good point. SuSE is learning, or needs to learn, a bunch of software lessons that RedHat learned two years ago.
1: Do not write your own complex and intricate installation and management tools to replace those written by the authors of software. If you need to do this, keep them very small and modular. SuSE's "YAST" tool is what "linuxconf" was for RedHat a few years back, and is nearly as bad. SuSE has actively broken software author's configuration tools to stuff them into YaST. By itself, YaST is not bad, but breaking things under it is an exceptionally bad practice.
2: The excessive internationalization is a good idea for selling in the European market, but in the core software it still breaks things and creates a huge burden on your programmers. Use flat 7-bit ASCII, people, and keep your software stable!
And add in the cost of Microsoft Office, and an anti-virus package, and an unlimited print server and email server. It adds up pretty fast when you compare the complete price of the package.
The WhiteBox Linux distribution, rebuile from the published RHES source RPM's and re-assembled into a full distribution with all the enterprise bits by default, is at:
http://www.whiteboxlinux.org
If you need RHES or its like, get a copy first of WhiteBox and see if all the tools work on your hardware, then buy RHES for the support. Personally, I think RHES it's always way out of date, especially since it's still running a 2.4 kernel.
Cryptographic or hash based sender authentication has its usages, but it still leaves a large burden on the receiving end. There's nothing quite like hammering a site doing such authentication to death by sending huge volumes of fake email valid or invalid keys.
Also, given the plethora of zombied machines being used for spam and attacks and email worms worldwide, the spammers and abusers have no difficulty stealing the computational load to use other people's keys. And getting use of any of those sender or message authentication tools into people's email clients is a technically workable but politically painful process. Good encryption/verification runs into legal problems with various governmental laws, for example.
Ohh, goodness. A badly written position paper. I'll refute 2 of them in small sowrds.
1: SPF is just starting. The use of DNS TXT records is until DNS can be adapted to include a new and more appropriate record, which is a painfully slow process, but it's already proven its effectiveness. And the process is already grinding along, although there's been a big distraction because of Microsoft's SenderID trying to pretend to be part of SPF.
2: SPF does interfere with mail reflectors, the standard ".forward" mechanism used by typical forwarding systems. Unfortunately, this is clearly necessary: there is no way to distinguish such email from blatantly forged email, as we who get hundreds of thousands of "your email worm bounced" messages a month can testify. Sites are going to have to implement more and more filters against such abuse, simply to reduce the load of bounces and the new attack mechanism of using dozens or hundreds of machines to forge viruses in someone's name and let them get all the bounces.
3: The author cannot even spell SRS, much less understand how it brings the bounce messages back to the forwarding machine, which sends it back to the original sender at the SMTP server itself. To joe-job someone with it, you'd have to replace the hash keys generated by the SRS-based forwarder.
No, the facts are good. You're underestimating the rancor generated by sending the challenges to innocent people, and the extent these days to which automated filtering will simply pitch or block the challenge letters because they usually look so much like spam. "Click here to verify that you want to really send me email" is pretty good.
Given the amount of email that looks just like that these days which is pure email worm traffic, people are just going to dump the challenges. And they should, since almost all of such challenge-like letters are email worms.
And oh, yes, we've neglected the ability to Joe-Job innocent people by forging email from them and sending it to the challenge/response system. Until something like SPF is in much more widespread use, or unless a preliminary filtering package is in place for the receiver (in which case why bother with C/R), most of the challenges people receive for the foreseeable future are going to be from email worms they didn't send.
Yes, it's a bitch to do if you want to allow the clients to handle the reverse DNS themselves. There are also two slightly different standards for how to do the delegation, and it involves creating additional domain tables that are even more fun and games to manage correctly.
That depends on how you define spam. If by spam you mean bulk unsolicited email, then yes, almost all of it is forged. But that includes email worms and viruses and lots of fraudulent stuff.
Some spammers do try to stay vaguely legal and follow the CANSPAM act and include a valid email or remove-from-list address. But most of those turn around and use your validated email address for their next venture: the "do not spam" address of one spammer is worth good money to another one.
You seem to have Jason's style. He's very gentle in his approach, even when he disagrees with you, but implies that disagreeing with him means you simply don't understand it (or you're stupid, by implication).
I do understand it quite well. I discarded such email address manipulation approaches roughly 15 years ago, when dealing with irritating gits in email who liked mucking with active mailing lists and harassing individual members.
Yes, you need to own the domain and administer every possible email address in it for your own personal use lest other people get sent your email, and vice versa. This is not feasible for most of us.
OK, I think I recognize this guy's style. I think he's the author of TMDA, who has a very friendly and feel-good sort of approach to the world that doesn't work well in groups. (He moved to Hawaii to get away from it all, which doesn't work for everyone!)
TMDA requires a sophisticated game of three-card Monte, for every single email recipient, that requires control of the mail delivery agent and the ability to generate and discard dozens, even hundreds of distinct email addresses at whim. Most of us simply don't have the resources for that kind of email address manipulation: there aren't enough domains around or easily handled to provide this under current email usage. And large ISP's like AOL or university's cannot afford to give away 10,000 distinct domain names for the email of 10,000 students and staff, it just breaks down in large groups of users.
And managing the passwords themselves is fine for someone who's comfortable storing a dozen different SSH or PGP keys or passwords and switching among them at whim, but for most folks, it's an unacceptable burden and will never gain prevalence.
That's what SPF is for. Take a look over at http://spf.pobox.net for details. It's quite lightweight, and if it keeps growing, we'll be able to dump a lot of the forged email on the floor without ever generating bounced messages: it gets blocked as soon as the connecting SMTP client says who it thinks the email bounces should go to.
Delegating reverse DNS is difficult and expensive for the ISP's to do. Simply updating their zones is fairly laborious, although tools like MKRDNS are helpful at www.mkrdns.org.
But reverse DNS is problematic at best for anyone hosting multiple email domains on a single mail server, such as many home or small business SMTP servers, since the same IP address supports multiple mail domains and for obvious reasons you want the outgoing headers to look like they're really from those distinct domains, even if they all live on the same machine.
All these problems go away when we go to IPv6, but that's unlikely to happen within the professional lifetime of any but our youngest slashdotters.
Quarantining questionable mail is good. Blocking outright is even better, but currently relies on blacklists for easiest, SPF for next easiest, and postage of some sort for hardest.
I agree that the actual domain lookups and other content examination by FairUCE is potentially useful as yet spam scoring technique, but it should be developed on that basis at best. Pitch the challenge/response.
And if your idea is really good, get something going over on sourcforge.net about it and let people look at it to see if it's already been done and broken the hard way.
People like you are included in what I meant by "authorized SMTP server". Apparently that was not clear when I wrote the note.
If you're not "authorized", then the ISP's should consider it a reasonable trade-off in work to "authorize" you as a known SMTP server, give you a static hostname, etc. in return for a modest fiscal incentive. This protects them and their network from carrying incredible spam traffic from worms and zombied machines, and protects you from being blocked with the rest of their customers.
Good question. "Branding" is a separate problem. I think that enough people will in fact object to that behavior that they'd lose out in business terms.
I'd certainly tell my friends and clients not to use such ISP's.
Nope. They just have to submit a lot of spew that looks like the challenge email, then a significant number of people's automatic filters (especially Bayesian or Markovian word filters) will auto-filter it. Then people who use the challenge systems get their email thrown in the trash. Voila, anyone who actually wants their email read stops using or refusing to use the challenge system and it never catches on.
What you didn't mention was that this kind of high correlation between the machine generated tag or challenge has already been shown to actually be a sign of being spam, with the "Haiku" header tag and Microsoft's new "Domainkeys" authorization keys.
You're not talking about a "dialup connection", or a normal home user setup. If you're running an SMTP server at home for you and your "recipients", you're running a business class service. Those cost more to support for the ISP, and you should be prepared to pay for it as such, with a registered domain name, MX records, forward and reverse DNS, and accountability.
You're paying for a static IP, and maybe a registered hostname, and paying appropriate fees to run that kind of SMTP service instead of using the ISP's SMTP? Good, then you can and should be able to use port 25 outbound. Go to it, and continue to run your business successfully *if you're paying for the hostname and the service*. If not, you may be in violation of your contract with your ISP by running a business from your home account.
It's the casual home user I'm concerned about, whose home boxes have been so widely zombied or infectedthat simply blocking all such users at the ISP level or at the blacklist level is extremely useful for blocking both spam and email worms.
The lack of reverse DNS is another problem, and is why insistence on forward and reverse DNS matching for all SMTP server names is simply impossible in the real world. People like you with legitimate uses, and people like me who host multiple SMTP services on the same IP address, are not feasible to have the forward and reverse match.
We're IT people. Doesn't it count as "misery loves company" to stuff mistreated captives in tiny little cubicles until they're glistening in grease!
I keep picturing all these sheep being herded together by the HR border collies, caying "We can't have layoffs! My stock options are finally vested tomorrow! No, not my cellphone! You can shear me, take my right leg for leg-of-lamb, but don't take my cellphone! A-a-a-a-a-r-r-g-g-h=h!"
Do you feel the civil rights of your snot are somehow violated when you blow your nose, or if someone took a used kleenex and did medical research with it? The blastocysts being used for fetal cell research are only a few dozens of cells, they have never even had a single neuron or organ and simply do not deserve the same consideration as a person. Unless, of course, you believe in the "magic soul" business where somehow, at conception, a mystical and indetectable or verifiable "soul" is somehow deposited.
And there is a huge difference between fetal stem cells and so-called "adult" stem cells, for technical reasons involving their numbers of cell divisions, resulting telomere lengths, and the environments they've been exposed to. While adult stem cells are potentially useful for various treatments, the possibility of using the non-rejected and highly adaptable tissues of fetal stem cells is quite amazing.
Slashdot Mirror
Unfortunately, the actual cost of providing that kind of customer support add up. The typical home user is very expensive to support: each has unique problems, especially in the Linux world. By keeping the cash price high, RedHat forces a lot of casual users into the "learn it yourselves" and "look it up on Google" world, which frankly works quite well. Training up and adding twice as much staff to support a cheaper distro might not be a good business decision for RedHat.
You can build a disk image, and a little wrapper on an installation CD or for PXE to partition and install that OS, but it's a lot of work to set up. The huge divide between Debian stable and Debian testing matches is even greater than that between RHES and Fedora Core, with all the problems that causes.
Penguin Computing? They tend to always have some funky little hardware feature just plain wrong, like weird mounting that barks your knuckles or cheap screws that strip their heads the third time you have to remount a machine.
It comes with a great rack?
Good point. SuSE is learning, or needs to learn, a bunch of software lessons that RedHat learned two years ago. 1: Do not write your own complex and intricate installation and management tools to replace those written by the authors of software. If you need to do this, keep them very small and modular. SuSE's "YAST" tool is what "linuxconf" was for RedHat a few years back, and is nearly as bad. SuSE has actively broken software author's configuration tools to stuff them into YaST. By itself, YaST is not bad, but breaking things under it is an exceptionally bad practice. 2: The excessive internationalization is a good idea for selling in the European market, but in the core software it still breaks things and creates a huge burden on your programmers. Use flat 7-bit ASCII, people, and keep your software stable!
And add in the cost of Microsoft Office, and an anti-virus package, and an unlimited print server and email server. It adds up pretty fast when you compare the complete price of the package.
The WhiteBox Linux distribution, rebuile from the published RHES source RPM's and re-assembled into a full distribution with all the enterprise bits by default, is at:
http://www.whiteboxlinux.org
If you need RHES or its like, get a copy first of WhiteBox and see if all the tools work on your hardware, then buy RHES for the support. Personally, I think RHES it's always way out of date, especially since it's still running a 2.4 kernel.
Cryptographic or hash based sender authentication has its usages, but it still leaves a large burden on the receiving end. There's nothing quite like hammering a site doing such authentication to death by sending huge volumes of fake email valid or invalid keys.
Also, given the plethora of zombied machines being used for spam and attacks and email worms worldwide, the spammers and abusers have no difficulty stealing the computational load to use other people's keys. And getting use of any of those sender or message authentication tools into people's email clients is a technically workable but politically painful process. Good encryption/verification runs into legal problems with various governmental laws, for example.
Ohh, goodness. A badly written position paper. I'll refute 2 of them in small sowrds. 1: SPF is just starting. The use of DNS TXT records is until DNS can be adapted to include a new and more appropriate record, which is a painfully slow process, but it's already proven its effectiveness. And the process is already grinding along, although there's been a big distraction because of Microsoft's SenderID trying to pretend to be part of SPF. 2: SPF does interfere with mail reflectors, the standard ".forward" mechanism used by typical forwarding systems. Unfortunately, this is clearly necessary: there is no way to distinguish such email from blatantly forged email, as we who get hundreds of thousands of "your email worm bounced" messages a month can testify. Sites are going to have to implement more and more filters against such abuse, simply to reduce the load of bounces and the new attack mechanism of using dozens or hundreds of machines to forge viruses in someone's name and let them get all the bounces. 3: The author cannot even spell SRS, much less understand how it brings the bounce messages back to the forwarding machine, which sends it back to the original sender at the SMTP server itself. To joe-job someone with it, you'd have to replace the hash keys generated by the SRS-based forwarder.
Ahh, yes. The "I have a way to do cold fusion, if I can just get the funding" approach to computer science.
No, the facts are good. You're underestimating the rancor generated by sending the challenges to innocent people, and the extent these days to which automated filtering will simply pitch or block the challenge letters because they usually look so much like spam. "Click here to verify that you want to really send me email" is pretty good.
Given the amount of email that looks just like that these days which is pure email worm traffic, people are just going to dump the challenges. And they should, since almost all of such challenge-like letters are email worms.
And oh, yes, we've neglected the ability to Joe-Job innocent people by forging email from them and sending it to the challenge/response system. Until something like SPF is in much more widespread use, or unless a preliminary filtering package is in place for the receiver (in which case why bother with C/R), most of the challenges people receive for the foreseeable future are going to be from email worms they didn't send.
Yes, it's a bitch to do if you want to allow the clients to handle the reverse DNS themselves. There are also two slightly different standards for how to do the delegation, and it involves creating additional domain tables that are even more fun and games to manage correctly.
That depends on how you define spam. If by spam you mean bulk unsolicited email, then yes, almost all of it is forged. But that includes email worms and viruses and lots of fraudulent stuff. Some spammers do try to stay vaguely legal and follow the CANSPAM act and include a valid email or remove-from-list address. But most of those turn around and use your validated email address for their next venture: the "do not spam" address of one spammer is worth good money to another one.
You seem to have Jason's style. He's very gentle in his approach, even when he disagrees with you, but implies that disagreeing with him means you simply don't understand it (or you're stupid, by implication).
I do understand it quite well. I discarded such email address manipulation approaches roughly 15 years ago, when dealing with irritating gits in email who liked mucking with active mailing lists and harassing individual members.
Yes, you need to own the domain and administer every possible email address in it for your own personal use lest other people get sent your email, and vice versa. This is not feasible for most of us.
OK, I think I recognize this guy's style. I think he's the author of TMDA, who has a very friendly and feel-good sort of approach to the world that doesn't work well in groups. (He moved to Hawaii to get away from it all, which doesn't work for everyone!) TMDA requires a sophisticated game of three-card Monte, for every single email recipient, that requires control of the mail delivery agent and the ability to generate and discard dozens, even hundreds of distinct email addresses at whim. Most of us simply don't have the resources for that kind of email address manipulation: there aren't enough domains around or easily handled to provide this under current email usage. And large ISP's like AOL or university's cannot afford to give away 10,000 distinct domain names for the email of 10,000 students and staff, it just breaks down in large groups of users. And managing the passwords themselves is fine for someone who's comfortable storing a dozen different SSH or PGP keys or passwords and switching among them at whim, but for most folks, it's an unacceptable burden and will never gain prevalence.
That's what SPF is for. Take a look over at http://spf.pobox.net for details. It's quite lightweight, and if it keeps growing, we'll be able to dump a lot of the forged email on the floor without ever generating bounced messages: it gets blocked as soon as the connecting SMTP client says who it thinks the email bounces should go to.
Delegating reverse DNS is difficult and expensive for the ISP's to do. Simply updating their zones is fairly laborious, although tools like MKRDNS are helpful at www.mkrdns.org. But reverse DNS is problematic at best for anyone hosting multiple email domains on a single mail server, such as many home or small business SMTP servers, since the same IP address supports multiple mail domains and for obvious reasons you want the outgoing headers to look like they're really from those distinct domains, even if they all live on the same machine. All these problems go away when we go to IPv6, but that's unlikely to happen within the professional lifetime of any but our youngest slashdotters.
Quarantining questionable mail is good. Blocking outright is even better, but currently relies on blacklists for easiest, SPF for next easiest, and postage of some sort for hardest. I agree that the actual domain lookups and other content examination by FairUCE is potentially useful as yet spam scoring technique, but it should be developed on that basis at best. Pitch the challenge/response. And if your idea is really good, get something going over on sourcforge.net about it and let people look at it to see if it's already been done and broken the hard way.
People like you are included in what I meant by "authorized SMTP server". Apparently that was not clear when I wrote the note. If you're not "authorized", then the ISP's should consider it a reasonable trade-off in work to "authorize" you as a known SMTP server, give you a static hostname, etc. in return for a modest fiscal incentive. This protects them and their network from carrying incredible spam traffic from worms and zombied machines, and protects you from being blocked with the rest of their customers.
Good question. "Branding" is a separate problem. I think that enough people will in fact object to that behavior that they'd lose out in business terms. I'd certainly tell my friends and clients not to use such ISP's.
Nope. They just have to submit a lot of spew that looks like the challenge email, then a significant number of people's automatic filters (especially Bayesian or Markovian word filters) will auto-filter it. Then people who use the challenge systems get their email thrown in the trash. Voila, anyone who actually wants their email read stops using or refusing to use the challenge system and it never catches on.
What you didn't mention was that this kind of high correlation between the machine generated tag or challenge has already been shown to actually be a sign of being spam, with the "Haiku" header tag and Microsoft's new "Domainkeys" authorization keys.
You're not talking about a "dialup connection", or a normal home user setup. If you're running an SMTP server at home for you and your "recipients", you're running a business class service. Those cost more to support for the ISP, and you should be prepared to pay for it as such, with a registered domain name, MX records, forward and reverse DNS, and accountability.
You're paying for a static IP, and maybe a registered hostname, and paying appropriate fees to run that kind of SMTP service instead of using the ISP's SMTP? Good, then you can and should be able to use port 25 outbound. Go to it, and continue to run your business successfully *if you're paying for the hostname and the service*. If not, you may be in violation of your contract with your ISP by running a business from your home account.
It's the casual home user I'm concerned about, whose home boxes have been so widely zombied or infectedthat simply blocking all such users at the ISP level or at the blacklist level is extremely useful for blocking both spam and email worms.
The lack of reverse DNS is another problem, and is why insistence on forward and reverse DNS matching for all SMTP server names is simply impossible in the real world. People like you with legitimate uses, and people like me who host multiple SMTP services on the same IP address, are not feasible to have the forward and reverse match.
We're IT people. Doesn't it count as "misery loves company" to stuff mistreated captives in tiny little cubicles until they're glistening in grease! I keep picturing all these sheep being herded together by the HR border collies, caying "We can't have layoffs! My stock options are finally vested tomorrow! No, not my cellphone! You can shear me, take my right leg for leg-of-lamb, but don't take my cellphone! A-a-a-a-a-r-r-g-g-h=h!"
Hey, if the folks of Minnesota couldn't make fun of themselves, they'd have *nothing* to do on Saturday night.
Do you feel the civil rights of your snot are somehow violated when you blow your nose, or if someone took a used kleenex and did medical research with it? The blastocysts being used for fetal cell research are only a few dozens of cells, they have never even had a single neuron or organ and simply do not deserve the same consideration as a person. Unless, of course, you believe in the "magic soul" business where somehow, at conception, a mystical and indetectable or verifiable "soul" is somehow deposited. And there is a huge difference between fetal stem cells and so-called "adult" stem cells, for technical reasons involving their numbers of cell divisions, resulting telomere lengths, and the environments they've been exposed to. While adult stem cells are potentially useful for various treatments, the possibility of using the non-rejected and highly adaptable tissues of fetal stem cells is quite amazing.