I saw this many years ago on The Tonight Show (back when they had competent and funnypeople on it, not likenow), when they had Mel Tillis on. Mel put the ear piece in, switched it on, and stopped stuttering completely.
Of course, Mel Tillis without stuttering is like a flat-chested Dolly Parton.
For situations like I am in (behind a corporate firewall), there is little chance of getting permission to poke a hole for BT.
However, it is just at the edge of feasibility to set up a bastion host running some form of BT proxy, whereby the basition runs BT, and the clients inside connect to the BT proxy via a web interface.
Has any thought been given to something like that?
Agent Smith writes "There was a major hacking incident last night on the servers of the Matrix. The attackers wreaked havoc on at least one game server, with apparent god-like capabilities in-game. There's already an official statement on the forums - 'The Machine Overlords are now working with law enforcement, and we promise all of you that these individuals will be prosecuted to the full extent of the law.'" There's a little more information via a post on the Matrix messageboard - apparently the carnage (including many less powerful players getting killed) involved "..teleporting people all over the world, teleporting hostile guards into the safe-holds, bringing in hordes of special event monsters, and teleporting everyone to a city at the bottom of the sea."
First of all, the GPS transmissions aren't "one a second" - they are continuous. The time pulse you get out of a GPS receiver is once per second, but that is just for convenience.
Secondly, the single biggest factor in the accuracy of GPS is not the timebase in the receiver, because normal receivers don't have much of a time base. That is why you need 4 birds to get a "3D" lock - actually you are getting a 4D lock: 3 space and 1 time. With three birds you get a 3D fix: 2 space and 1 time (actually you get a hypersurface in 4D, but...).
The limit on GPS now is time-of-flight uncertainty in the signals themselves - due to variations in the ionosphere at any given time there will be an unknown amount of bending of the signals as they pass through, which introduces a variable delay. Military rigs compensate by using 2 different frequencies, one the frequency normal civilian rigs use, and a second one being only available to military rigs. The two different frequencies are bent by different amounts (just as light passing through a prism is bent by different amounts) and by computing the difference in time-of-flight of the two frequencies you can work out the amount of refraction the signals are undergoing and subtract it out.
Now, a new system could increase the chip rate (the rate at which the GPS signal is spread) and thus allow for more precise time determination (and thus more precise location determination), and by providing multiple frequencies per bird could remove the ionospheric refraction variable from the system, and thus could provide real-time position data down to a centimeter or less, but at the expense of more complicated processing systems. Do remember that there are a few iterations of Moore's Law that have occurred between when GPS was first deployed and now.
However, I see the same fundimental problem with the EU system as they see with the US system - namely since WE don't control it, how can WE trust THEM to play fair (substitute any suitable nationstate for WE and THEM as needed.)
Unfortunately, this will in the limit lead to each nationstate wishing to deploying their own system, so as to have a trustworthy system under their own control. However, few nationstates have the resources to deploy such a system.
"Post-RIAA world"? Quickly, quarentine Cliff - he has Jon Katz disease! (Actually, this being Memorial Day, I must admit I actually miss JK sometimes..) </OT>
I would ask this: Is your album available in stores, or only via on-line ordering? If it is only available on-line, how easy to remember is the URL?
Consider where people listen to the radio - I would say mostly in their cars. Now, here I am, driving along, and on comes your ad. First of all, my ad filter wetware comes online - I hit the button to skip to a new station, or I blank out what is going on.
OK, so let's say your ad plays a snippet of the music in question, and I listen to it and say "Huh, that's kinda cool. Who is this?" Then your ad says "That was a sample of Scab - Now the Puss Flows Freely, available for download and purchase at www.fbq39x34.com/~tqxir/49912/pxj36.asp". Now, even if you said that slowly enough I could copy it, I'm not going to whip out a pen and paper and copy that while weaving through downtown traffic.
That's part of why the RIAA is still pertainent in this world. If all I can remember is the group name (and maybe not even that all that well) and if the group is in Worst Buy, I can find it. But if I have to find them online, and if all I have is some common words that don't lend themselves to Googling....
Last but not least: how does your website handle orders? Do you hid things behind layers of Flash and Javascript? Do you work only with Exploiter? Do you not accept credit cards?
Ask yourself this: if I wanted to buy that album, how many impediments are in my way?
A bolt-action 30-06, or even an autoloading 30-06 is NOT a controlled item in the US. I don't know where you are getting your information, but you might try actually doing some research.
The only thing "controlled" about a 30-06 is that if you are buying one from a dealer the dealer will have to fill in the appropriate forms.
True, but that is no worse than the situation now - for example, my ISP has blacklisted netvision.net.il because they are infected with a virus and won't clean up their act.
They will remain blacklisted ad infinitum, since it is unlikely they will be able to notify us if and when they clean up their act.
However, again the idea is to bring pressure to bear quickly upon the spammers, that they are removed from the system before they make any money, and wither and die.
The short answer is that if you are willing to buy domains and spam from them, there is relatively little anybody can do about it with any system.
However, you not only have to register the domain, you have to host it somewhere. Obviously, the current IP based blacklists don't go away, so your IP gets blocked as well.
However, the idea here is to be able to identify WHO YOU ARE - to be able to track the spam back not just to spammer.example, but to Joe Blowe at 1234 Pink Tinned Meat Lane, FL. If I can trace the mail back to your server, I can get your name. Ideally, it should be in WHOIS, but failing that I can file a subpoena and get it.
As for how to blacklists expire - I would propose a geometricly increasing timeout: first offence, blacklist for a week, then 49 days, then 343 days, etc.
Clearly you've never done development on a driver for ANY OS.
You don't want your development machine to be the machine your driver runs on. If your driver breaks, it could crash the machine, corrupt the file system, or any number of nasty things.
You also need to be able to inspect OS level objects, which you usually cannot do on a running system. So, most OS's provide a debug capability that "freezes" the system, and through a simple interface (usually serial) allows you to inspect the state of the whole system. However, to do that you need a second computer to do the development on.
So, I would suggest you stop trolling on/. and go out into the wider world, and learn something about the things you try to talk about.
For the record, the device driver I was developing was for a DSP based RF analysis board, which if you had spent any time at all checking my background as posted on/. you would have seen is what I do for a living.
Now, put down the mouse, drop your cock, go out into the world, and start actually learning something other than how to troll/. - we have plenty of those already.
The fundemental problem with this is that it gives a spammer a way to insure a user is valid, thus allowing him to continue to spam the user. Thus, it not only does not solve the problem, it makes it worse.
Here's my counterproposal:
1) Create a new system, called "Verified Mail Transport System" or VMTS. 2) A VMTS server has a public/private keypair. The public key is listed via DNS, the private key is held by the server. 3) Several revocation lists exist - for example, a list of servers known to propagate spam, or to accept mail from non-VMTS servers and send it as though it had come from a VMTS server. 4) Failure to comply with the rules of VMTS is sufficent cause to be blacklisted - the server's administrators will be given 1 week after notification of violation to correct the problem, and if the problem persists, they are blacklisted. It does not matter whether the server is ittybittyisp.cm or uunet.net. 5) All servers are REQUIRED to validate the identity of anyone originating mail on that server - this validation can be done by a public/private keypair system similar to the one used between servers, or by RADIUS, or any other means that allows for tracing a given message back to the (l)user who sent it. 6) The user's machine shall sign the mail with the user's identity, or the user's mail server shall sign the message with its key if the user's system cannot do so. This signature shall be placed in the mail system headers of the message, along with the user's ID (NOTE: the user's ID does not have to be the user's email address or name, just some identifying number). 7) When a mail server handles a piece of mail, it shall compute a signature of the headers it adds AND the signature of the previous mail server's headers, add place that signature in the headers. That signature shall be based on the mail server's keypair.
To make this clear, given the following headers:
1) From: server foo
2) For: joeblow@bar.ex
3) Priority: highest
4) Prev_hdr_sig: 0xf238ace1
5) From: server narf
6) For: joeblow@bar.ex The receiving server need only check headers 1-4. Header 4 covers header lines 5 up.
8) A mail server shall validate the headers from the previous server by looking up that server's public key, decoding the signature, and verifying the signature matches the headers. 9) Upon getting a failure to match in step 8, the server receiving the message shall stop the transfer and drop the message. It MAY also blacklist the sending server, notify its postmaster, or whatever other actions are deems needed.
NOTE: since all each server in the chain needs to check is just a very small number of headers, this shouldn't add a HUGE load to the server (less than spam filtering does). Since the keys are distributed via DNS (perhaps as TXT records, perhaps as a dedicated record), they get cached, so that the load of getting them is reduced.
When I, as an end user, get my mail, I can still get SMTP and VMTS. I can then read my VMTS mail first, then worry about the SMTP.
Now, how does this fight spam? 1) No unintentional mail servers/relays. Since you have to set up a DNS record to be valid, you won't see accidental open relays. 2) Intentional spam relays get blacklisted, since that is a part of the rules of the system. The big backbone providers like UUNET can and will get blacklisted if they don't comply, so they cannot play host to pink contracted spammers. 3) If I want to fully authenticate a message, I can independandly check each header block. If the headers are forged the signature won't decrypt properly (since the forger won't have the private key needed to encrypt it), and I immediately know where the message came into the system (thus, who to blacklist). 4) If I wish to identify the particular (l)user who sent the message, I could send the originating mail server a message with the following information:
4a) the signature I've computed for the message
4b) the signature heade
All the Q/A in the world does you no good if you don't act upon what Q/A has found.
I used to do driver development for NT4.0. As such, I had a "victim" machine and a "debugging" machine, linked via a serial cable. The victim runs my driver, and I do my development and debug using the debugging machine to access the kernel debugger on the victim.
A normal cycle of development went something like this:
{ {{edit,compile} while errors} link } while errors
Download to victim
boot victim. Watch hundreds of assertion failures from the OS scroll by on debugging console.
Shut down debugger as it has leaked all available memory
Start debugger again
Load my driver and test.
locate bugs in my driver, begin again
Note: this was a fresh install of NT4.0 debugging, with SP4. No third party apps (other than my own) installed. This was using Microsoft's WinDBG.
Now, I don't know about Microsoft's developers, but I regard an assertion failure as a failure - i.e. a bug to be fixed. Having HUNDREDS of them in released code is just unacceptable. Using an ASSERT() as a debugging printf() is wrong.
So either a) the MS developers have a different view of things than I do, or b) the MS developers were allowing hundreds of easily identified problems to go into release.
Now, EVERY non-trivial software project's lead engineer must make a decision at every release - "Do I fix these bugs and slip the release, or fix these bugs in the next release?" And EVERY lead will allow some bugs to slip. Usually, those bugs are deemed minor - spelin mestaches (sic), layout errors, things like that.
But to have a) hundreds of assertion failures, which give you file and line number of the error, and b) a memory leak in your debugger bad enough that you can WATCH it leak away hundreds of megabytes of memory each time, and to allow that to go out? Ugh.
Now I am sure that MS Q/A found those errors - if not they are far more incompetent that I am willing to assume they are. So clearly Q/A was overruled by management - "We don't care, ship it anyway!"
And that is the central problem to ANY Q/A department - if management overrules them, and forces a shipment anyway, then how do you blame Q/A?
I've said this before, and I shall say it again now: this is one of the places a real ISO-9000 standard can be useful. If the spec sayth "Lo, and the release candidate code shall have no bugs open against it in the bug tracking system, and any bugs that exist shall be clearly targeted to later revisions, and Q/A shall findth no undocumented bugs in the code, or the release shall be slipped, and the bugs corrected, AMEN!" then Q/A can say "OK, if you want to throw our ISO-9000 cert out the door, then by all means override us and ship."
(Yes, that won't prevent management from simply targeting all bugs to a later revision and shipping, but it at least forces some consideration of the consequences to me made."
This guy's reasoning seems to go something like this:
"This showed up all of a sudden, we've never seen anything like it, so it must be ALIENS!"
True, he is not suggesting that SARS is the first step of global domination by an actual extra-terrestrial intelligence, but he is saying that SARS came from a comet.
OK, let's break out Occam's razor. (strop, strop, strop. Hmmm, good and sharp.)
The explaination that requires the fewest ad-hoc assumptions is the most likely to be correct (as it has the fewest places to break).
Scenario 1: SARS is ET in origin. Required ad-hoc assumptions: there are viruses in space. Those viruses can infect humans. Those viruses can survive transport on a comet or other body from their point of origin and earth. None of those assumptions have much evidence to back them up.
Scenario 2: SARS is a naturally occuring virus that we have not seen before. Required ad-hoc assumptions: none.
OK, kids - which of these scenarios survives Occam's Razor?
EXACTLY! MOD UP PARENT, PLEASE!
on
Build Your Own ECG
·
· Score: 5, Informative
EXACTLY! Just what I was thinking when I saw this.
Kids, DO NOT TRY THIS AT HOME.
Real medical gear has full galvanic isolation - that means there is NO current path that goes from the patient's body to the equipment - the signals pass through either an isolation transformer, an optocoupler, or a capacitive coupling. That way, any ground leakage in the equipment won't fry the user.
It takes about.1 amp to kill you dead, and about.01 amp can interfere with normal heart operation. Normally, skin runs about 10 to 100 kohms resistance - to get 10 milliamps you would need about 100 to 1000 volts delivered across the chest.
When you put the gel on, you reduce the resistance to a few hundred ohms. Now you need only a volt.
Normal consumer equipment can have "leakage currents" - places current shouldn't be flowing but is. You hook your home-brew circuit up to the printer port on your PC, and maybe you are OK. Then one day, while screwing around with it, a cap starts to fizzle in your power supply, or maybe you reach up to adjust your monitor, or maybe you put your foot on the ventilation register. Then you get to start (posthumously) on the 6 o'clock news.
At a MINIMUM, you should power the circuit with a nine volt battery, and communicate with the PC via an opto-isolated RS-232 link.
Even better, splurge and get the real medical isolation amplifier modules. Yes, they will cost a bit more than US$4, but then, if that is all the value you place on your life....
On second thought - go for it! And make sure you clip the ground lead off your computer's power cord while you are at it. And do it in the bathtub - that will help shield the fnord rays out.
At the Primate Research Center, an interviewer asked Washoe Jr. (daughter of the famous chimp taught sign language) about the news that chimps might be included under Genus homo.
She went to her computer, and with a few deft mouseclicks brought up a famous discussion sight called Slashdot. She quickly set her "threshold" to -1.
Gesturing to the screen, she then signed "Thanks, but no thanks."
Sounds like another "twenty year man" speaking - Amen.
But again, that is one of the things that seperates a GOOD senior software engineer from a new hire - the knowledge of what happens when one bodges features in, and the courage to say to the senior VP of marketing "NO, I am not going to just rush that in. The risks are too great. If you don't like it, you can talk to the head of the department, and see if he is willing to accept my resignation, because this feature will not be rushed in while I am the lead on this project. I am perfectly willing to begin work on the feature, and once it has been designed, implemented, and tested, we can release it. Now, do you wish to continue to delay the day it is done by wasting my time, or do you want be to begin working on it correctly now?"
NOTE: Kids, don't try this at home UNLESS you really ARE the senior software engineer on a project - you have to have developed some cred with management to get away with this.
And this is also why senior software engineers need to constantly pressure management to make sure the company policy allows you to do this, and that you get backing from management. This is one of the (few) places an ISO-9000 cert is useful - make sure your policies are written to require planning and test, so that when the VPMarketing tries to do an end-run around it, you can say, "Well, if you want to void the company's ISO-9000 cert, I guess I can start...."
I think the problem is the immediacy of a web site - it is possible to make quick changes and see the results (as opposed to a lengthy edit/compile/link/load/swear cycle) so people get used to making quick changes. When you can make a quick edit and immediately see the results, you get sloppy - when you are looking at a 15 minute e/c/l/s cycle you are a bit more careful.
On my project at work we do much of the work in TCL/Tk - and so you can make changes while the system is running. This is good, in that when you are doing communications protocol testing you often need to experiment to determine the things the standards didn't define, but you can all too often get into the habit of "Well this looks simple enough - I'll just throw it in to HEAD rather than fully checking it - what could go wrong?" (and I am no better nor no worse than the rest of the guys under me about this, though I do try to set an example).
That is why I feel it is so important to make this point over and over again: No matter how tempting, test before going live.
... sometimes a change is so simple it seems better to just go direct to the liver (sic) server, then all of sudden everything is down....
And that is EXACTLY my point. I've been bit by that too many times myself - "Oh, this is so simple I'll just roll it in". Then all goes to hell.
True, there are things that won't break until they go live - that's life in a universe ruled by Murphy. But the idea is to reduce the likelihood of an error as much as possible.
That is why, no matter how tempting, no matter how trivial the change seems, no matter how much it seems like a waste of time, you put it into test first, test as much as you can, then go live.
Slashdot Mirror
This idea is actually pretty old: Edinburgh Masker.
I saw this many years ago on The Tonight Show (back when they had competent and funny people on it, not like now), when they had Mel Tillis on. Mel put the ear piece in, switched it on, and stopped stuttering completely.
Of course, Mel Tillis without stuttering is like a flat-chested Dolly Parton.
For situations like I am in (behind a corporate firewall), there is little chance of getting permission to poke a hole for BT.
However, it is just at the edge of feasibility to set up a bastion host running some form of BT proxy, whereby the basition runs BT, and the clients inside connect to the BT proxy via a web interface.
Has any thought been given to something like that?
Agent Smith writes "There was a major hacking incident last night on the servers of the Matrix. The attackers wreaked havoc on at least one game server, with apparent god-like capabilities in-game. There's already an official statement on the forums - 'The Machine Overlords are now working with law enforcement, and we promise all of you that these individuals will be prosecuted to the full extent of the law.'" There's a little more information via a post on the Matrix messageboard - apparently the carnage (including many less powerful players getting killed) involved "..teleporting people all over the world, teleporting hostile guards into the safe-holds, bringing in hordes of special event monsters, and teleporting everyone to a city at the bottom of the sea."
nVidia: "Well, for this program they will never step off the rail, so we can fake it so it looks good from the rail only."
ATI: "Well, this shader program isn't optimally coded - here is a more optimally coded shader that does the exact same thing but more quickly."
nVidia: "Well, you caught us, but we have to cheat because you have it in for us!"
ATI: "Well, you caught us, and although we were doing the exact same thing (only faster), we will remove that code ASAP."
The observation:
Has anybody else noticed how cadaverous the new G-Man looks? Especially his eyes - he looks like a dead man walking. Hmmmm.
The hope:
Either that HL2 runs under Wine, or that Valve releases a native version.
First of all, the GPS transmissions aren't "one a second" - they are continuous. The time pulse you get out of a GPS receiver is once per second, but that is just for convenience.
Secondly, the single biggest factor in the accuracy of GPS is not the timebase in the receiver, because normal receivers don't have much of a time base. That is why you need 4 birds to get a "3D" lock - actually you are getting a 4D lock: 3 space and 1 time. With three birds you get a 3D fix: 2 space and 1 time (actually you get a hypersurface in 4D, but...).
The limit on GPS now is time-of-flight uncertainty in the signals themselves - due to variations in the ionosphere at any given time there will be an unknown amount of bending of the signals as they pass through, which introduces a variable delay. Military rigs compensate by using 2 different frequencies, one the frequency normal civilian rigs use, and a second one being only available to military rigs. The two different frequencies are bent by different amounts (just as light passing through a prism is bent by different amounts) and by computing the difference in time-of-flight of the two frequencies you can work out the amount of refraction the signals are undergoing and subtract it out.
Now, a new system could increase the chip rate (the rate at which the GPS signal is spread) and thus allow for more precise time determination (and thus more precise location determination), and by providing multiple frequencies per bird could remove the ionospheric refraction variable from the system, and thus could provide real-time position data down to a centimeter or less, but at the expense of more complicated processing systems. Do remember that there are a few iterations of Moore's Law that have occurred between when GPS was first deployed and now.
However, I see the same fundimental problem with the EU system as they see with the US system - namely since WE don't control it, how can WE trust THEM to play fair (substitute any suitable nationstate for WE and THEM as needed.)
Unfortunately, this will in the limit lead to each nationstate wishing to deploying their own system, so as to have a trustworthy system under their own control. However, few nationstates have the resources to deploy such a system.
"Post-RIAA world"? Quickly, quarentine Cliff - he has Jon Katz disease!
(Actually, this being Memorial Day, I must admit I actually miss JK sometimes..)
</OT>
I would ask this: Is your album available in stores, or only via on-line ordering? If it is only available on-line, how easy to remember is the URL?
Consider where people listen to the radio - I would say mostly in their cars. Now, here I am, driving along, and on comes your ad. First of all, my ad filter wetware comes online - I hit the button to skip to a new station, or I blank out what is going on.
OK, so let's say your ad plays a snippet of the music in question, and I listen to it and say "Huh, that's kinda cool. Who is this?" Then your ad says "That was a sample of Scab - Now the Puss Flows Freely, available for download and purchase at www.fbq39x34.com/~tqxir/49912/pxj36.asp". Now, even if you said that slowly enough I could copy it, I'm not going to whip out a pen and paper and copy that while weaving through downtown traffic.
That's part of why the RIAA is still pertainent in this world. If all I can remember is the group name (and maybe not even that all that well) and if the group is in Worst Buy, I can find it. But if I have to find them online, and if all I have is some common words that don't lend themselves to Googling....
Last but not least: how does your website handle orders? Do you hid things behind layers of Flash and Javascript? Do you work only with Exploiter? Do you not accept credit cards?
Ask yourself this: if I wanted to buy that album, how many impediments are in my way?
A bolt-action 30-06, or even an autoloading 30-06 is NOT a controlled item in the US. I don't know where you are getting your information, but you might try actually doing some research.
The only thing "controlled" about a 30-06 is that if you are buying one from a dealer the dealer will have to fill in the appropriate forms.
as
which, I personally feel would be an interesting name for a security enhancing project - right up there with Big Brother.
ENOCAFFINE
True, but that is no worse than the situation now - for example, my ISP has blacklisted netvision.net.il because they are infected with a virus and won't clean up their act.
They will remain blacklisted ad infinitum, since it is unlikely they will be able to notify us if and when they clean up their act.
However, again the idea is to bring pressure to bear quickly upon the spammers, that they are removed from the system before they make any money, and wither and die.
Good questions, actually.
The short answer is that if you are willing to buy domains and spam from them, there is relatively little anybody can do about it with any system.
However, you not only have to register the domain, you have to host it somewhere. Obviously, the current IP based blacklists don't go away, so your IP gets blocked as well.
However, the idea here is to be able to identify WHO YOU ARE - to be able to track the spam back not just to spammer.example, but to Joe Blowe at 1234 Pink Tinned Meat Lane, FL. If I can trace the mail back to your server, I can get your name. Ideally, it should be in WHOIS, but failing that I can file a subpoena and get it.
As for how to blacklists expire - I would propose a geometricly increasing timeout: first offence, blacklist for a week, then 49 days, then 343 days, etc.
Clearly you've never done development on a driver for ANY OS.
/. and go out into the wider world, and learn something about the things you try to talk about.
/. you would have seen is what I do for a living.
/. - we have plenty of those already.
You don't want your development machine to be the machine your driver runs on. If your driver breaks, it could crash the machine, corrupt the file system, or any number of nasty things.
You also need to be able to inspect OS level objects, which you usually cannot do on a running system. So, most OS's provide a debug capability that "freezes" the system, and through a simple interface (usually serial) allows you to inspect the state of the whole system. However, to do that you need a second computer to do the development on.
So, I would suggest you stop trolling on
For the record, the device driver I was developing was for a DSP based RF analysis board, which if you had spent any time at all checking my background as posted on
Now, put down the mouse, drop your cock, go out into the world, and start actually learning something other than how to troll
The fundemental problem with this is that it gives a spammer a way to insure a user is valid, thus allowing him to continue to spam the user. Thus, it not only does not solve the problem, it makes it worse.
Here's my counterproposal:
1) Create a new system, called "Verified Mail Transport System" or VMTS.
2) A VMTS server has a public/private keypair. The public key is listed via DNS, the private key is held by the server.
3) Several revocation lists exist - for example, a list of servers known to propagate spam, or to accept mail from non-VMTS servers and send it as though it had come from a VMTS server.
4) Failure to comply with the rules of VMTS is sufficent cause to be blacklisted - the server's administrators will be given 1 week after notification of violation to correct the problem, and if the problem persists, they are blacklisted. It does not matter whether the server is ittybittyisp.cm or uunet.net.
5) All servers are REQUIRED to validate the identity of anyone originating mail on that server - this validation can be done by a public/private keypair system similar to the one used between servers, or by RADIUS, or any other means that allows for tracing a given message back to the (l)user who sent it.
6) The user's machine shall sign the mail with the user's identity, or the user's mail server shall sign the message with its key if the user's system cannot do so. This signature shall be placed in the mail system headers of the message, along with the user's ID (NOTE: the user's ID does not have to be the user's email address or name, just some identifying number).
7) When a mail server handles a piece of mail, it shall compute a signature of the headers it adds AND the signature of the previous mail server's headers, add place that signature in the headers. That signature shall be based on the mail server's keypair.
To make this clear, given the following headers:
1) From: server foo
2) For: joeblow@bar.ex
3) Priority: highest
4) Prev_hdr_sig: 0xf238ace1
5) From: server narf
6) For: joeblow@bar.ex
The receiving server need only check headers 1-4. Header 4 covers header lines 5 up.
8) A mail server shall validate the headers from the previous server by looking up that server's public key, decoding the signature, and verifying the signature matches the headers.
9) Upon getting a failure to match in step 8, the server receiving the message shall stop the transfer and drop the message. It MAY also blacklist the sending server, notify its postmaster, or whatever other actions are deems needed.
NOTE: since all each server in the chain needs to check is just a very small number of headers, this shouldn't add a HUGE load to the server (less than spam filtering does). Since the keys are distributed via DNS (perhaps as TXT records, perhaps as a dedicated record), they get cached, so that the load of getting them is reduced.
When I, as an end user, get my mail, I can still get SMTP and VMTS. I can then read my VMTS mail first, then worry about the SMTP.
Now, how does this fight spam?
1) No unintentional mail servers/relays. Since you have to set up a DNS record to be valid, you won't see accidental open relays.
2) Intentional spam relays get blacklisted, since that is a part of the rules of the system. The big backbone providers like UUNET can and will get blacklisted if they don't comply, so they cannot play host to pink contracted spammers.
3) If I want to fully authenticate a message, I can independandly check each header block. If the headers are forged the signature won't decrypt properly (since the forger won't have the private key needed to encrypt it), and I immediately know where the message came into the system (thus, who to blacklist).
4) If I wish to identify the particular (l)user who sent the message, I could send the originating mail server a message with the following information:
4a) the signature I've computed for the message
4b) the signature heade
I used to do driver development for NT4.0. As such, I had a "victim" machine and a "debugging" machine, linked via a serial cable. The victim runs my driver, and I do my development and debug using the debugging machine to access the kernel debugger on the victim.
A normal cycle of development went something like this:
Note: this was a fresh install of NT4.0 debugging, with SP4. No third party apps (other than my own) installed. This was using Microsoft's WinDBG.
Now, I don't know about Microsoft's developers, but I regard an assertion failure as a failure - i.e. a bug to be fixed. Having HUNDREDS of them in released code is just unacceptable. Using an ASSERT() as a debugging printf() is wrong.
So either a) the MS developers have a different view of things than I do, or b) the MS developers were allowing hundreds of easily identified problems to go into release.
Now, EVERY non-trivial software project's lead engineer must make a decision at every release - "Do I fix these bugs and slip the release, or fix these bugs in the next release?" And EVERY lead will allow some bugs to slip. Usually, those bugs are deemed minor - spelin mestaches (sic), layout errors, things like that.
But to have a) hundreds of assertion failures, which give you file and line number of the error, and b) a memory leak in your debugger bad enough that you can WATCH it leak away hundreds of megabytes of memory each time, and to allow that to go out? Ugh.
Now I am sure that MS Q/A found those errors - if not they are far more incompetent that I am willing to assume they are. So clearly Q/A was overruled by management - "We don't care, ship it anyway!"
And that is the central problem to ANY Q/A department - if management overrules them, and forces a shipment anyway, then how do you blame Q/A?
I've said this before, and I shall say it again now: this is one of the places a real ISO-9000 standard can be useful. If the spec sayth "Lo, and the release candidate code shall have no bugs open against it in the bug tracking system, and any bugs that exist shall be clearly targeted to later revisions, and Q/A shall findth no undocumented bugs in the code, or the release shall be slipped, and the bugs corrected, AMEN!" then Q/A can say "OK, if you want to throw our ISO-9000 cert out the door, then by all means override us and ship."
(Yes, that won't prevent management from simply targeting all bugs to a later revision and shipping, but it at least forces some consideration of the consequences to me made."
This guy's reasoning seems to go something like this:
"This showed up all of a sudden, we've never seen anything like it, so it must be ALIENS! "
True, he is not suggesting that SARS is the first step of global domination by an actual extra-terrestrial intelligence, but he is saying that SARS came from a comet.
OK, let's break out Occam's razor. (strop, strop, strop. Hmmm, good and sharp.)
The explaination that requires the fewest ad-hoc assumptions is the most likely to be correct (as it has the fewest places to break).
Scenario 1: SARS is ET in origin. Required ad-hoc assumptions: there are viruses in space. Those viruses can infect humans. Those viruses can survive transport on a comet or other body from their point of origin and earth. None of those assumptions have much evidence to back them up.
Scenario 2: SARS is a naturally occuring virus that we have not seen before. Required ad-hoc assumptions: none.
OK, kids - which of these scenarios survives Occam's Razor?
EXACTLY! Just what I was thinking when I saw this.
.1 amp to kill you dead, and about .01 amp can interfere with normal heart operation. Normally, skin runs about 10 to 100 kohms resistance - to get 10 milliamps you would need about 100 to 1000 volts delivered across the chest.
Kids, DO NOT TRY THIS AT HOME.
Real medical gear has full galvanic isolation - that means there is NO current path that goes from the patient's body to the equipment - the signals pass through either an isolation transformer, an optocoupler, or a capacitive coupling. That way, any ground leakage in the equipment won't fry the user.
It takes about
When you put the gel on, you reduce the resistance to a few hundred ohms. Now you need only a volt.
Normal consumer equipment can have "leakage currents" - places current shouldn't be flowing but is. You hook your home-brew circuit up to the printer port on your PC, and maybe you are OK. Then one day, while screwing around with it, a cap starts to fizzle in your power supply, or maybe you reach up to adjust your monitor, or maybe you put your foot on the ventilation register. Then you get to start (posthumously) on the 6 o'clock news.
At a MINIMUM, you should power the circuit with a nine volt battery, and communicate with the PC via an opto-isolated RS-232 link.
Even better, splurge and get the real medical isolation amplifier modules. Yes, they will cost a bit more than US$4, but then, if that is all the value you place on your life....
On second thought - go for it! And make sure you clip the ground lead off your computer's power cord while you are at it. And do it in the bathtub - that will help shield the fnord rays out.
It's dimmer than they expect because Lister has not yet finished repainting it yet.
Be careful - what if they accept your resume and hire you?
Then you get to watch them pass the Schwarzschild Radius from the INSIDE!
Linux claims SCO irrelevant after suit.
For his next trick....
Making the bubbles in a Guiness flow up!
At the Primate Research Center, an interviewer asked Washoe Jr. (daughter of the famous chimp taught sign language) about the news that chimps might be included under Genus homo.
She went to her computer, and with a few deft mouseclicks brought up a famous discussion sight called Slashdot. She quickly set her "threshold" to -1.
Gesturing to the screen, she then signed "Thanks, but no thanks."
Sounds like another "twenty year man" speaking - Amen.
But again, that is one of the things that seperates a GOOD senior software engineer from a new hire - the knowledge of what happens when one bodges features in, and the courage to say to the senior VP of marketing "NO, I am not going to just rush that in. The risks are too great. If you don't like it, you can talk to the head of the department, and see if he is willing to accept my resignation, because this feature will not be rushed in while I am the lead on this project. I am perfectly willing to begin work on the feature, and once it has been designed, implemented, and tested, we can release it. Now, do you wish to continue to delay the day it is done by wasting my time, or do you want be to begin working on it correctly now?"
NOTE: Kids, don't try this at home UNLESS you really ARE the senior software engineer on a project - you have to have developed some cred with management to get away with this.
And this is also why senior software engineers need to constantly pressure management to make sure the company policy allows you to do this, and that you get backing from management. This is one of the (few) places an ISO-9000 cert is useful - make sure your policies are written to require planning and test, so that when the VPMarketing tries to do an end-run around it, you can say, "Well, if you want to void the company's ISO-9000 cert, I guess I can start...."
OUCH!
I think the problem is the immediacy of a web site - it is possible to make quick changes and see the results (as opposed to a lengthy edit/compile/link/load/swear cycle) so people get used to making quick changes. When you can make a quick edit and immediately see the results, you get sloppy - when you are looking at a 15 minute e/c/l/s cycle you are a bit more careful.
On my project at work we do much of the work in TCL/Tk - and so you can make changes while the system is running. This is good, in that when you are doing communications protocol testing you often need to experiment to determine the things the standards didn't define, but you can all too often get into the habit of "Well this looks simple enough - I'll just throw it in to HEAD rather than fully checking it - what could go wrong?" (and I am no better nor no worse than the rest of the guys under me about this, though I do try to set an example).
That is why I feel it is so important to make this point over and over again: No matter how tempting, test before going live.
And that is EXACTLY my point. I've been bit by that too many times myself - "Oh, this is so simple I'll just roll it in". Then all goes to hell.
True, there are things that won't break until they go live - that's life in a universe ruled by Murphy. But the idea is to reduce the likelihood of an error as much as possible.
That is why, no matter how tempting, no matter how trivial the change seems, no matter how much it seems like a waste of time, you put it into test first, test as much as you can, then go live.
Arg. I just got back from vacation, so I don't seem to be hitting on all 8 yet.
s/grammer/grammar