I know there are a lot of sysadmins around that are incapable of learning new tools or even new systems. Those are the kind of people that when they move from one Unix style platform to another they are totally lost, run crying to momma, and demand the old systems back. Yeah, I've seen those kind. But I didn't think they were the kind who would post to Slashdot. Sheesh.
And yes, I do have points, but this story/thread was more important to post comments on, so the points are going to help clean up some other story which I don't have any words for, later on tonight.
While there are certain business models that suggest it is wise to use commidity computers (read: Intel x86 based), there are others that suggest using high end high performance machines. Where things can be adequately load balanced over many small servers (think: RAIS: Redundant Array of Inexpensive Servers), such as most web services; other things such as a mission critical central database, really need a highly reliable "five 9s" or even "six 9s" platform. High end SUN machines are supposedly that (my experience with them is not recent, although my past experience with the model 2000 didn't get any better than about "four 9s").
With the exception of my desktop locking up a couple times due to a problem with X, I have not had a single software crash in over 3 years using Linux. I have had various hardware problems, power outages (cheap UPSes), and of course the occaisional big upgrade (Slackware 9.0 is in progress now). I certainly would like to have a more robust and reliable hardware platform for my servers. But switching to Solaris simply isn't an option in the cases I am currently running right now. Linux on SUN Sparc would get me where I want to be. But SUN's support for Linux is too focused on Intel x86 (for obvious market reasons), and is ignoring it's own Sparc platform on the low end. I'm not saying I would want to run Linux on the Starfires. But I would on the Netras. And in fact many people do that anyway, given a few distributions do have Sparc versions available. SUN doesn't need to support it so far as creating a distribution, but I do think they need to do a better job in general support such as making binaries for programs they do offer in binary only form available not only for Solaris Sparc and Linux x86, but also for Solaris x86 (some things are available, but not all) and Linux Sparc.
If SUN were to do a better job helping to make Linux work on Sparc machines, I'm sure they could sell more of them. That won't be a big market, but it will be a way to smooth out the transition between Linux x86 and enterprise class Solaris Sparc for many.
I don't see the need for SUN to offer a Linux distribution. But it would certainly be nice if Linux was supported for Sparc, even if that support is through other vendors like Redhat (which has dropped Sparc) or others (there is Debian if you want to self-support or hire independent support, and I think SuSE still has Sparc available for download but not on CD).
BTW, another reason to go with Sparc is to get 64 bit. Of course there are other 64 bit platforms out there. But those who go there are essentially lost from being SUN customers once that happens. Just because I might need 64 bit doesn't mean I need Solaris.
That program got my account cancelled! Well, OK, so I submitted 1000 jobs with 255 steps each specifying PGM=IEFBR14. But the real reason was because I used lower case Hollerith punch codes on the job names, and the console ops couldn't cancel the individual jobs because everything typed on the console was upper case.
How do you define when a vulnerability is fixed, at least for the purpose of determining when to go public with it? Consider a vulnerability in some shared and widely used and distributed library such as OpenSSL or Zlib. Potentially you could say it is fixed as soon as there is a source patch. But that doesn't really make it universally available. Armed with the patch, the vulnerability may well become obvious, yet most systems which are installed and maintained in binary code remain vulnerable. Should things wait until the distributions package the fix? How many have to wait for the others?
And what if the same vulnerability exists in more than one implementation because of things like code re-use, or a flaw in a protocol that can be dealt with in the code anyway? Suppose OpenBSD fixes theirs in 2 hours and NetBSD fixes theirs in 5 hours and FreeBSD fixes theirs in 9 hours and Slackware fixes theirs in 15 hours and Debian fixes theirs in 24 hours and SuSE fixes theirs in 36 hours and Redhat fixes theirs in 60 hours and Microsoft Windows fixes theirs in 10 days (hypothetical times chosen arbitrarily)? Would it be OK for OpenBSD to go ahead and blast their security mailing list with the fix when it's done? Or should everyone have to wait until the stragglers get their act together?
IMHO, vulnerabilities should be released as soon as the first vendor has a fix, or after some fixed determinate time to ensure they don't all get together to hide the problem (not that all of them would, but certain vulnerabilities may only affect a small subset of them, or even just one). Yes, that leaves the systems "supported" by the stragglers unprotected. But that should also help leverage market pressure to fixing things faster, and designing to avoid the as well.
Actually, it looks like it might be about hardware as much as it is software, especially any hardware that requires a driver to be installed in Windows (where XP compatibility issues are more serious). The benefit is that it forces manufacturers to make the drivers better (benefits Windows XP users). The problem is in time Microsoft may require functional changes in the way the hardware behaves, either to force DRM at that level, or worse, to sabotage the ability of BSD and Linux to use the hardware at the same capability.
If you don't want to name your own language because it might focus too much on just a single one, then perhaps you might list several, maybe including your own or maybe not, that give a general idea of how you feel about it. Or perhaps just tell us how many people are currently speaking it. You can get some references for that in Ethnologue: Languages of the World. For example, one small language, Frisian, has 700,000 speakers and is rather unknown through most of the world. Is yours smaller or larger than this?
I've found 6000 some spamming servers in Rackspace's network. Based on their pricing, that's over a million dollars a month. Based on the spam volumes I've seen, they are costing others over 30 million dollars a month in mail server load costs, and probably a lot more figuring in "just press delete" time for what makes it through. Lots of networks are blocking Rackspace now, as well as many others as another comment in this thread mentioned.
It just seems to odd to refresh the page to see more comments about spam, and I get a banner ad promoting one of the larger spammer hosters in the US... Rackspace. Those who sign up for service from those scumbags are just as bad as the scumbags because that effectively helps support the spam they keep pounding my servers with. So far today, 98 attempts just from Rackspace addresses. Yesterday there was a total of 240.
And while previewing this comment submission, yet another Rackspace banner ad. Don't these guys know I'm never, ever, going to pay them for any services?
Despite the obvious problems of jurisdiction, there is one thing that could be outlawed. That is a requirement that when the mass emailer gets a rejection of the spam, either through an SMTP 5XX code, or a bounced message (they would be required to codify the return addresses and have capacity to receive all the bounces and process them), then the address being mailed to should be handled this way. If the address had been successfully delivered to before, further mailings should be stopped after rejections keep coming back for 7 days. If the address had never been successfully delivered to before, further mailings should stop immediately.
Spam is regularly mailed to a few hundred email addresses that not only do not exist, but never have existed (in a few domains I have). A lot of it just comes from random locations, so that can be just propogation of bad addresses among small time spammers (you know, the CD of millions). But a lot of this repeat spam to never-existed addresses comes from bulk mailing houses, including places like rackspace.com, m0.net, and even weatherbug.com.
This is a clear case of abuse which could be used to help shut some obvious spammers down, or at least fine them heavily, without running afoul of things like first amendment issues. If there's no one there to read a message, then it isn't free speech. And once it is possible for them to know this is the case, then any further attempts are nothing more than intentional abuse.
Re:Spam can be avoided without protocol changes.
on
IETF to Look at Spam
·
· Score: 1
Not all commercial advertisements are spam. Not all spam is commercial advertisements. One problem we have in finding a solution is defining the problem. One question is what is spam. And we can't seem to even agree on that. To me, spam is unsolicited bulk email. Or perhaps it is unsolicited impersonal email. Or just impersonal email. If it isn't a message being sent as part of a personal relationship, I don't want it, and therefore it is spam.
As for redundancy, spammers are already figuring out how to make each mail different. Systems that depend on checking for duplication in the world will just be part of a "tit for tat" arms race with spammers who will find more clever ways to evade these techniques, quite possibly using AI techniques to generate the wording of the message.
The real solution is to catch who sends the spam and make them sleep on those carpet chairmats turned upside down.
It has nothing to do with whether you have a T1, a DSL, a dialup, or a cable modem. It has everything to do with identity and authentication. Were there to be a good infrastructure of authentication in SMTP already, and I knew how to identify you in it, I could let it pass. Or there might be a means to have it look up your history of spamming, and finding 0, let it pass.
Is your IP address STATICALLY assigned? If so, I can whitelist it.
The last-mile technology is not relevant. I can't tell what it is. I can guess perhaps from the name. But there are some ISPs that give T1 lines the same treatment (bogus reverse DNS) that they do for DSL. And there are other ISPs that give DSL as well as T1 a competent service (proper identification via reverse DNS with matching forward DNS). Get the latter if you're running a mail server, or learn how to "smart host" forward through your ISP.
Sure, spam is a social problem. But there are generally no practical solutions to any social problem. To the extent that my spam blocking narrows the scope of who can send me mail, it is a private address. It's just that most people can still send to me. So yes, I am applying a technological solution to a social problem. The reason is that it is not practical to carry out the necessary social solution.
Interestingly, spam experiences do vary greatly. I obviously get far more than you do. Here is how much spam I got recently:
2002-07 - 6646
2002-08 - 10336
2002-09 - 11467
2002-10 - 6535
2002-11 - 12001
2002-12 - 36760
2003-01 - 30261
2003-02 - 19205
That looks like a rather public address to me. Actually it covers several addresses.
And remember, I'm not blocking you, per se. I'm blocking an ability to identify that it is really you, or a least really someone willing to be identified (at connection time, e.g. reverse DNS). If you're stuck on DYNAMIC IP addressing, I'm sure you can figure a way around the problem.
I get almost no spam from DSL customers. That's because I block the DSL connections. And to be sure I don't get stuck having to keep a list of DSL IP addresses updated all the time as those pools are changed, I do the blocking based on the domain name. What this does is allows the ISP some actual control. For example, they can separate their centralized email servers (that legitimate mail is supposed to relay through) from their direct DSL lines, based on domain name (most ISPs are smart enough to put the DSL lines in subdomains, just like they did for dialups). Dedicated connections that just happen to be using DSL technology can simply have reverse DNS set up to identify the mail server hostname within the customer domain name. If a customer sends spam, then I can block that customer by their domain name (instead of by an IP address which might end up being used by someone else later, without my knowledge).
Still, using a certified method of sending mail can help, whether it is by STARTTLS in SMTP (certifies the sending mail server), or a certificate in the message itself (provided I allow the SMTP session to get as far as the "DATA" command, which might not happen on those untrusted servers like the generic DSL ports).
Re:It wouldn't be adopted instantaneously.
on
IETF to Look at Spam
·
· Score: 2, Insightful
Adopting a new protocol is very different than upgrading to a new version of an implementation of a protocol. In the case of a new protocol, there might be two different kinds of things going on at the same time, either with the same MTA, or different MTAs. In the case of Apache 2.0, you can't have the same web site available under the new version at the old version at the same time. With a new protocol, you can easily have a transition period because of the window of concurrency. With a new version of an implementation of the same protocol, deployed for a single instances of usage (e.g. a domain), it's basically one or the other. You can run Apache 2.0 on www.test-site.example.com while Apache 1.3 still runs www.example.com. But you can't have www.example.com running both very easily.
One of the reasons CF won't be practical is that each machine will be in a separate customer location, and upgrades will be distributed by sending a replacement media to each location. At a few pennies per CDR this is practical. Mini-CD media is nearly as cheap these days. CF is nowhere as close. With CF now I have to arrange to have the old media shipped back. I'm better off with full size CD drives than with CF.
Aside from the fact that the custodian of the information certainly has a lot to blame in this, there is another big part of the problem. That problem is what people can actually do with the information.
An SSN is identity. It is nothing more than that. The problem is people make the incorrect assumption that it is authenticity (I can recite the number, or read it off a little card in my wallet, so it must be me), and authority (this account has your SSN and is overdrawn, so you are liable for it).
If any law change is needed, it is a law change that says that it is illegal for an SSN to be accepted for any purpose other than identity. What that means is that if I walk into a bank and open an account citing some SSN, the bank needs to understand that all this does is identify someone, and not necessarily me. If the bank causes harm to the real owner of the SSN by having provided any derogatory credit information based on that SSN, then the bank shall be fully liable for having not taking reasonable measures to ensure accuracy of information. And by that, what I mean is that the bank can't simply say that the victim needs to track down the perpetrator to cover the costs. The banks need to be forced to properly authenticate the information they use, especially when and where it might be used in a negative way.
And I don't mean to pick on banks (I just happen to have an open case with Chase Manhattan bank which continues to allow someone to operate a credit card account with my SSN, reported on my credit reports, without my consent, and after I have advised them of the fraud). Such a law should apply to anyone and everyone who accepts and uses SSN data for anything. It's the negative things that can be done (like bad credit info) that needs to be stopped (in addition to other stupidities like running computers insecurely and connecting systems to the internet that have no business being there).
My younger brother's SSN is actually immediately prior to my own. Yet we were born 3 states away from each other (and 2 years apart, too). So the parent post is correct. The probability of being born in the associated state is high, and higher with younger people, but is not a certainty. And as the numbers are used up, they may even change the scheme to assign them. Maybe they should now.
I've filled out the full size bays in quite a number of machines I have, and most still have floppy size bays available. I could put a floppy or zip drive in there, but a floppy is way too tight to build the rescue disk system I need to have (because it has more software than can ever fit on a floppy... it's about 32MB in size). I've tried Zip drives, but all three I've used turn out to be regularly unreliable (I can coax them to work, but this isn't the kind of thing I want to put in customer locations). Maybe it's the media, but either way, the Zip drive option isn't where I want to go.
A small mini-CD drive that fits in the floppy drive bay would be ideal. Such a product would also let us start downsizing computer cases in a lot of new ways for the special purposes that don't need large amounts of CD data (such as firewalls and specialized mini-servers).
I have 3 X servers running on my desktop, on vt10, vt11, and vt12. And on top of that I have 60 text virtual consoles, vt1-vt9 and vt13-vt63. And yes, every one of them is in use. I've changed the keyboard mapping around so that ALT+key switches VT where key is just about every key on the main part of the keyboard. For example, ALT+1 is vt14, ALT+tab is vt28, ALT+/ is vt61, ALT+space is vt62 and ALT+ESC is vt63.
Having multiple X servers running does allow me to switch between different window managers without messing up what I'm already doing. I have my own customized fvwm based environment on:0, a stock Gnome setup on:1, and a stock KDE setup on:2 (logged in under different userids).
BTW, the virtual consoles do work on SUN Sparc machines when running Linux on them. There's nothing particular about the hardware to implement virtual consoles. They just happen to be text in graphics mode on SUN Sparc, much as they would on x86 if you used frame buffer mode (that's apparently what's happening on the SUN Sparc machines).
As an example of just how hard it is to identify, consider the case of a bulk mailer that supplements its list of 5,000 local people who have requested information on the product with a purchased list of 495,000 email addresses known to be in the same city and surrounding area. So they send out the big mailing to 500,000 people. It's the same exact content to everyone. There's the usual sell wording followed by the URL to the web page to opt-in and opt-out or refine your mailing choices.
Is this spam?
To many people it will be, because it is most certainly unsolicited, and also bulk. To others it won't be because they know they asked for it, they are interested in it, and they may never realize it's bulk (they only got one copy because they only have one email address).
To detect if it is spam or not involves more than just the content of the mail; it also involves the intentions and/or actions of the recipient.
Barry Shein's proprosal may well cause this mailer to not add those 495,000 other addresses due to the cost. That would probably be a good thing. And I see merits to his idea, as well as problems.
His idea may also mean that the mailing to the 5,000 people that requested it also cannot be done. Many organizations, such as charities, but also including small scale businesses, simply cannot afford that, especially if the mailing is something that isn't really meant to bring in new business, but to just be informative about ongoing events. If there was a way to allow such groups to send their mail, anyway, Barry Shein's idea might work. OTOH, that would also result in spammers trying fit themselves into such ways, too.
The first thing you assume is that your first sentence is what gave the first idea. That's not true. I didn't get a "first idea" until after I read the whole thing. It's clear our thought processes are very different. I no longer see any point it in this. Perhaps it is the case that your wording has only one possible way to understand it the way you think. I saw several meanings. I'm sorry you spent so much time writing a response, but I feel no value in reading the rest of it.
Slashdot Mirror
I know there are a lot of sysadmins around that are incapable of learning new tools or even new systems. Those are the kind of people that when they move from one Unix style platform to another they are totally lost, run crying to momma, and demand the old systems back. Yeah, I've seen those kind. But I didn't think they were the kind who would post to Slashdot. Sheesh.
And yes, I do have points, but this story/thread was more important to post comments on, so the points are going to help clean up some other story which I don't have any words for, later on tonight.
While there are certain business models that suggest it is wise to use commidity computers (read: Intel x86 based), there are others that suggest using high end high performance machines. Where things can be adequately load balanced over many small servers (think: RAIS: Redundant Array of Inexpensive Servers), such as most web services; other things such as a mission critical central database, really need a highly reliable "five 9s" or even "six 9s" platform. High end SUN machines are supposedly that (my experience with them is not recent, although my past experience with the model 2000 didn't get any better than about "four 9s").
With the exception of my desktop locking up a couple times due to a problem with X, I have not had a single software crash in over 3 years using Linux. I have had various hardware problems, power outages (cheap UPSes), and of course the occaisional big upgrade (Slackware 9.0 is in progress now). I certainly would like to have a more robust and reliable hardware platform for my servers. But switching to Solaris simply isn't an option in the cases I am currently running right now. Linux on SUN Sparc would get me where I want to be. But SUN's support for Linux is too focused on Intel x86 (for obvious market reasons), and is ignoring it's own Sparc platform on the low end. I'm not saying I would want to run Linux on the Starfires. But I would on the Netras. And in fact many people do that anyway, given a few distributions do have Sparc versions available. SUN doesn't need to support it so far as creating a distribution, but I do think they need to do a better job in general support such as making binaries for programs they do offer in binary only form available not only for Solaris Sparc and Linux x86, but also for Solaris x86 (some things are available, but not all) and Linux Sparc.
If SUN were to do a better job helping to make Linux work on Sparc machines, I'm sure they could sell more of them. That won't be a big market, but it will be a way to smooth out the transition between Linux x86 and enterprise class Solaris Sparc for many.
I don't see the need for SUN to offer a Linux distribution. But it would certainly be nice if Linux was supported for Sparc, even if that support is through other vendors like Redhat (which has dropped Sparc) or others (there is Debian if you want to self-support or hire independent support, and I think SuSE still has Sparc available for download but not on CD).
BTW, another reason to go with Sparc is to get 64 bit. Of course there are other 64 bit platforms out there. But those who go there are essentially lost from being SUN customers once that happens. Just because I might need 64 bit doesn't mean I need Solaris.
It was actually quite a long time ago ... OS/MVT with HASP.
That program got my account cancelled! Well, OK, so I submitted 1000 jobs with 255 steps each specifying PGM=IEFBR14. But the real reason was because I used lower case Hollerith punch codes on the job names, and the console ops couldn't cancel the individual jobs because everything typed on the console was upper case.
How do you define when a vulnerability is fixed, at least for the purpose of determining when to go public with it? Consider a vulnerability in some shared and widely used and distributed library such as OpenSSL or Zlib. Potentially you could say it is fixed as soon as there is a source patch. But that doesn't really make it universally available. Armed with the patch, the vulnerability may well become obvious, yet most systems which are installed and maintained in binary code remain vulnerable. Should things wait until the distributions package the fix? How many have to wait for the others?
And what if the same vulnerability exists in more than one implementation because of things like code re-use, or a flaw in a protocol that can be dealt with in the code anyway? Suppose OpenBSD fixes theirs in 2 hours and NetBSD fixes theirs in 5 hours and FreeBSD fixes theirs in 9 hours and Slackware fixes theirs in 15 hours and Debian fixes theirs in 24 hours and SuSE fixes theirs in 36 hours and Redhat fixes theirs in 60 hours and Microsoft Windows fixes theirs in 10 days (hypothetical times chosen arbitrarily)? Would it be OK for OpenBSD to go ahead and blast their security mailing list with the fix when it's done? Or should everyone have to wait until the stragglers get their act together?
IMHO, vulnerabilities should be released as soon as the first vendor has a fix, or after some fixed determinate time to ensure they don't all get together to hide the problem (not that all of them would, but certain vulnerabilities may only affect a small subset of them, or even just one). Yes, that leaves the systems "supported" by the stragglers unprotected. But that should also help leverage market pressure to fixing things faster, and designing to avoid the as well.
Actually, it looks like it might be about hardware as much as it is software, especially any hardware that requires a driver to be installed in Windows (where XP compatibility issues are more serious). The benefit is that it forces manufacturers to make the drivers better (benefits Windows XP users). The problem is in time Microsoft may require functional changes in the way the hardware behaves, either to force DRM at that level, or worse, to sabotage the ability of BSD and Linux to use the hardware at the same capability.
Sounds like Catalan. That would make the "large" language involved Spanish.
If you don't want to name your own language because it might focus too much on just a single one, then perhaps you might list several, maybe including your own or maybe not, that give a general idea of how you feel about it. Or perhaps just tell us how many people are currently speaking it. You can get some references for that in Ethnologue: Languages of the World. For example, one small language, Frisian, has 700,000 speakers and is rather unknown through most of the world. Is yours smaller or larger than this?
The best and most complete online language reference for over 6,800 languages is "Ethnologue: Languages of the World", created by SIL International.
I've found 6000 some spamming servers in Rackspace's network. Based on their pricing, that's over a million dollars a month. Based on the spam volumes I've seen, they are costing others over 30 million dollars a month in mail server load costs, and probably a lot more figuring in "just press delete" time for what makes it through. Lots of networks are blocking Rackspace now, as well as many others as another comment in this thread mentioned.
It just seems to odd to refresh the page to see more comments about spam, and I get a banner ad promoting one of the larger spammer hosters in the US ... Rackspace. Those who sign up for service from those scumbags are just as bad as the scumbags because that effectively helps support the spam they keep pounding my servers with. So far today, 98 attempts just from Rackspace addresses. Yesterday there was a total of 240.
And while previewing this comment submission, yet another Rackspace banner ad. Don't these guys know I'm never, ever, going to pay them for any services?
Despite the obvious problems of jurisdiction, there is one thing that could be outlawed. That is a requirement that when the mass emailer gets a rejection of the spam, either through an SMTP 5XX code, or a bounced message (they would be required to codify the return addresses and have capacity to receive all the bounces and process them), then the address being mailed to should be handled this way. If the address had been successfully delivered to before, further mailings should be stopped after rejections keep coming back for 7 days. If the address had never been successfully delivered to before, further mailings should stop immediately.
Spam is regularly mailed to a few hundred email addresses that not only do not exist, but never have existed (in a few domains I have). A lot of it just comes from random locations, so that can be just propogation of bad addresses among small time spammers (you know, the CD of millions). But a lot of this repeat spam to never-existed addresses comes from bulk mailing houses, including places like rackspace.com, m0.net, and even weatherbug.com.
This is a clear case of abuse which could be used to help shut some obvious spammers down, or at least fine them heavily, without running afoul of things like first amendment issues. If there's no one there to read a message, then it isn't free speech. And once it is possible for them to know this is the case, then any further attempts are nothing more than intentional abuse.
Not all commercial advertisements are spam. Not all spam is commercial advertisements. One problem we have in finding a solution is defining the problem. One question is what is spam. And we can't seem to even agree on that. To me, spam is unsolicited bulk email. Or perhaps it is unsolicited impersonal email. Or just impersonal email. If it isn't a message being sent as part of a personal relationship, I don't want it, and therefore it is spam.
As for redundancy, spammers are already figuring out how to make each mail different. Systems that depend on checking for duplication in the world will just be part of a "tit for tat" arms race with spammers who will find more clever ways to evade these techniques, quite possibly using AI techniques to generate the wording of the message.
The real solution is to catch who sends the spam and make them sleep on those carpet chairmats turned upside down.
It has nothing to do with whether you have a T1, a DSL, a dialup, or a cable modem. It has everything to do with identity and authentication. Were there to be a good infrastructure of authentication in SMTP already, and I knew how to identify you in it, I could let it pass. Or there might be a means to have it look up your history of spamming, and finding 0, let it pass.
Is your IP address STATICALLY assigned? If so, I can whitelist it.
The last-mile technology is not relevant. I can't tell what it is. I can guess perhaps from the name. But there are some ISPs that give T1 lines the same treatment (bogus reverse DNS) that they do for DSL. And there are other ISPs that give DSL as well as T1 a competent service (proper identification via reverse DNS with matching forward DNS). Get the latter if you're running a mail server, or learn how to "smart host" forward through your ISP.
Sure, spam is a social problem. But there are generally no practical solutions to any social problem. To the extent that my spam blocking narrows the scope of who can send me mail, it is a private address. It's just that most people can still send to me. So yes, I am applying a technological solution to a social problem. The reason is that it is not practical to carry out the necessary social solution.
Interestingly, spam experiences do vary greatly. I obviously get far more than you do. Here is how much spam I got recently:
2002-07 - 6646
2002-08 - 10336
2002-09 - 11467
2002-10 - 6535
2002-11 - 12001
2002-12 - 36760
2003-01 - 30261
2003-02 - 19205
That looks like a rather public address to me. Actually it covers several addresses.
And remember, I'm not blocking you, per se. I'm blocking an ability to identify that it is really you, or a least really someone willing to be identified (at connection time, e.g. reverse DNS). If you're stuck on DYNAMIC IP addressing, I'm sure you can figure a way around the problem.
Yes, that was indeed my point. Thanks for the clarification.
I get almost no spam from DSL customers. That's because I block the DSL connections. And to be sure I don't get stuck having to keep a list of DSL IP addresses updated all the time as those pools are changed, I do the blocking based on the domain name. What this does is allows the ISP some actual control. For example, they can separate their centralized email servers (that legitimate mail is supposed to relay through) from their direct DSL lines, based on domain name (most ISPs are smart enough to put the DSL lines in subdomains, just like they did for dialups). Dedicated connections that just happen to be using DSL technology can simply have reverse DNS set up to identify the mail server hostname within the customer domain name. If a customer sends spam, then I can block that customer by their domain name (instead of by an IP address which might end up being used by someone else later, without my knowledge).
Still, using a certified method of sending mail can help, whether it is by STARTTLS in SMTP (certifies the sending mail server), or a certificate in the message itself (provided I allow the SMTP session to get as far as the "DATA" command, which might not happen on those untrusted servers like the generic DSL ports).
Adopting a new protocol is very different than upgrading to a new version of an implementation of a protocol. In the case of a new protocol, there might be two different kinds of things going on at the same time, either with the same MTA, or different MTAs. In the case of Apache 2.0, you can't have the same web site available under the new version at the old version at the same time. With a new protocol, you can easily have a transition period because of the window of concurrency. With a new version of an implementation of the same protocol, deployed for a single instances of usage (e.g. a domain), it's basically one or the other. You can run Apache 2.0 on www.test-site.example.com while Apache 1.3 still runs www.example.com. But you can't have www.example.com running both very easily.
One of the reasons CF won't be practical is that each machine will be in a separate customer location, and upgrades will be distributed by sending a replacement media to each location. At a few pennies per CDR this is practical. Mini-CD media is nearly as cheap these days. CF is nowhere as close. With CF now I have to arrange to have the old media shipped back. I'm better off with full size CD drives than with CF.
Aside from the fact that the custodian of the information certainly has a lot to blame in this, there is another big part of the problem. That problem is what people can actually do with the information.
An SSN is identity. It is nothing more than that. The problem is people make the incorrect assumption that it is authenticity (I can recite the number, or read it off a little card in my wallet, so it must be me), and authority (this account has your SSN and is overdrawn, so you are liable for it).
If any law change is needed, it is a law change that says that it is illegal for an SSN to be accepted for any purpose other than identity. What that means is that if I walk into a bank and open an account citing some SSN, the bank needs to understand that all this does is identify someone, and not necessarily me. If the bank causes harm to the real owner of the SSN by having provided any derogatory credit information based on that SSN, then the bank shall be fully liable for having not taking reasonable measures to ensure accuracy of information. And by that, what I mean is that the bank can't simply say that the victim needs to track down the perpetrator to cover the costs. The banks need to be forced to properly authenticate the information they use, especially when and where it might be used in a negative way.
And I don't mean to pick on banks (I just happen to have an open case with Chase Manhattan bank which continues to allow someone to operate a credit card account with my SSN, reported on my credit reports, without my consent, and after I have advised them of the fraud). Such a law should apply to anyone and everyone who accepts and uses SSN data for anything. It's the negative things that can be done (like bad credit info) that needs to be stopped (in addition to other stupidities like running computers insecurely and connecting systems to the internet that have no business being there).
My younger brother's SSN is actually immediately prior to my own. Yet we were born 3 states away from each other (and 2 years apart, too). So the parent post is correct. The probability of being born in the associated state is high, and higher with younger people, but is not a certainty. And as the numbers are used up, they may even change the scheme to assign them. Maybe they should now.
I've filled out the full size bays in quite a number of machines I have, and most still have floppy size bays available. I could put a floppy or zip drive in there, but a floppy is way too tight to build the rescue disk system I need to have (because it has more software than can ever fit on a floppy ... it's about 32MB in size). I've tried Zip drives, but all three I've used turn out to be regularly unreliable (I can coax them to work, but this isn't the kind of thing I want to put in customer locations). Maybe it's the media, but either way, the Zip drive option isn't where I want to go.
A small mini-CD drive that fits in the floppy drive bay would be ideal. Such a product would also let us start downsizing computer cases in a lot of new ways for the special purposes that don't need large amounts of CD data (such as firewalls and specialized mini-servers).
I have 3 X servers running on my desktop, on vt10, vt11, and vt12. And on top of that I have 60 text virtual consoles, vt1-vt9 and vt13-vt63. And yes, every one of them is in use. I've changed the keyboard mapping around so that ALT+key switches VT where key is just about every key on the main part of the keyboard. For example, ALT+1 is vt14, ALT+tab is vt28, ALT+/ is vt61, ALT+space is vt62 and ALT+ESC is vt63.
Having multiple X servers running does allow me to switch between different window managers without messing up what I'm already doing. I have my own customized fvwm based environment on :0, a stock Gnome setup on :1, and a stock KDE setup on :2 (logged in under different userids).
BTW, the virtual consoles do work on SUN Sparc machines when running Linux on them. There's nothing particular about the hardware to implement virtual consoles. They just happen to be text in graphics mode on SUN Sparc, much as they would on x86 if you used frame buffer mode (that's apparently what's happening on the SUN Sparc machines).
As an example of just how hard it is to identify, consider the case of a bulk mailer that supplements its list of 5,000 local people who have requested information on the product with a purchased list of 495,000 email addresses known to be in the same city and surrounding area. So they send out the big mailing to 500,000 people. It's the same exact content to everyone. There's the usual sell wording followed by the URL to the web page to opt-in and opt-out or refine your mailing choices.
Is this spam?
To many people it will be, because it is most certainly unsolicited, and also bulk. To others it won't be because they know they asked for it, they are interested in it, and they may never realize it's bulk (they only got one copy because they only have one email address).
To detect if it is spam or not involves more than just the content of the mail; it also involves the intentions and/or actions of the recipient.
Barry Shein's proprosal may well cause this mailer to not add those 495,000 other addresses due to the cost. That would probably be a good thing. And I see merits to his idea, as well as problems.
His idea may also mean that the mailing to the 5,000 people that requested it also cannot be done. Many organizations, such as charities, but also including small scale businesses, simply cannot afford that, especially if the mailing is something that isn't really meant to bring in new business, but to just be informative about ongoing events. If there was a way to allow such groups to send their mail, anyway, Barry Shein's idea might work. OTOH, that would also result in spammers trying fit themselves into such ways, too.
I propose that all spam be totally outlawed with the following exceptions:
Of course there is the problem of a legal definition of spam. Certainly everything that is bulk and unsolicited should be considered spam.
The first thing you assume is that your first sentence is what gave the first idea. That's not true. I didn't get a "first idea" until after I read the whole thing. It's clear our thought processes are very different. I no longer see any point it in this. Perhaps it is the case that your wording has only one possible way to understand it the way you think. I saw several meanings. I'm sorry you spent so much time writing a response, but I feel no value in reading the rest of it.