It's been a while since I followed bugtraq/NTbugtraq. Does Microsoft still charge people $90 (up front -- but supposedly refundable) if they want to report a security bug?
If they are, then I can see why researchers aren't playing their silly game, especially if they discover several bugs. Further, Microsoft is giving up a small advantage they could have over open source. If they allowed non-public reporting of security bugs, then they could have that information before the crackers get it, while open source bugs are generally reported to open developer lists.
Perhaps I'm showing grave naivete, but it seems like it would be better
to treat accents (dots, slashes and stuff) like case. DNS names are case
insensitive, but case preserving. So, you can type all your fancy European characters if you want, but you don't have to mess with them if you're on a keyboard where that's difficult, and there's no additional opportunity for squatting or visual name hijacking. Naturally, you would want the accents
to appear on reverse lookups (just like mixed case domain names work.)
I know there are times when differnet accents sometimes indicate different
words -- but I'm under the impression that it is unlikely that more than one
of them would be a "good" domain name. (Am I wrong about that?)
This won't work for non-latin characters, obviously. But UTF-8 seems like a better solution to that. (I understand that most chineese words are 2-3 characters of 2-3 bytes (unified is U-430 to U-9fa and upto U-7ff is 2 characters) for 4-9 bytes -- clearly less than 63 bytes) The obvious downside is that it means that all DNS servers and resolvers must (at least!) be 8-bit clean.
As many have stated, the Internet is less resiliant than POTS. I don't know if it is more reliable than the power grids, though.
The internet doesn't seem to have any cascading failure modes. Inter-router links tend to be much larger than any traffic that could go through them. TCP will backoff automatically if a path becomes bandwidth-constrained. Even routing loops will only affect a few paths, and tend to be corrected fairly quickly.
The internet does have other systemic failures, though. Worms and DDOS can break all or any part of it, by simply overloading it with traffic. For other infastructure, there might be an equivlent to DDOS (eg, super bowl flush), but nothing like a worm.
Looking at SMTP as a security solution leads one to try to understand what security policty the SMTP server needs to implement. Before spam, it was "anyone on the internet can append email to my mailbox, but only I can read and delete the email." Now, we're trying to implement "anyone who is not a spammer can append anything that is not spam to my mailbox, but only I can read and delete the email." That's harder, because we have to define spammers (ussually with DNSbls) and spam (with baysian and other filters).
Some users try to make their email addresses "secret" like a key. This works for some, but not for others. This is essentially implementing "People who know my address can append emails to my inbox, but only I can read and delete." The address is essentially a plain-text password, which is shared by all of one's corispondants.
Compairing this to the car lock, I think you can see why the analogy breaks down. The security policy for a car door is "only the owner or somone with the owner's premission may enter." This is accomplished through a key (brass or radio). It can be broken by a determined theif, but is ussually sufficient to make it not worth the risk of being caught. The lock mostly works because it has a simple security policy and there's serious consequences for even trying.
I think the "anyone may append" property of email is a big part of what makes it successful. Managing a list of "who may email whom" is an N-squared problem, so any AAA is unlikely in any protocol. I could imagine ways to allow email only from humans, but that breaks mailing lists and other useful things. There might be useful ways to modify and/or replace SMTP, but I think that "anyone may append" is both needed for the usefulness of email, and sufficient for spammers to abuse.
If we want to solve the spam problem without breaking the usefulness of email, I think we need to use all of the tools we can. We have to make it technically hard to spam. We need to educate users to never buy anything from spam, and we need to have serious consequences for anyone who tries.
Infancy: The worm starts from one computer, and begins to spread.
Adult: The worm has tried all 2^32 addresses in the IPv4 internet. The worm continues to spread, however, as machines come and go, and may "leak" into networks not directly connected to the Internet.
Lingering: Patches are availible and national news covers the story, so everyone knows they need to update their machines, and almost everyone does. A few leftover machines (unadministered, presumably?) keep the worm alive, though. It continues to infect forever, unless the worm suicides (and the suicide works) as long-dormant machines re-connect to the internet, or are re-installed from media of old OSes.
Counterattacks are generally not developed fast enough to deploy in the infancy phase, when they might actually be useful in giving admins a little more time to patch. Slowing the spread of a worm might be done just as effectively with standard tar-pit/sticky honey-pot methods.
Once worm reaches the adult phase (which could be literally miniutes) then all the systems on the Internet that can be infected are already infected. What point could the counterattack have? Sure, it's fun. But it's not a defensive measure (You're either immune, or already infected.) It uses more bandwidth than it saves. Dealing with counterattacks will divert the time and attention of admins from patching -- which is what they need to be doing.
Counterattacks in the lingering stange may seem tempting, especially as one looks at logs and sees evidence of year-old worms, still in the wild. Surely, no machine should be connected to the Internet while being unmaintained this long, right? I suggest, however, that the cost of these attempts is pretty small, and the potential cost of an attack is pretty big (and a self-replicating attack, even bigger!) If you really want to help, email or telephone some domain or netblock contacts, and/or their upstream ISP.
So, I don't see any real benifit from counterattacks, no matter how well intentioned. The "patch treadmill" is a terrible way of securing our Internet infastructure. Unfortunatly, it's also the only way we have, right now.
My opinion:
A "linux specialist" has most likely submitted at least one patch to at least one open source project. Even if this isn't a big flashy bit, it still requires knowing what pieces are doing what to know what needs patching, and then some coding skills to write the patch. This is then peer-reviewed before being accepted into the project. Even if they don't have coding skills, documentation authors/contributors also show a reasonable depth of knowlage. If you want to hire someone who knows something, ask them where their name can be found.
It seems to me that, if AT&T wanted a list of mailservers which send them email, they would probably start with their own maillogs. That is going to be much more complete, and they won't sound as stupid to all their contacts.
Even if they did come up with a complete and accurate list of non-spammer mailservers, they still need a way to continiously update it. What would they want? Everyone in the world sending them email whenever a mailserver comes or goes? (oops, no... because the new server wouldn't be on the list either.)
AT&T cannot be this stupid.
I have to think that this is a hoax. The long message vouching for the credibility of the earlier, terse message supports this idea.
It's not so much that you don't have a door, but that if your door is a cheap particle-board one (that is only usefull for keeping honest people out) and some punk puts his shoulder through it, then yes, the punk is responsible for the cost of a steel (shoulder-proof) door. After all, if there were no shoulder-punks, the cheaper door would be good enough.
So it is with software patching. Not very long ago, you could patch a system once every three months or so. Now, a windows system more than 2 weeks behind in patches is no longer networthy. A tiny part of that is microsoft's fault (they make insecure software out of cheapness), but most of the blame goes to the people who intentionally break into other people's computers. If malware-writers/users found another hobby, we wouldn't need to patch our systems once a week.
That said, I don't recomend letting your system remain unpatched or leaving your front door stand open -- Everyone has a responsiblilty to prevent what crime they reasonably can.
There's no need for a flat file.
We can fix that if DNSBL users do zone transfers. I know some operators are nervous about legal issues with that (and I'm completly ignorant of what those issues are), but this is a simple technical fix for lots of DDOS attacks. DNS servers automatically update their slave zones periodically, so I don't think there would be much trouble with people not updating them like they should. The bandwidth required for a TCP zone transfer is more than a few UDP quries, but no server should have to do more than one transfer in each refresh interval (eg, a few hours to a day) so this would save bandwidth for servers that do lots of queries.
The original MAPS RBL is also availible as a BGP feed. Most people find this too painful (especially when MAPS and Tier-1 ISPs are slugging things out) but maybe a return to something like that would be the next step if DNSBLs become unworkable.
Another, possibly random thought: If the FBI told the victims of DDOS attacks to go away, and it later turned out that this was the lead they needed to find the authors of some virus/worms.... would heads roll? Policies be changed? It seems that, if they find fraudsters and emezlers by following the money, they should be following the zombies to find out who wrote the worm.
Okay, I'm clueless on this... DSM seems like an obvious solution for short-term (few miniutes) shortages, but I don't think people want their large-load appliances to stop working just because the power company decided they could make more if we didn't use them today. Maybe it would have to be more fine-grained than "shut off now" but more like "increase AC thermostats 3 degrees." Anyway, how are the air conditioner, electric heater and other big loads (and the power meter) supposed to "know" when to conserve? Would the power company send some signal? Or would they just use voltage/frequency of the lines?
At a bigger scale, I kept thinking, as I read the report, that the grid needs a "smarter" way of isolating itself. Relays that turn off lines and generators based on only local information can act like dominoes. They protect infrastructure from damage, but the emergent property is that, when the grid gets unhealty, it all shuts down. It seems like it would be better for a computer to decide (for example) that Ohio is going out, so everyone disconnect them at the same time, to save the rest of the grid from whatever is wrong there. (I guess politics aren't going to allow that, though.) Another way might be for computers to be working to find the "islands" that have ballanced generation and load, then make the relays at the edges of the islands more sensitive, and within the island less sensitive. That would allow more (and larger?) islands to remain with power, if the grid were to get unstable. It would also be a major motovation against NIMBYism. (I remember that the Bush Energy Policy noted that NYC needed a lot more power generation within the city. I wonder if any has been built.)
We've seen people do time-of-day based conservation in California and in Oregon,you can get a special power meter that will charge differently based on different times of day. That's a step away from "one rate" billing, but I don't see how that could help prevent or contain major power outages.
Out of curiosity, how much would DSM cost? If it's more than the cost of conservation, then it's easy to see why it never goes anywhere -- because more efficient appliances shed load every day, not just when the grid is unstable.
I think a better solution is that mail servers need to be scanning mails for viruses. It's easier to keep a mail server's scanner up to date than 1000s of peecees, and users don't have the option of turning mailserver's scanners off if it seems too slow. Email isn't the only infection vector (so scanning on email servers can't be the only protection) but it's a good place, I think, to practice defence-in-depth.
If users were forced to move to p2p for file exchange, or running their own servers, then centralised scanning becomes impossible. Users who want to give a file to only one other person then have to come up with some kind of authentication, which they rarely think much about or implement well. (email isn't really good for this either, but it's "close enough" and intuitive for the user.)
I realize unix/linux users enjoy smugly ignoring virus emails, but one of my servers (with 3500 users) blocked about 7GB of viruses this month. Lots of my users were never vunerable because they don't use windows. Most have antivirus software on their client machines. A few would have been vunerable, but now had more time to get their anti-virus software installed and updated. Those that were not vunerable saved much wear on their delete keys. Obviously, it would have been less work for my server if all (or most) MTAs were scanning & blocking. (I feel like I should have done this a long time ago, but I think the last two weeks should convince anyone who hasn't that this is a good idea.)
--David Burns
Problem definition?
on
Replacing SMTP?
·
· Score: 2, Insightful
SMTP has some problems (HELO / EHLO for "advanced" features, etc) but it still solves the basic problem of letting anyone on the internet append a message to my mailspool. If you want a new protocol to implement a "more secure" version of that, you'll have to define a security policy which is "more secure" than "anyone may append."
The simplest such policy is a whitelist -- but this means you can't just give your email address to a friend, and expect her to be able to send you mail. It means that if your friends change email addresses, they can't just send you email saying "This is my new address -- my old ISP stinks!"
A more complex policy might include some public key infrastrucure, where a user needs to have a valid key to sign their messages, in order to send mail. This brings up "who do you trust" in terms of who can sign message-signing keys, but more importaintly, who is going to have more trouble with this, a spammer that wants 100 throw-away accounts with keys per week, or someone's Mom who just wants to type a message and click "send?"
I think that it will be little use in trying to come up with a protocol solution to spam, without first defining what security policy you need to enforce. Once you do that, you can design exactly what you need to make your new policy work. (You might even find that SMTP is not at fault -- you might just need a layer above that transport to secure your mailbox.)
This would proove, beyond a shadow of a doubt, that life on earth could have stemmed from the same methods. Really, the implications are astounding.
If life simular to that on Earth were found on Mars, it wouldn't prove anything, but would be strong evidence that one of two things happend: 1. Life started somewhere, and moved between planets (metiors or viking spacecraft); or 2. As you suggest, life in both places came to be for the same reason. Either multi-celled organisms "adapted" to life on Mars, or God created multi-celled organisms on Mars -- I don't think your theoretical discovery would favor either of those theories over the other.
I'm curious why you suppose that a creationist (like myself) would have a problem with creation happening in more than one place? If God created Mars and Earth (and every thing else that is not "formless and void") and God created life on Earth, then why would it be hard for Him to create life on Mars? (or anywhere else?)
If you begin with the assumption that you can explain the universe without any supernatual intervention, then evolutionary theory fits most of the data pretty well (better than anything else.) If you don't begin with that assumption, and also have "evidence of things unseen" (which, by neccesity, is unscientific) then the origins question becomes a theological question, rather than a scientific one. If you want to know the truth, I think you need to consider both, and that is going to make the question harder.
If I recall that passage correctly (sorry, I'm too lazy to look it up), the measurement was done with a rod, which had a length equal to the radius of the circle. This means that what was really measured was a hexagon inscribed within the circle. (Of course, a hexagon's perimeter is 3 times longer than its diameter.)
As far as I am aware, the Bible is silent on the value of Pi.
I was suggesting that the server should take your prefernce into account, and send (.3)y audio and (.7)y video, or send (.5)y audio and (.5)y video. That is, you would want the sending server to compress the audio & video to different bitrates for you.
What probably will not work is for the server to send you 1.25y of audio and video, and have "the network" somehow drop only the right packets to give you what you want.
I think what you really want is both, scaled for the bandwidth you have
availible. Sure, you might want to tweak the quality of audio and video streams for different applications, and you could hope that the server could dynamically discover the bandwidth availible to you. If you aren't trying to use more bandwith than you have (and there aren't other more interesting problems) you should not be seeing much packet loss, and that should give you audio and video results of quality fitting the bandwidth used.
For a TCP protocol, that just means you need enough buffer space to deal with any occasional loss that might occur (enough time to deal with timouts and re-transmits). For a UDP protocol, that means the codec needs to be smart enough to deal with some loss (graceful degradation).
Both linked articles were pretty content-free. I'm trying to read between the lines and figure out what they're really doing. The article seems to imply that this is only a change on the TCP sender's side, not clien TCP stacks or anything in between.
Maybe they're measuring the round-trip delay, and then sending more data than can fit in the reciver's window, on the assumption that ACKs "should be" in flight. Maybe they also notice when an ACK is overdue, and send a duplicate packet early,
rather than wait for the normal timeout or a duplicate ACK of earlier data. If they do that, then the duplicate would come 1 RTT after the original, and the reciever's window would be full of after-loss data (so it would catch up right away.) I suppose they could assume that only one packet would be lost, and send another window-full of data after that, before recieving an ACK. (If that assumption was wrong, then that data would be lost and bandwidth wasted.)... but that's all just guessing.
I do hope that there is something to this (in spite of the fluff of these articles.) We're kindof stuck in terms of throughput with TCP right now.
TCP throughput <= (TCP window size)/(Round-trip-delay) TCP throughput <= 9.8 * (MSS -- smalest MTU in the path) / sqrt(loss) / (Round-trip-delay)
The former inequality is reasonably easy to fix -- make bigger windows (and buffers). The latter is harder. 9.8 is a constant (I don't know where it comes from, but that value is often quoted, and seems to work out in my experience.) It would be great to fix MSS, but lots of hardware won't support more than 1500 bytes, and nobody benifits from this until everybody upgrades, so nobody upgrades. For fast links, RTT is mostly determined by the speed of light./* Insert C increase petition joke here. */ loss can be fixed if it's really bad (e.g., duplex mismatches), but if you've already got 4-nines, getting two more for that 10X TCP improvement is really hard.
I'm planning to roll out IPv6 support in my networks this summer. This means that nodes that are capable will have routable IPv6 addresses. This means routers that can support it in hardware (we're due for upgrades anyway), and basic services starting with DNS. We'll try to move as many services as we can to availabilty on both stacks.
I'm guessing 1/4 to 1/2 of our nodes will support it, and maybe 1-5% of offsite traffic will be IPv6. (But those are just my wild guesses.)
It is importaint to note that IPv4 will not be going away anytime soon. I don't even see any IPv6-only nodes in the immediate future. I don't see the end of IPv4 globally routable addresses any time soon, and local IPv4 will probably outlast most of our careers.
Yes, enforcability is going to be a big problem here.
Even if people weren't discouraged from sending legit emails (your example is one where people would be!), $0.01 per email is not enough to cover the cost of counting the number of emails people send, even if everybody played fairly. Spammers probably aren't going to play fairly. They will deliver their spam, and either try to make it tax-free, or put it on somone else's bill. (they already forge return addresses so others have to deal with bounces and comlaints.)
Another problem with this is that it will appear to legitimise tax-paying spammers. Even with the $0.01 tax, it's still a lot cheaper than paper mail, and so spammers will try to take advantage of that. But the recipients don't get that $0.01, while they (and their ISPs) are using resources to deal with the spam.
I still think that the solution to spam requires three parts:
Make unsolicited bulk email illegal (like fax-spam). This means that a spammer has a real cost to deal with for even trying to spam.
Filter as much as reasonably possible. This means most spam won't get through.
Never buy from a spammer, even if they sell what you want.
You wouldn't need nanobots to do this. Macro-bots could do just as well. This would be especially interesting if the macro-bots knew what pieces they themselves were made from, and could collect those pieces and replicate themselves.
I have suspected for some time that lots of spam gets sent to people who
send (or recive) lots of forwards. This is the only explaination I can think of for some of the spam I've seen to some "private" (given only to friends) addresses. This implies, I suppose, that some friends, or friends of friends, or their friends are giving my address to spammers.
They also didn't test viruses as a method of address-harvesting. (Viruses like Klez that send mail to random people with forged From: addresses.) I have no clue how much spam comes from this, but it would be very interesting to know.
I note also that this study didn't include any control to compare results to "real" addresses that get used for lots of things, so maybe there is some other method that spammers use, that also wasn't tracked. Six months might be too short of a time. I know I get mail to new@walt (walt is a machine that had a usenet server on it during the mid-ninteties), so old email addresses, once harvested, get on CDROMS and keep getting hit forever.
These are generally in/usr/local/share/spamassassin/* (in this case,
20_head_tests.cf)
To =~/undisclosed[_ ]*recipient(?:s[^:]|[^s])/i
A quick grep through my spam folder shows that this test really does
help track a lot of spam. (What I don't understand, is why spammers are
so consitant in their errors.)
If you get a lot of legit mail with undisclosed recipients in the headers, you
might write a test for that (which probably looks different from the fakes)
and submit it to the project. (Or, use SA 2.5, which used Baysian Filtering.)
Now you'd have to watch for asteroids passing near any of the L1 / L2 (maybe L3, too? The article doesn't mention it, though, and it would be hard to observe) points of Earth-Sun, in addition to just watching what comes near the Earth/moon system itself.
Slashdot Mirror
If they are, then I can see why researchers aren't playing their silly game, especially if they discover several bugs. Further, Microsoft is giving up a small advantage they could have over open source. If they allowed non-public reporting of security bugs, then they could have that information before the crackers get it, while open source bugs are generally reported to open developer lists.
Erm... Yes, you're right -- my error. (I was only looking at the top of the table at unicode.org, which leaves me missing one hex digit.)
I know there are times when differnet accents sometimes indicate different words -- but I'm under the impression that it is unlikely that more than one of them would be a "good" domain name. (Am I wrong about that?)
This won't work for non-latin characters, obviously. But UTF-8 seems like a better solution to that. (I understand that most chineese words are 2-3 characters of 2-3 bytes (unified is U-430 to U-9fa and upto U-7ff is 2 characters) for 4-9 bytes -- clearly less than 63 bytes) The obvious downside is that it means that all DNS servers and resolvers must (at least!) be 8-bit clean.
The internet doesn't seem to have any cascading failure modes. Inter-router links tend to be much larger than any traffic that could go through them. TCP will backoff automatically if a path becomes bandwidth-constrained. Even routing loops will only affect a few paths, and tend to be corrected fairly quickly.
The internet does have other systemic failures, though. Worms and DDOS can break all or any part of it, by simply overloading it with traffic. For other infastructure, there might be an equivlent to DDOS (eg, super bowl flush), but nothing like a worm.
Some users try to make their email addresses "secret" like a key. This works for some, but not for others. This is essentially implementing "People who know my address can append emails to my inbox, but only I can read and delete." The address is essentially a plain-text password, which is shared by all of one's corispondants.
Compairing this to the car lock, I think you can see why the analogy breaks down. The security policy for a car door is "only the owner or somone with the owner's premission may enter." This is accomplished through a key (brass or radio). It can be broken by a determined theif, but is ussually sufficient to make it not worth the risk of being caught. The lock mostly works because it has a simple security policy and there's serious consequences for even trying.
I think the "anyone may append" property of email is a big part of what makes it successful. Managing a list of "who may email whom" is an N-squared problem, so any AAA is unlikely in any protocol. I could imagine ways to allow email only from humans, but that breaks mailing lists and other useful things. There might be useful ways to modify and/or replace SMTP, but I think that "anyone may append" is both needed for the usefulness of email, and sufficient for spammers to abuse.
If we want to solve the spam problem without breaking the usefulness of email, I think we need to use all of the tools we can. We have to make it technically hard to spam. We need to educate users to never buy anything from spam, and we need to have serious consequences for anyone who tries.
- Infancy: The worm starts from one computer, and begins to spread.
- Adult: The worm has tried all 2^32 addresses in the IPv4 internet. The worm continues to spread, however, as machines come and go, and may "leak" into networks not directly connected to the Internet.
- Lingering: Patches are availible and national news covers the story, so everyone knows they need to update their machines, and almost everyone does. A few leftover machines (unadministered, presumably?) keep the worm alive, though. It continues to infect forever, unless the worm suicides (and the suicide works) as long-dormant machines re-connect to the internet, or are re-installed from media of old OSes.
Counterattacks are generally not developed fast enough to deploy in the infancy phase, when they might actually be useful in giving admins a little more time to patch. Slowing the spread of a worm might be done just as effectively with standard tar-pit/sticky honey-pot methods.Once worm reaches the adult phase (which could be literally miniutes) then all the systems on the Internet that can be infected are already infected. What point could the counterattack have? Sure, it's fun. But it's not a defensive measure (You're either immune, or already infected.) It uses more bandwidth than it saves. Dealing with counterattacks will divert the time and attention of admins from patching -- which is what they need to be doing.
Counterattacks in the lingering stange may seem tempting, especially as one looks at logs and sees evidence of year-old worms, still in the wild. Surely, no machine should be connected to the Internet while being unmaintained this long, right? I suggest, however, that the cost of these attempts is pretty small, and the potential cost of an attack is pretty big (and a self-replicating attack, even bigger!) If you really want to help, email or telephone some domain or netblock contacts, and/or their upstream ISP.
So, I don't see any real benifit from counterattacks, no matter how well intentioned. The "patch treadmill" is a terrible way of securing our Internet infastructure. Unfortunatly, it's also the only way we have, right now.
My opinion:
A "linux specialist" has most likely submitted at least one patch to at least one open source project. Even if this isn't a big flashy bit, it still requires knowing what pieces are doing what to know what needs patching, and then some coding skills to write the patch. This is then peer-reviewed before being accepted into the project. Even if they don't have coding skills, documentation authors/contributors also show a reasonable depth of knowlage. If you want to hire someone who knows something, ask them where their name can be found.
Even if they did come up with a complete and accurate list of non-spammer mailservers, they still need a way to continiously update it. What would they want? Everyone in the world sending them email whenever a mailserver comes or goes? (oops, no... because the new server wouldn't be on the list either.)
AT&T cannot be this stupid. I have to think that this is a hoax. The long message vouching for the credibility of the earlier, terse message supports this idea.
So it is with software patching. Not very long ago, you could patch a system once every three months or so. Now, a windows system more than 2 weeks behind in patches is no longer networthy. A tiny part of that is microsoft's fault (they make insecure software out of cheapness), but most of the blame goes to the people who intentionally break into other people's computers. If malware-writers/users found another hobby, we wouldn't need to patch our systems once a week.
That said, I don't recomend letting your system remain unpatched or leaving your front door stand open -- Everyone has a responsiblilty to prevent what crime they reasonably can.
The original MAPS RBL is also availible as a BGP feed. Most people find this too painful (especially when MAPS and Tier-1 ISPs are slugging things out) but maybe a return to something like that would be the next step if DNSBLs become unworkable.
Another, possibly random thought: If the FBI told the victims of DDOS attacks to go away, and it later turned out that this was the lead they needed to find the authors of some virus/worms.... would heads roll? Policies be changed? It seems that, if they find fraudsters and emezlers by following the money, they should be following the zombies to find out who wrote the worm.
At a bigger scale, I kept thinking, as I read the report, that the grid needs a "smarter" way of isolating itself. Relays that turn off lines and generators based on only local information can act like dominoes. They protect infrastructure from damage, but the emergent property is that, when the grid gets unhealty, it all shuts down. It seems like it would be better for a computer to decide (for example) that Ohio is going out, so everyone disconnect them at the same time, to save the rest of the grid from whatever is wrong there. (I guess politics aren't going to allow that, though.) Another way might be for computers to be working to find the "islands" that have ballanced generation and load, then make the relays at the edges of the islands more sensitive, and within the island less sensitive. That would allow more (and larger?) islands to remain with power, if the grid were to get unstable. It would also be a major motovation against NIMBYism. (I remember that the Bush Energy Policy noted that NYC needed a lot more power generation within the city. I wonder if any has been built.)
We've seen people do time-of-day based conservation in California and in Oregon,you can get a special power meter that will charge differently based on different times of day. That's a step away from "one rate" billing, but I don't see how that could help prevent or contain major power outages.
Out of curiosity, how much would DSM cost? If it's more than the cost of conservation, then it's easy to see why it never goes anywhere -- because more efficient appliances shed load every day, not just when the grid is unstable.
If users were forced to move to p2p for file exchange, or running their own servers, then centralised scanning becomes impossible. Users who want to give a file to only one other person then have to come up with some kind of authentication, which they rarely think much about or implement well. (email isn't really good for this either, but it's "close enough" and intuitive for the user.)
I realize unix/linux users enjoy smugly ignoring virus emails, but one of my servers (with 3500 users) blocked about 7GB of viruses this month. Lots of my users were never vunerable because they don't use windows. Most have antivirus software on their client machines. A few would have been vunerable, but now had more time to get their anti-virus software installed and updated. Those that were not vunerable saved much wear on their delete keys. Obviously, it would have been less work for my server if all (or most) MTAs were scanning & blocking. (I feel like I should have done this a long time ago, but I think the last two weeks should convince anyone who hasn't that this is a good idea.)
--David Burns
The simplest such policy is a whitelist -- but this means you can't just give your email address to a friend, and expect her to be able to send you mail. It means that if your friends change email addresses, they can't just send you email saying "This is my new address -- my old ISP stinks!"
A more complex policy might include some public key infrastrucure, where a user needs to have a valid key to sign their messages, in order to send mail. This brings up "who do you trust" in terms of who can sign message-signing keys, but more importaintly, who is going to have more trouble with this, a spammer that wants 100 throw-away accounts with keys per week, or someone's Mom who just wants to type a message and click "send?"
I think that it will be little use in trying to come up with a protocol solution to spam, without first defining what security policy you need to enforce. Once you do that, you can design exactly what you need to make your new policy work. (You might even find that SMTP is not at fault -- you might just need a layer above that transport to secure your mailbox.)
If life simular to that on Earth were found on Mars, it wouldn't prove anything, but would be strong evidence that one of two things happend: 1. Life started somewhere, and moved between planets (metiors or viking spacecraft); or 2. As you suggest, life in both places came to be for the same reason. Either multi-celled organisms "adapted" to life on Mars, or God created multi-celled organisms on Mars -- I don't think your theoretical discovery would favor either of those theories over the other.
I'm curious why you suppose that a creationist (like myself) would have a problem with creation happening in more than one place? If God created Mars and Earth (and every thing else that is not "formless and void") and God created life on Earth, then why would it be hard for Him to create life on Mars? (or anywhere else?)
If you begin with the assumption that you can explain the universe without any supernatual intervention, then evolutionary theory fits most of the data pretty well (better than anything else.) If you don't begin with that assumption, and also have "evidence of things unseen" (which, by neccesity, is unscientific) then the origins question becomes a theological question, rather than a scientific one. If you want to know the truth, I think you need to consider both, and that is going to make the question harder.
As far as I am aware, the Bible is silent on the value of Pi.
What probably will not work is for the server to send you 1.25y of audio and video, and have "the network" somehow drop only the right packets to give you what you want.
I'm sorry that my previous post was unclear.
For a TCP protocol, that just means you need enough buffer space to deal with any occasional loss that might occur (enough time to deal with timouts and re-transmits). For a UDP protocol, that means the codec needs to be smart enough to deal with some loss (graceful degradation).
Maybe they're measuring the round-trip delay, and then sending more data than can fit in the reciver's window, on the assumption that ACKs "should be" in flight. Maybe they also notice when an ACK is overdue, and send a duplicate packet early, rather than wait for the normal timeout or a duplicate ACK of earlier data. If they do that, then the duplicate would come 1 RTT after the original, and the reciever's window would be full of after-loss data (so it would catch up right away.) I suppose they could assume that only one packet would be lost, and send another window-full of data after that, before recieving an ACK. (If that assumption was wrong, then that data would be lost and bandwidth wasted.) ... but that's all just guessing.
I do hope that there is something to this (in spite of the fluff of these articles.) We're kindof stuck in terms of throughput with TCP right now.
The former inequality is reasonably easy to fix -- make bigger windows (and buffers). The latter is harder. 9.8 is a constant (I don't know where it comes from, but that value is often quoted, and seems to work out in my experience.) It would be great to fix MSS, but lots of hardware won't support more than 1500 bytes, and nobody benifits from this until everybody upgrades, so nobody upgrades. For fast links, RTT is mostly determined by the speed of light.The same "capture the ram" process could be used to capture disk images, including swap/paging space.
I'm planning to roll out IPv6 support in my networks this summer. This means that nodes that are capable will have routable IPv6 addresses. This means routers that can support it in hardware (we're due for upgrades anyway), and basic services starting with DNS. We'll try to move as many services as we can to availabilty on both stacks.
I'm guessing 1/4 to 1/2 of our nodes will support it, and maybe 1-5% of offsite traffic will be IPv6. (But those are just my wild guesses.)
It is importaint to note that IPv4 will not be going away anytime soon. I don't even see any IPv6-only nodes in the immediate future. I don't see the end of IPv4 globally routable addresses any time soon, and local IPv4 will probably outlast most of our careers.
Even if people weren't discouraged from sending legit emails (your example is one where people would be!), $0.01 per email is not enough to cover the cost of counting the number of emails people send, even if everybody played fairly. Spammers probably aren't going to play fairly. They will deliver their spam, and either try to make it tax-free, or put it on somone else's bill. (they already forge return addresses so others have to deal with bounces and comlaints.)
Another problem with this is that it will appear to legitimise tax-paying spammers. Even with the $0.01 tax, it's still a lot cheaper than paper mail, and so spammers will try to take advantage of that. But the recipients don't get that $0.01, while they (and their ISPs) are using resources to deal with the spam.
I still think that the solution to spam requires three parts:
You wouldn't need nanobots to do this. Macro-bots could do just as well. This would be especially interesting if the macro-bots knew what pieces they themselves were made from, and could collect those pieces and replicate themselves.
I have suspected for some time that lots of spam gets sent to people who send (or recive) lots of forwards. This is the only explaination I can think of for some of the spam I've seen to some "private" (given only to friends) addresses. This implies, I suppose, that some friends, or friends of friends, or their friends are giving my address to spammers.
They also didn't test viruses as a method of address-harvesting. (Viruses like Klez that send mail to random people with forged From: addresses.) I have no clue how much spam comes from this, but it would be very interesting to know.
I note also that this study didn't include any control to compare results to "real" addresses that get used for lots of things, so maybe there is some other method that spammers use, that also wasn't tracked. Six months might be too short of a time. I know I get mail to new@walt (walt is a machine that had a usenet server on it during the mid-ninteties), so old email addresses, once harvested, get on CDROMS and keep getting hit forever.
To =~ /undisclosed[_ ]*recipient(?:s[^:]|[^s])/i
A quick grep through my spam folder shows that this test really does help track a lot of spam. (What I don't understand, is why spammers are so consitant in their errors.)
If you get a lot of legit mail with undisclosed recipients in the headers, you might write a test for that (which probably looks different from the fakes) and submit it to the project. (Or, use SA 2.5, which used Baysian Filtering.)
Now you'd have to watch for asteroids passing near any of the L1 / L2 (maybe L3, too? The article doesn't mention it, though, and it would be hard to observe) points of Earth-Sun, in addition to just watching what comes near the Earth/moon system itself.