Human sperm can "survive" for about 48 hours at body temp. -- where "survive" means they're still swimmers. Beyond that, they are viable (for lab impregnation) as long as they stay hydrated and uncontaminated (i.e. free of bacteria, mold, chemicals, etc.) [It's worth noting, your sperm is very likely contaminated by the time it gets out of you.] The actual genetic material will be (forensically) intact for years -- I'm not saying you could make a baby from it.
As for "stealing" sperm... she'd have to get the "sample" within a few hours for them to still be able to perform naturally. Using sperm from a used condom simply won't work... pretty much all condoms made these days contain spermacides.
Altering the contents of the packets -- "adding noise" -- is illegal. That constitutes a wire-tap.
And singling out VoIP traffic for specific losy traffic shaping is grounds to lose common carrier status. It's intentional action against very specific traffic for a competetive advantage. (I'm sure there are lawyers already drooling in anticipation of class action suits.)
(Btw, I recall one ISP being wacked over the head for doing this sort of shit. Mebtel in Mebane, NC.)
This might've been true decades ago. But it's very much not true today. The bundles various telco's are pokin' in the ground belong to them. They pay the complete cost for every millimeter of the cable. Local government doesn't pay them anything to do it -- in fact, they make money out of it from taxes and fees for access to right-of-way (which the government does own.)
It's regulated because it's a finite resource. There's only so much wire that can be run down the right-of-way before it's "full". And every additional thing buried there is a hazard to all the others... a ditch witch will slice right through water lines, gas lines, power lines, etc., etc. Every schmuck who wants to cannot run out and bury a cable. (or string one from a utility ["power"] pole.)
In every place that a municipality has even mentioned building their own *public* telecom infrastructure, teleco's have screamed bloody murder... and taken legal action to block it. If the government already owned the wire, why would they need to hang more?
Actually, there isn't a "backbone" anymore. Back when the NSF administered the Internet, there was a backbone -- the "top of the hill" from whence packets would flow back out to where they needed to go; if you didn't know what to do with a packet, you forwarded it to the next upstream hop towards the backbone. In today's Internet, there's no such thing. If you're connected behind UUNet and I'm connected behind Sprint, there has to be a connection between UUNet and Sprint or we cannot talk to each other. (As Tier 1 ISP's, they will not hand that traffic to a 3rd party -- i.e. a "transit" provider.) That's what made the Level3/Cogent thing such a damnedable mess.
(It's what makes the entire Internet a f'ing mess, IMO.)
It's not DOS that's spinning, it's that horribly written X-ADM admin.exe eating 200% of the CPU to do absolutely nothing. The program is old, but it's not so damned old that they cannot use more efficient methods than an open ended for(;;) loop.
Hah. I do BIOS upgrades from floppy images via memdisk -- part of ISOLinux. Don't try to boot Real DOS(tm). But all of the clone DOS's I've used have worked just fine.
I was dealing with the BS last night, as a matter of fact... Toshiba's Stratagy (DK and IVP8) voice mail systems are DOS based. The management application is also a [censored] DOS application. It is, in fact, so DOS I have to run it inside VMWare to get it to work correctly. And it CONSUMES the cpu -- it is a DOS app after all; it's supposed to have the whole machine to itself, right?
(I'm told they have an NT based VM, but it's buggy as all hell.)
A little company called ThinkNIC did the same thing with Linux. (they used a tiny mediagx system complete with a freakin' winmodem.) It'd likely take the same amount of work to build a linux image from scratch, but it'd be much easier to maintain once you had it in hand. (Seriously. Who makes DOS drivers anymore?)
Many of my machines can flash it's own BIOS. Yes, this is the "recovery" method, but it gets the job done without DOS. And all of my Tyan "server" hardware supports "Remote BIOS updates" -- serial transfer of the bios image.
And with a bit of hackery, the BIOS can be reprogrammed from most *NIX's.
Capchas don't solve anything. 90% of them are easily decoded by software. (Software made them, software can decode them.) And as others love to point out, there are ways to get actual people to decode them for you. [However, I've never seen actual evidence of one of the "pr0n traps".]
The only thing that appears to work is charging for new accounts. Yes, it's annoying. Yes, it will drive some, otherwise legit, people away (because they don't use online payment systems, etc., etc.) And yes, it's a hassle for the site. But, aside from stolen credit cards, there's no getting around it. (And very few spammers are willing to commit credit card fraud to increase their pagerank.)
What you're call a "value statement" is in fact resource efficiency. IPv4 address space is a finite, non-renewable resource. Once it's been divided up, there isn't anymore. Unlike an empty cookie jar, you cannot go to the store to get more.
They are using a resource that is very cheap and plentiful (address space on a/8 network) to avoid investing in complex address assignment schemes.
This is wrong in so many ways. First off, a/8 is not cheap; those companies are paying a huge wad of cash for that space. Second, that space is not "plentiful". That/8 is all they are going to get. Ever. There's no way they will be able to meet the (IANA) requirements for further address assignments. (without lying.) If they really do have a reason for using a/8 internally, there's a private/8 reserved for such applications. And lastly, a/8 is a huge amount of address space to manage. There will certainly be some form of "complex scheme" used to keep up with it. Whether that's anything from metasolv to a bunch of text files/spreadsheets, there's something tracking address assignments.
It is, again, very highly unlikely they have any real (read: IANA acceptable) need for 16 million world accessable IP addresses.
These companies would care no more about renumbering their networks than a town might care to renumber their street addresses...
Be careful of one's examples.... I'm 33 years old. My parent's house has been renumbered twice in my lifetime. (And no, it's hasn't moved an inch.) Just because most cities don't, doesn't mean none ever do. Renumbering houses is simple -- tell people their address is now Y instead of X and leave it to them to change the number on their box/house/etc.
(And btw, street addresses are calculated by linear distance from some reference point. What number a house gets depends on the location of the driveway, mailbox, and/or entryway. For example, if 3 houses are numbers 10, 20, and 30, then they're pretty much equidistant apart. This is a USPS mandate, btw.)
Companies care deeply about renumbering because IPv4 addressing isn't exactly as simple. Most computer users just aren't that bright when it comes to the network they use everyday. Getting them to change their address is an exercise in headache generation. In the places where DHCP handles the assignments, migration is quick and easy (and "self healing" if the lease times are low enough -- change the DHCP server Friday @ 5 and all the desktops will have new addresses by Monday morning.)
But, I'll grant you there's little point in renumbering an IPv4 network... Today. If the future is IPv6, then one's energy is better spent on moving forward. However, moving to IPv6 is significantly more involved than changing an address. In this, Y2K is a good parallel. With y2k, the problem was space; years were stored as 2 digits instead of 4. Everything that dealt with dates had to be re-tooled to deal with "00" being "2000" instead of "1900". That ended up requiring changes in numerous places: data structures, file formats, displays, conversions from the old 2 digit format, etc. The exact same thing is true of IPv4->IPv6. Every application with any IPv4 knowledge at all will need re-work. In the simplest cases (which are, sadly, few), recompiling the application will make it IPv6 capable. In all other cases, the application(s) will have to have sections rewritten to handle the increased size of the address field(s), printing IPv6 addresses, determining when to use IPv4 vs. IPv6, etc., etc.
But all this still comes down to a "chicken and the egg..." Nobody will want to use IPv6 until everyone is using IPv6. And there are lots of ("legacy") IPv4 networked gear out there that no longer has anyone supporting them to make them IPv6 capable. Don't expect people to run out to replace dozens of appliances, that honestly, aren't tha
Your contrived example is BS. All of these/8's have been allocated for years. The organizations holding them have had a decade to implement best practices and move away from such large, unnecessary utilizations of address space.
Your "underling" fails to mention how much that/8 is costing the company per year. NO ONE gets address space for free. Granted, for the companies holding/8's, the cost is down in the noise of the operational budget.
what do you do when you have your first merger with another company...
The same thing companies have been doing for YEARS... plan for it and build a migration plan. You seem to think mergers are a simple flip of a switch for people and machines alike. Such a notion is laughable. Renumbering every computer in both companies is simple in comparision to all the other tasks in consolidating two companies. In fact, there may be no need at all to renumber either network. NAT will handle private transformations, too.
Also worth noting is the possiblity of a company divesting into two or more independant companies. If they were built within one public network, breaking them up can be an even bigger mess. If they're using private addressing, the process is simple.
I've never been in a "major corporation" that didn't use private addressing internally. (And that includes at least one of those/8 hoarding bastards.) NAT at the firewalled perimeter handles their public addressing. At that point, changing providers and address ranges is rather simple and painless. AND, you end up needing far fewer globally unique, routable addresses.
There is no reason everything shouldn't have its own IP address.
And there's equally no reason why they should. Do you really need to ping the nerf darts on my desk?
why not just assign 1 phone number to each 10 desks and ask them to share...
Funny you mention it. While not sharing in the analog partyline sense, PBX's already do this very thing. How many extentions are there on your office phone system? 20, 50, 100? How many actual CO lines are there? 8, 20? It's very rare for a PBX to have one CO line for each extention. In fact, that's counter productive -- just put a damned POTS phone on each desk. (Telco's used to sell this as centrex service.)
Greedy certainly applies. Go ask one of them to return their address space in exchange for one more suitable to their network. Apple certainly has no need for that much address space. MIT? I think every other university on Earth is evidence they don't need a/8.
Most places/networks have more address space than they use (will ever use.) In my experience, this appears to be universal.
It's "not worth it" simply because of the greedy bastards hoarding those/8's. Let's see who is hoarding all that space... 003/8 - GE 004/8, 008/8, 046/8 - BBN 009/8 - IBM 015/8 - HP 016/8 - DEC 017/8 - Apple 018/8 - MIT 019/8 - Ford... 045/8 - Interop Show Network !!
And then there's the US GOVERNMENT with 8+/8's -- more if you count the number of big contractors holding/8's.
I've been preaching this for years. Client reported stats are not trustworthy -- they never have been. Unfortunately, lawyers and judges aren't the most technically savy people around.
This assumes perfect communications between all the peers and tracker. If a single update gets lost, then the numbers won't add up. It's far, FAR too likely for peers to be cut off from the tracker during their session. They'll continue to upload and download from any connected peers in the interim. And the tracker will continue to report them to new peers until they timeout (varies from tracker to tracker.)
Add into the mix the clients that find other peers away from the tracker (*cough*BitComet*cough*) [DHT, peer exchange, plugins, etc.] and this method falls on it's face.
There are just as many ways to detect cheating as there are ways to cheat. Unfortunately, none of them are completely free.
There are two problems with this... 1) you assume the client knows it's external IP address. In most cases, this simply isn't true. And it's not even necessary. 2) Broadcast discovery will only work if the clients are in the same subnet and/or the same broadcast domain (i.e. more than one subnet on the same cable.)
Btw, people already cheat using this method. One machine reports to the tracker while another on the local lan does not. They can move the same file between themselves hundreds of times and "legally" boost their reported stats. [It's really much more work than it's worth.]
It doesn't take any sniffing at all... just read the spec for the BT protocol. This is the same lameness as screaming Apache is vulnerable because I can use telnet to get a web page. (And I don't need ethereal's help doing it.)
This isn't a vulnerability; it's simply the way the protocol works. It doesn't take a client to act like one and send syntacically correct requests to a tracker. (In fact, that's how I test tracker code... with telnet and/or nc)
I will warning those wanting to "cheat" using this method... if you follow his instructions to the letter, you will be detectable like a road flare in a movie theater. (if anyone is actually looking.)
And such things are very Not Cheap(tm). Only the bean counters can say if it's a good investment against possible downtime. Lemme ask, how often has that backup SAN and off-site tape storage been of utility?
Of course, I've lived in a world where "uptime" and "reliability" aren't always absolutes... if one mail server is down and 1000 of those million users cannot get their mail, is that "down"? (answer: no. the 'system' is up; your mail is 'unavailable'.) And the number of nines is measured within "business hours" -- if the client uses the system between 8am-8pm, we could turn the datacenter off between 8pm-8am and still have "five nines". (maint. windows don't count as downtime.)
That's 99.983% reliability, btw. (People really need to get out pencil and paper to do their math 'cause they are getting everything wrong when they aren't looking at it.)
I said no such thing... There are indeed "plans" in place for failures. They don't involve dropping thousands of dollars on hardware and software that are not necessary. The fact that the system has been working for 2 years is proof it's not necessary.
If the server dies, move the drive(s) to another box. There's a mirrored set of drives inside there -- so a dead drive doesn't take the files with it. Linux/FreeBSD is very forgiving of being moved to wildly different base hardware; and any incompatabilities are quickly and easily corrected. Plus, the server is backed up to tape (as are a number of other systems), so at worst, one day of "stuff" would be lost. The entire cyrus/sendmail combination can be dropped on just about any system in the building (even inside a vmware if necessary.)
Btw, replication doesn't necessarly prevent replicating errors. The major downtime was due to a dbm error, so it would've happened on every box.
[The only "luck" part is that it's drives are still good. Unlike all the other machines...]
Slashdot Mirror
Human sperm can "survive" for about 48 hours at body temp. -- where "survive" means they're still swimmers. Beyond that, they are viable (for lab impregnation) as long as they stay hydrated and uncontaminated (i.e. free of bacteria, mold, chemicals, etc.) [It's worth noting, your sperm is very likely contaminated by the time it gets out of you.] The actual genetic material will be (forensically) intact for years -- I'm not saying you could make a baby from it.
As for "stealing" sperm... she'd have to get the "sample" within a few hours for them to still be able to perform naturally. Using sperm from a used condom simply won't work... pretty much all condoms made these days contain spermacides.
... with added noise...
Altering the contents of the packets -- "adding noise" -- is illegal. That constitutes a wire-tap.
And singling out VoIP traffic for specific losy traffic shaping is grounds to lose common carrier status. It's intentional action against very specific traffic for a competetive advantage. (I'm sure there are lawyers already drooling in anticipation of class action suits.)
(Btw, I recall one ISP being wacked over the head for doing this sort of shit. Mebtel in Mebane, NC.)
This might've been true decades ago. But it's very much not true today. The bundles various telco's are pokin' in the ground belong to them. They pay the complete cost for every millimeter of the cable. Local government doesn't pay them anything to do it -- in fact, they make money out of it from taxes and fees for access to right-of-way (which the government does own.)
It's regulated because it's a finite resource. There's only so much wire that can be run down the right-of-way before it's "full". And every additional thing buried there is a hazard to all the others... a ditch witch will slice right through water lines, gas lines, power lines, etc., etc. Every schmuck who wants to cannot run out and bury a cable. (or string one from a utility ["power"] pole.)
In every place that a municipality has even mentioned building their own *public* telecom infrastructure, teleco's have screamed bloody murder... and taken legal action to block it. If the government already owned the wire, why would they need to hang more?
Actually, there isn't a "backbone" anymore. Back when the NSF administered the Internet, there was a backbone -- the "top of the hill" from whence packets would flow back out to where they needed to go; if you didn't know what to do with a packet, you forwarded it to the next upstream hop towards the backbone. In today's Internet, there's no such thing. If you're connected behind UUNet and I'm connected behind Sprint, there has to be a connection between UUNet and Sprint or we cannot talk to each other. (As Tier 1 ISP's, they will not hand that traffic to a 3rd party -- i.e. a "transit" provider.) That's what made the Level3/Cogent thing such a damnedable mess.
(It's what makes the entire Internet a f'ing mess, IMO.)
It's not DOS that's spinning, it's that horribly written X-ADM admin.exe eating 200% of the CPU to do absolutely nothing. The program is old, but it's not so damned old that they cannot use more efficient methods than an open ended for(;;) loop.
Hah. I do BIOS upgrades from floppy images via memdisk -- part of ISOLinux. Don't try to boot Real DOS(tm). But all of the clone DOS's I've used have worked just fine.
(There's always USB floppies, too.)
Sadly. Yes, they do.
I was dealing with the BS last night, as a matter of fact... Toshiba's Stratagy (DK and IVP8) voice mail systems are DOS based. The management application is also a [censored] DOS application. It is, in fact, so DOS I have to run it inside VMWare to get it to work correctly. And it CONSUMES the cpu -- it is a DOS app after all; it's supposed to have the whole machine to itself, right?
(I'm told they have an NT based VM, but it's buggy as all hell.)
A little company called ThinkNIC did the same thing with Linux. (they used a tiny mediagx system complete with a freakin' winmodem.) It'd likely take the same amount of work to build a linux image from scratch, but it'd be much easier to maintain once you had it in hand. (Seriously. Who makes DOS drivers anymore?)
Many of my machines can flash it's own BIOS. Yes, this is the "recovery" method, but it gets the job done without DOS. And all of my Tyan "server" hardware supports "Remote BIOS updates" -- serial transfer of the bios image.
And with a bit of hackery, the BIOS can be reprogrammed from most *NIX's.
Capchas don't solve anything. 90% of them are easily decoded by software. (Software made them, software can decode them.) And as others love to point out, there are ways to get actual people to decode them for you. [However, I've never seen actual evidence of one of the "pr0n traps".]
The only thing that appears to work is charging for new accounts. Yes, it's annoying. Yes, it will drive some, otherwise legit, people away (because they don't use online payment systems, etc., etc.) And yes, it's a hassle for the site. But, aside from stolen credit cards, there's no getting around it. (And very few spammers are willing to commit credit card fraud to increase their pagerank.)
What you're call a "value statement" is in fact resource efficiency. IPv4 address space is a finite, non-renewable resource. Once it's been divided up, there isn't anymore. Unlike an empty cookie jar, you cannot go to the store to get more.
/8 network) to avoid investing in complex address assignment schemes.
/8 is not cheap; those companies are paying a huge wad of cash for that space. Second, that space is not "plentiful". That /8 is all they are going to get. Ever. There's no way they will be able to meet the (IANA) requirements for further address assignments. (without lying.) If they really do have a reason for using a /8 internally, there's a private /8 reserved for such applications. And lastly, a /8 is a huge amount of address space to manage. There will certainly be some form of "complex scheme" used to keep up with it. Whether that's anything from metasolv to a bunch of text files/spreadsheets, there's something tracking address assignments.
They are using a resource that is very cheap and plentiful (address space on a
This is wrong in so many ways. First off, a
It is, again, very highly unlikely they have any real (read: IANA acceptable) need for 16 million world accessable IP addresses.
These companies would care no more about renumbering their networks than a town might care to renumber their street addresses...
Be careful of one's examples.... I'm 33 years old. My parent's house has been renumbered twice in my lifetime. (And no, it's hasn't moved an inch.) Just because most cities don't, doesn't mean none ever do. Renumbering houses is simple -- tell people their address is now Y instead of X and leave it to them to change the number on their box/house/etc.
(And btw, street addresses are calculated by linear distance from some reference point. What number a house gets depends on the location of the driveway, mailbox, and/or entryway. For example, if 3 houses are numbers 10, 20, and 30, then they're pretty much equidistant apart. This is a USPS mandate, btw.)
Companies care deeply about renumbering because IPv4 addressing isn't exactly as simple. Most computer users just aren't that bright when it comes to the network they use everyday. Getting them to change their address is an exercise in headache generation. In the places where DHCP handles the assignments, migration is quick and easy (and "self healing" if the lease times are low enough -- change the DHCP server Friday @ 5 and all the desktops will have new addresses by Monday morning.)
But, I'll grant you there's little point in renumbering an IPv4 network... Today. If the future is IPv6, then one's energy is better spent on moving forward. However, moving to IPv6 is significantly more involved than changing an address. In this, Y2K is a good parallel. With y2k, the problem was space; years were stored as 2 digits instead of 4. Everything that dealt with dates had to be re-tooled to deal with "00" being "2000" instead of "1900". That ended up requiring changes in numerous places: data structures, file formats, displays, conversions from the old 2 digit format, etc. The exact same thing is true of IPv4->IPv6. Every application with any IPv4 knowledge at all will need re-work. In the simplest cases (which are, sadly, few), recompiling the application will make it IPv6 capable. In all other cases, the application(s) will have to have sections rewritten to handle the increased size of the address field(s), printing IPv6 addresses, determining when to use IPv4 vs. IPv6, etc., etc.
But all this still comes down to a "chicken and the egg..." Nobody will want to use IPv6 until everyone is using IPv6. And there are lots of ("legacy") IPv4 networked gear out there that no longer has anyone supporting them to make them IPv6 capable. Don't expect people to run out to replace dozens of appliances, that honestly, aren't tha
Your contrived example is BS. All of these /8's have been allocated for years. The organizations holding them have had a decade to implement best practices and move away from such large, unnecessary utilizations of address space.
/8 is costing the company per year. NO ONE gets address space for free. Granted, for the companies holding /8's, the cost is down in the noise of the operational budget.
Your "underling" fails to mention how much that
what do you do when you have your first merger with another company...
The same thing companies have been doing for YEARS... plan for it and build a migration plan. You seem to think mergers are a simple flip of a switch for people and machines alike. Such a notion is laughable. Renumbering every computer in both companies is simple in comparision to all the other tasks in consolidating two companies. In fact, there may be no need at all to renumber either network. NAT will handle private transformations, too.
Also worth noting is the possiblity of a company divesting into two or more independant companies. If they were built within one public network, breaking them up can be an even bigger mess. If they're using private addressing, the process is simple.
I've never been in a "major corporation" that didn't use private addressing internally. (And that includes at least one of those /8 hoarding bastards.) NAT at the firewalled perimeter handles their public addressing. At that point, changing providers and address ranges is rather simple and painless. AND, you end up needing far fewer globally unique, routable addresses.
There is no reason everything shouldn't have its own IP address.
And there's equally no reason why they should. Do you really need to ping the nerf darts on my desk?
why not just assign 1 phone number to each 10 desks and ask them to share...
Funny you mention it. While not sharing in the analog partyline sense, PBX's already do this very thing. How many extentions are there on your office phone system? 20, 50, 100? How many actual CO lines are there? 8, 20? It's very rare for a PBX to have one CO line for each extention. In fact, that's counter productive -- just put a damned POTS phone on each desk. (Telco's used to sell this as centrex service.)
Greedy certainly applies. Go ask one of them to return their address space in exchange for one more suitable to their network. Apple certainly has no need for that much address space. MIT? I think every other university on Earth is evidence they don't need a /8.
Most places/networks have more address space than they use (will ever use.) In my experience, this appears to be universal.
BBN... currently known as Level 3 Communications.
They were one of the first movers and shakers in the internet industry 20 odd years ago.
It's "not worth it" simply because of the greedy bastards hoarding those /8's. Let's see who is hoarding all that space... ...
/8's -- more if you count the number of big contractors holding /8's.
003/8 - GE
004/8, 008/8, 046/8 - BBN
009/8 - IBM
015/8 - HP
016/8 - DEC
017/8 - Apple
018/8 - MIT
019/8 - Ford
045/8 - Interop Show Network !!
And then there's the US GOVERNMENT with 8+
No, they aren't. But thank you for playing.
You don't understand the protocol, so you don't understand this is simply How It Works (tm).
You can use telnet to browse websites if you understand the HTTP protocol well enough. Is this a vulnerability? No.
I've been preaching this for years. Client reported stats are not trustworthy -- they never have been. Unfortunately, lawyers and judges aren't the most technically savy people around.
This assumes perfect communications between all the peers and tracker. If a single update gets lost, then the numbers won't add up. It's far, FAR too likely for peers to be cut off from the tracker during their session. They'll continue to upload and download from any connected peers in the interim. And the tracker will continue to report them to new peers until they timeout (varies from tracker to tracker.)
Add into the mix the clients that find other peers away from the tracker (*cough*BitComet*cough*) [DHT, peer exchange, plugins, etc.] and this method falls on it's face.
There are just as many ways to detect cheating as there are ways to cheat. Unfortunately, none of them are completely free.
There are two problems with this... 1) you assume the client knows it's external IP address. In most cases, this simply isn't true. And it's not even necessary. 2) Broadcast discovery will only work if the clients are in the same subnet and/or the same broadcast domain (i.e. more than one subnet on the same cable.)
Btw, people already cheat using this method. One machine reports to the tracker while another on the local lan does not. They can move the same file between themselves hundreds of times and "legally" boost their reported stats. [It's really much more work than it's worth.]
It doesn't take any sniffing at all... just read the spec for the BT protocol. This is the same lameness as screaming Apache is vulnerable because I can use telnet to get a web page. (And I don't need ethereal's help doing it.)
This isn't a vulnerability; it's simply the way the protocol works. It doesn't take a client to act like one and send syntacically correct requests to a tracker. (In fact, that's how I test tracker code... with telnet and/or nc)
I will warning those wanting to "cheat" using this method... if you follow his instructions to the letter, you will be detectable like a road flare in a movie theater. (if anyone is actually looking.)
And such things are very Not Cheap(tm). Only the bean counters can say if it's a good investment against possible downtime. Lemme ask, how often has that backup SAN and off-site tape storage been of utility?
Of course, I've lived in a world where "uptime" and "reliability" aren't always absolutes... if one mail server is down and 1000 of those million users cannot get their mail, is that "down"? (answer: no. the 'system' is up; your mail is 'unavailable'.) And the number of nines is measured within "business hours" -- if the client uses the system between 8am-8pm, we could turn the datacenter off between 8pm-8am and still have "five nines". (maint. windows don't count as downtime.)
That's 99.983% reliability, btw. (People really need to get out pencil and paper to do their math 'cause they are getting everything wrong when they aren't looking at it.)
I said no such thing... There are indeed "plans" in place for failures. They don't involve dropping thousands of dollars on hardware and software that are not necessary. The fact that the system has been working for 2 years is proof it's not necessary.
If the server dies, move the drive(s) to another box. There's a mirrored set of drives inside there -- so a dead drive doesn't take the files with it. Linux/FreeBSD is very forgiving of being moved to wildly different base hardware; and any incompatabilities are quickly and easily corrected. Plus, the server is backed up to tape (as are a number of other systems), so at worst, one day of "stuff" would be lost. The entire cyrus/sendmail combination can be dropped on just about any system in the building (even inside a vmware if necessary.)
Btw, replication doesn't necessarly prevent replicating errors. The major downtime was due to a dbm error, so it would've happened on every box.
[The only "luck" part is that it's drives are still good. Unlike all the other machines...]