Looking at the code as a programmer, some things stand out:
The "copying" JBoss claims doesn't fit. There's differences in braces, keywords and other things that wouldn't be accounted for by automatic reformatting of code. I can't see a programm who's copying code directly going back in and doing that kind of editing. I'd expect braces to be maintained, for example, yet in several places they aren't.
The similar names are obvious names for types, variables and functions. Given the same spec to start from, without having seen the JBoss code at all, I'd pick the same names.
The places they cite as having code-structure similarity are very simple. Frankly, it looks to me like there's only one sane way to write that code.
It can't hurt to do a check, but I suspect JBoss is seeing copying where there's just only one obvious way to do something and most programmers, working independently, will make basically the same set of choices for that code.
Unfortunately it's not ready for prime time yet. Problems in the current version of SUS include inability of the server to be selective about platforms, lack of configurability in what gets installed to which clients (think about an update which interferes with desktop software but which is fine and even required on servers where the software it interferes with isn't present), continual re-installing of the same updates, lack of support for the standard Windows Update interface and lack of full support for all the features of the Automatic Updates component (primarily non-scheduled updates).
It's typical MS: it fits well into the MS view of how the world should work but has major flaws which show up when it's faced with how everybody else really works.
Let me turn that around: why shouldn't the main IT staff at corporate be patching all corporate systems regardless of location? We do it all the time in the Unix world, and there's only a handful of things (the kernel, the remote access service itself) where there's any more risk doing it from half a world away than there is doing it locally. It's not rocket science, it's 30-year-old ideas, MS is the only ones who don't take this situation as a given. Which is why their patch system is so much of a pain.
Every service pack on NT, 2K and XP to date has broken at least one major third-party application, IIRC.
As far as testing, I'm afraid that no company that can put out multiple revisions of the same patch, all to fix mistakes in the original patch, within the span of a week or so can possibly be doing even cursory testing. As far as MS is concerned, paying customers seem to be the beta testers.
Windows Update is fine if you've just got 1 system. Now, imagine you've got to patch 30,000 systems in 700 offices in 43 states, and you don't have any access to the main keyboard. And you can't use automatic updates because IT has to vet the patches before they're installed to make sure they won't make inoperable third-party software which your business depends on being operational.
I don't wee the tug-o-war. There's two seperate issues:
What the "correct" decision is at the end of the debate.
Whether the debate should occur at all.
People can disagree on #1, but to get to that point you have to have debate. What Symantec is doing is saying that there should be no debate at all. As long as they're just a private company that's fine, but the instant filtering software became mandatory under penalty of law then that shutting down of the debate landed squarely in the middle of the First Amendment.
If a position is so overwhelmingly correct that you can justify banning any arguments against it, you won't need to ban arguments against it. Conversely, if it's so weak that the only way it can prevail is to ban any argument against it, it's too weak to justify that ban.
They can distribute their code any way they please. The problem is, Linux contains other people's code, and they've only licensed it to be distributed under the GPL. SCO has no ownership interest in any code they didn't write, and no other law gives them any rights to it, so unless they agree to the GPL they're limited to the rights they'd have under copyright which specifically exclude the right to redistribute without permission.
What you can do with your code doesn't affect what you can do with my code.
Less bloated? You can't get much less bloated. For example, when an X client wants to display a string, the packet that gets sent to the server contains:
The "display string" command byte.
The string itself.
The co-ordinates to start drawing the string at.
The font ID to use (the font itself is already present in the server).
If client and server are on the same machine this command packet will go through a local-domain socket with just about zero overhead. If you used the traditional Windows model, the client would be making a call into the GDI libraries with the same parameters, and about the same overhead as X.
The rest of X follows similar models, with the client-to-server packet contents reduced to similarly abstract views of what's desired. So where exactly is the bloat?
Why would we want to remove the remote-windowing capability. Current reality is that one of the biggest headaches companies have is keeping all those installations of software updated with the latest patches. With X, you can remove the software entirely from the client machines and install it on one central server, yet still seamlessly have people run it and have it appear as if it was on their local machine. Updates only have to be applied to the central server's installation and they appear to users the next time they run the software. No more headaches trying to patch hundreds of clients.
This is why X was designed the way it was. In fact, this was the way X was originally used, when "turbo" meant you had a CPU that could run at 8MHz.
Those who refuse to learn from the past are doomed to repeat it... poorly.:)
As I said, I think SCO will have a hard time proving even that they have any control over AIX-derived code. The thing is, courts consistently rule that when you license something to someone, that license isn't exclusive unless the contract explicitly says it's exclusive. Nothing in the IBM-SCO contract says anything about exclusivity, so the court's unlikely to rule that SCO has any control over IBM's code or any ability to limit IBM's use or distribution of their own code. I seriously doubt SCO can show that any code they wrote as part of JFS went anywhere but their own OSes, so I don't see where they're going to get even to square 1.
I think you're incorrect on the JFS code issue. JFS predates the existence of SCO. As I understand it, IBM licensed the JFS code to SCO as part of a joint development effort, and SCO is now claiming that this gives them control over that code and anything else that IBM might decide to use it in. There's also the complication that there are two different JFS implementations within IBM: the original from their mainframe and AIX systems, and the clean-room implementation used in OS/2. The OS/2 code was the basis for the contribution to Linux, so even if SCO manages to prove their claim in the case of the AIX code (highly unlikely, given existing case law) they'd then have to argue that IBM vs. Phoenix Technology (the seminal clean-room reimplementation case that allowed the creation of clones on the IBM PC) was incorrect, and they're unlikely to be able to successfully argue that.
No, they care very much about getting the right results. The problem lies in the definition of "right". Depending on local politics, a system where it's always possible to determine exactly how the recorded result differed from the actual votes may be very much the wrong system... from the POV of the election officials. Think Tammany Hall.
It might not even be a competitor. For example, Fry's in the US sells Microsoft Windows. They're entirely within their rights to use the term "Microsoft Windows" in their ads to identify what they're selling, even though they don't hold the trademark on "Microsoft Windows". Buying a text ad keyed on that term would, IMHO, fall well within that same allowance.
Verisign has a problem with how ICANN and the technical community want the gTLD nameservers run. Perhaps ICANN should take steps to insure that their views no longer cause Verisign any issues, say by handing the relevant gTLDs over to another registry operator.
In the meantime, ISAGN for an RFC on DNS that says, basically, "If the zone for a domain does delegation to people other than the zone's owner, that zone can't contain wildcard RRs unless everyone with subdomains below it agrees to them. Also, you can return RRs for names in the zone but you can't return RRs for names in undelegated subdomains unless everyone with subdomains below you agrees to them (eg. Verisign could return an A record for "www.com" but not for "www.unregistered-domain.com").".
It's the same way a used-car salesman gets you to buy a car even when it's got questionable things about it: high-pressure sales tactics. Salescritters know most people are reluctant to just turn their backs on someone and walk away. It's rude. Similarly, it's rude to just hang up the phone when someone's talking so most people will only do so when the situation becomes utterly intolerable. So the salescritters get you on the line and tighten the screws, putting you in the position of either buying something or being inexcusably rude to them, betting that a certain nontrivial percentage of people will cave in rather than go against a lifetime of social conditioning against rudeness.
That's land-line. On my cel phone, all calls regardless of direction cost air-time. Plan air-time is 6.7 cents/minute under my plan. Air-time after plan minutes are exhausted is 50 cents/minute.
I suspect a judge would also be rather sympathetic to the argument "I don't need more air-time every month than I'm buying on my current plan. Why should I pay more every month for a larger plan just so that telemarketers don't have to pay the 50 cent/minute rate to bother me?".
You've got them if they admitted that they called you and got "no answer" or "answering machine". It's the incoming call that costs, not your answering it, and by admitting they got the machine or no answer they've admitted that they made the call and caused you to incur the cost. Combine their admission that they made the call with the proof on the bill that that call cost a specific amount, and small-claims court should be a slam-dunk for all those calls after the one where you told them not to call that number again.
This idea won't fly. The reason is simple: money. On landlines it costs nothing to receive a call, so consumers can complain but that's about it as far as the telephone carriers are concerned. Cel phones and SMS are a different story. When a telemarketer calls a cel phone or sends a text message, the phone's owner can point to a line on his bill and say "This unwanted call/message cost me $X.". Now the phone owner has proof of an actual dollar amount to go with his complaint, and he can demand reimbursement. If the phone carrier reimburses, it's going to turn telemarketing into a cost for the carriers and they're going to do something about it. If phone carriers refuse to reimburse, we'll see something like the junk-fax law passed ASAP. One way or another, when the telemarketers start generating provable costs to the recipients of their calls there's going to be a major backlash against the telemarketers.
Telemarketers, take note: if you won't compromise, if you insist that it's either no limits at all or nothing, you may find that the rest of us consider giving you nothing at all a perfectly acceptable outcome.:)
My reply to the author would be this: The GPL is a license, just like the license on any piece of software. Cisco and Broadcom knew it's terms and accepted them when they used GPL'd software in their products, just like any other company would know the terms of the licenses of software they use in their products. Are you saying that people who pirate Windows, who pirate songs and movies, who pirate any software in violation of the license terms, are right and that Microsoft, the RIAA and MPAA, Eolas and the rest are wrong in trying to enforce their licenses and prevent license violations?
Technical note: if a cracker gained access to a server via some hole or another, it's possible for him to install a specially modified hostile server which could attempt to exploit the OpenSSL hole in clients. This, however, is beyond the state of the art currently demonstrated by today's crackers. It's difficult to automate as part of a kit, and most of them are helpless without automated kits. The risk is theoretically present but, until we start seeing old-school technically-adept crackers again, IMHO very low.
When you think about updates, think about this: Windows has major updates regularly enough that people find the automatic update feature useful. Linux gets major updates that must be installed immediately infrequently enough that automatic updates aren't nearly so useful.
Example: the OpenSSL updates. Frankly, your average desktop user doesn't need to make them a priority. They're critical mainly for people who run servers which use SSL and are exposed to the public Internet. If you're using a hardware router with NAT, or have a standard desktop install and have enabled the recommended firewall settings on it, the outside world can't get at the ports to begin to exploit the OpenSSL bug.
As for deploying to a hundred million users, news flash: Unix admins were doing large-scale whole-enterprise rollouts back when MS's idea of a GUI was DOSSHELL. Of course we also figured out the right way to do it: have the applications installed centrally, so we could update them just once and have everyone pick up the changes automatically, and either run them centrally on large servers or make them available via network filesystems when people needed to run them locally. We also invented rdist and rsync to handle the cases where we couldn't install locally. The main reason Windows can't do the same is all the software that assumed it can blithely install device drivers and system DLLs and scribble on the system parts of the registry with impunity. Software that obeys MS's rules and will run as an ordinary, non-administrative user on WinXP should be quite amenable to centralized installation and maintenance.
NB: Unix people don't "get" the whole remote administration thing for similar reasons. We look at Unix, where there's little distinction between local and remote administration and you can administer a box on the other side of the Atlantic easily using the same tools you use to administer the box on your desktop, and wonder why, with 25 years of this behind us, anyone would deliberately break system design so badly that you'd need special tools for remote administration?
First problem: you assume that HTTP is the only protocol. It's not. What works for HTTP with a human being royally screws things up for a piece of hardware trying to do SNMP.
Second, your checkbox wouldn't work. The way Sitefinder works is by eliminating "site not found" errors. Since your browser would never see a "site not found" error, it'd never check whether to consult anything else.
Hard to run executable attachments being a lack-of-feature: no, it IS a feature. 99% of the Windows malware going around depends on users unwittingly running executable attachments. Making it easy for Linux users to suffer the same fate is NOT a feature, and in particular not a desirable one.
Application vs. OS: MS itself is the one that integrated the HTML component into the core OS. And they can't fix it, because things like Windows Help also use that component. If you fix the behavior for e-mail, you break Windows Help. If you leave the behavior available for Windows Help, it's also available in e-mail. This is the price you pay for integration, and it's a high one.
In that case you don't need SPF, since MTAs already have this capability. At least sendmail is capable of stripping out any Sender header the original sender supplied and filling in it's own with what it knows about the sender. The problem is that spammers could do the same thing, which means you still couldn't trust the Sender header to contain envelope information. This works only as long as the first MTA sends directly to the recipient's final mailserver, but breaks if you have to accomodate in-transit mailservers.
Travelling Mailman problem's solution's problem
on
Spoofed From: Prevention
·
· Score: 4, Insightful
He mentions the Travelling Mailman problem, that of being able to use your home e-mail address while not on your home network. His solution, having your home mailserver use authentication so that you always send via it, has it's own problem. The problem is Windows malware that e-mails itself out. Several large ISPs have responded to this by prohibiting the use of any mailserver but their own from inside their network. This puts me in a quandry: I wouldn't be able to use my domain while on my ISP's (Cox Cable) network because SPF would reject it, and I can't use my domain's mailserver because my ISP won't let me connect to it. This is, IMHO, a fatal flaw in the scheme.
Slashdot Mirror
Looking at the code as a programmer, some things stand out:
- The "copying" JBoss claims doesn't fit. There's differences in braces, keywords and other things that wouldn't be accounted for by automatic reformatting of code. I can't see a programm who's copying code directly going back in and doing that kind of editing. I'd expect braces to be maintained, for example, yet in several places they aren't.
- The similar names are obvious names for types, variables and functions. Given the same spec to start from, without having seen the JBoss code at all, I'd pick the same names.
- The places they cite as having code-structure similarity are very simple. Frankly, it looks to me like there's only one sane way to write that code.
It can't hurt to do a check, but I suspect JBoss is seeing copying where there's just only one obvious way to do something and most programmers, working independently, will make basically the same set of choices for that code.Unfortunately it's not ready for prime time yet. Problems in the current version of SUS include inability of the server to be selective about platforms, lack of configurability in what gets installed to which clients (think about an update which interferes with desktop software but which is fine and even required on servers where the software it interferes with isn't present), continual re-installing of the same updates, lack of support for the standard Windows Update interface and lack of full support for all the features of the Automatic Updates component (primarily non-scheduled updates).
It's typical MS: it fits well into the MS view of how the world should work but has major flaws which show up when it's faced with how everybody else really works.
Let me turn that around: why shouldn't the main IT staff at corporate be patching all corporate systems regardless of location? We do it all the time in the Unix world, and there's only a handful of things (the kernel, the remote access service itself) where there's any more risk doing it from half a world away than there is doing it locally. It's not rocket science, it's 30-year-old ideas, MS is the only ones who don't take this situation as a given. Which is why their patch system is so much of a pain.
Every service pack on NT, 2K and XP to date has broken at least one major third-party application, IIRC.
As far as testing, I'm afraid that no company that can put out multiple revisions of the same patch, all to fix mistakes in the original patch, within the span of a week or so can possibly be doing even cursory testing. As far as MS is concerned, paying customers seem to be the beta testers.
Windows Update is fine if you've just got 1 system. Now, imagine you've got to patch 30,000 systems in 700 offices in 43 states, and you don't have any access to the main keyboard. And you can't use automatic updates because IT has to vet the patches before they're installed to make sure they won't make inoperable third-party software which your business depends on being operational.
I don't wee the tug-o-war. There's two seperate issues:
- What the "correct" decision is at the end of the debate.
- Whether the debate should occur at all.
People can disagree on #1, but to get to that point you have to have debate. What Symantec is doing is saying that there should be no debate at all. As long as they're just a private company that's fine, but the instant filtering software became mandatory under penalty of law then that shutting down of the debate landed squarely in the middle of the First Amendment.If a position is so overwhelmingly correct that you can justify banning any arguments against it, you won't need to ban arguments against it. Conversely, if it's so weak that the only way it can prevail is to ban any argument against it, it's too weak to justify that ban.
They can distribute their code any way they please. The problem is, Linux contains other people's code, and they've only licensed it to be distributed under the GPL. SCO has no ownership interest in any code they didn't write, and no other law gives them any rights to it, so unless they agree to the GPL they're limited to the rights they'd have under copyright which specifically exclude the right to redistribute without permission.
What you can do with your code doesn't affect what you can do with my code.
Less bloated? You can't get much less bloated. For example, when an X client wants to display a string, the packet that gets sent to the server contains:
- The "display string" command byte.
- The string itself.
- The co-ordinates to start drawing the string at.
- The font ID to use (the font itself is already present in the server).
If client and server are on the same machine this command packet will go through a local-domain socket with just about zero overhead. If you used the traditional Windows model, the client would be making a call into the GDI libraries with the same parameters, and about the same overhead as X.The rest of X follows similar models, with the client-to-server packet contents reduced to similarly abstract views of what's desired. So where exactly is the bloat?
Why would we want to remove the remote-windowing capability. Current reality is that one of the biggest headaches companies have is keeping all those installations of software updated with the latest patches. With X, you can remove the software entirely from the client machines and install it on one central server, yet still seamlessly have people run it and have it appear as if it was on their local machine. Updates only have to be applied to the central server's installation and they appear to users the next time they run the software. No more headaches trying to patch hundreds of clients.
This is why X was designed the way it was. In fact, this was the way X was originally used, when "turbo" meant you had a CPU that could run at 8MHz.
Those who refuse to learn from the past are doomed to repeat it... poorly. :)
As I said, I think SCO will have a hard time proving even that they have any control over AIX-derived code. The thing is, courts consistently rule that when you license something to someone, that license isn't exclusive unless the contract explicitly says it's exclusive. Nothing in the IBM-SCO contract says anything about exclusivity, so the court's unlikely to rule that SCO has any control over IBM's code or any ability to limit IBM's use or distribution of their own code. I seriously doubt SCO can show that any code they wrote as part of JFS went anywhere but their own OSes, so I don't see where they're going to get even to square 1.
I think you're incorrect on the JFS code issue. JFS predates the existence of SCO. As I understand it, IBM licensed the JFS code to SCO as part of a joint development effort, and SCO is now claiming that this gives them control over that code and anything else that IBM might decide to use it in. There's also the complication that there are two different JFS implementations within IBM: the original from their mainframe and AIX systems, and the clean-room implementation used in OS/2. The OS/2 code was the basis for the contribution to Linux, so even if SCO manages to prove their claim in the case of the AIX code (highly unlikely, given existing case law) they'd then have to argue that IBM vs. Phoenix Technology (the seminal clean-room reimplementation case that allowed the creation of clones on the IBM PC) was incorrect, and they're unlikely to be able to successfully argue that.
No, they care very much about getting the right results. The problem lies in the definition of "right". Depending on local politics, a system where it's always possible to determine exactly how the recorded result differed from the actual votes may be very much the wrong system... from the POV of the election officials. Think Tammany Hall.
It might not even be a competitor. For example, Fry's in the US sells Microsoft Windows. They're entirely within their rights to use the term "Microsoft Windows" in their ads to identify what they're selling, even though they don't hold the trademark on "Microsoft Windows". Buying a text ad keyed on that term would, IMHO, fall well within that same allowance.
Verisign has a problem with how ICANN and the technical community want the gTLD nameservers run. Perhaps ICANN should take steps to insure that their views no longer cause Verisign any issues, say by handing the relevant gTLDs over to another registry operator.
In the meantime, ISAGN for an RFC on DNS that says, basically, "If the zone for a domain does delegation to people other than the zone's owner, that zone can't contain wildcard RRs unless everyone with subdomains below it agrees to them. Also, you can return RRs for names in the zone but you can't return RRs for names in undelegated subdomains unless everyone with subdomains below you agrees to them (eg. Verisign could return an A record for "www.com" but not for "www.unregistered-domain.com").".
It's the same way a used-car salesman gets you to buy a car even when it's got questionable things about it: high-pressure sales tactics. Salescritters know most people are reluctant to just turn their backs on someone and walk away. It's rude. Similarly, it's rude to just hang up the phone when someone's talking so most people will only do so when the situation becomes utterly intolerable. So the salescritters get you on the line and tighten the screws, putting you in the position of either buying something or being inexcusably rude to them, betting that a certain nontrivial percentage of people will cave in rather than go against a lifetime of social conditioning against rudeness.
That's land-line. On my cel phone, all calls regardless of direction cost air-time. Plan air-time is 6.7 cents/minute under my plan. Air-time after plan minutes are exhausted is 50 cents/minute.
I suspect a judge would also be rather sympathetic to the argument "I don't need more air-time every month than I'm buying on my current plan. Why should I pay more every month for a larger plan just so that telemarketers don't have to pay the 50 cent/minute rate to bother me?".
You've got them if they admitted that they called you and got "no answer" or "answering machine". It's the incoming call that costs, not your answering it, and by admitting they got the machine or no answer they've admitted that they made the call and caused you to incur the cost. Combine their admission that they made the call with the proof on the bill that that call cost a specific amount, and small-claims court should be a slam-dunk for all those calls after the one where you told them not to call that number again.
This idea won't fly. The reason is simple: money. On landlines it costs nothing to receive a call, so consumers can complain but that's about it as far as the telephone carriers are concerned. Cel phones and SMS are a different story. When a telemarketer calls a cel phone or sends a text message, the phone's owner can point to a line on his bill and say "This unwanted call/message cost me $X.". Now the phone owner has proof of an actual dollar amount to go with his complaint, and he can demand reimbursement. If the phone carrier reimburses, it's going to turn telemarketing into a cost for the carriers and they're going to do something about it. If phone carriers refuse to reimburse, we'll see something like the junk-fax law passed ASAP. One way or another, when the telemarketers start generating provable costs to the recipients of their calls there's going to be a major backlash against the telemarketers.
Telemarketers, take note: if you won't compromise, if you insist that it's either no limits at all or nothing, you may find that the rest of us consider giving you nothing at all a perfectly acceptable outcome. :)
My reply to the author would be this: The GPL is a license, just like the license on any piece of software. Cisco and Broadcom knew it's terms and accepted them when they used GPL'd software in their products, just like any other company would know the terms of the licenses of software they use in their products. Are you saying that people who pirate Windows, who pirate songs and movies, who pirate any software in violation of the license terms, are right and that Microsoft, the RIAA and MPAA, Eolas and the rest are wrong in trying to enforce their licenses and prevent license violations?
Technical note: if a cracker gained access to a server via some hole or another, it's possible for him to install a specially modified hostile server which could attempt to exploit the OpenSSL hole in clients. This, however, is beyond the state of the art currently demonstrated by today's crackers. It's difficult to automate as part of a kit, and most of them are helpless without automated kits. The risk is theoretically present but, until we start seeing old-school technically-adept crackers again, IMHO very low.
When you think about updates, think about this: Windows has major updates regularly enough that people find the automatic update feature useful. Linux gets major updates that must be installed immediately infrequently enough that automatic updates aren't nearly so useful.
Example: the OpenSSL updates. Frankly, your average desktop user doesn't need to make them a priority. They're critical mainly for people who run servers which use SSL and are exposed to the public Internet. If you're using a hardware router with NAT, or have a standard desktop install and have enabled the recommended firewall settings on it, the outside world can't get at the ports to begin to exploit the OpenSSL bug.
As for deploying to a hundred million users, news flash: Unix admins were doing large-scale whole-enterprise rollouts back when MS's idea of a GUI was DOSSHELL. Of course we also figured out the right way to do it: have the applications installed centrally, so we could update them just once and have everyone pick up the changes automatically, and either run them centrally on large servers or make them available via network filesystems when people needed to run them locally. We also invented rdist and rsync to handle the cases where we couldn't install locally. The main reason Windows can't do the same is all the software that assumed it can blithely install device drivers and system DLLs and scribble on the system parts of the registry with impunity. Software that obeys MS's rules and will run as an ordinary, non-administrative user on WinXP should be quite amenable to centralized installation and maintenance.
NB: Unix people don't "get" the whole remote administration thing for similar reasons. We look at Unix, where there's little distinction between local and remote administration and you can administer a box on the other side of the Atlantic easily using the same tools you use to administer the box on your desktop, and wonder why, with 25 years of this behind us, anyone would deliberately break system design so badly that you'd need special tools for remote administration?
First problem: you assume that HTTP is the only protocol. It's not. What works for HTTP with a human being royally screws things up for a piece of hardware trying to do SNMP.
Second, your checkbox wouldn't work. The way Sitefinder works is by eliminating "site not found" errors. Since your browser would never see a "site not found" error, it'd never check whether to consult anything else.
Hard to run executable attachments being a lack-of-feature: no, it IS a feature. 99% of the Windows malware going around depends on users unwittingly running executable attachments. Making it easy for Linux users to suffer the same fate is NOT a feature, and in particular not a desirable one.
Application vs. OS: MS itself is the one that integrated the HTML component into the core OS. And they can't fix it, because things like Windows Help also use that component. If you fix the behavior for e-mail, you break Windows Help. If you leave the behavior available for Windows Help, it's also available in e-mail. This is the price you pay for integration, and it's a high one.
In that case you don't need SPF, since MTAs already have this capability. At least sendmail is capable of stripping out any Sender header the original sender supplied and filling in it's own with what it knows about the sender. The problem is that spammers could do the same thing, which means you still couldn't trust the Sender header to contain envelope information. This works only as long as the first MTA sends directly to the recipient's final mailserver, but breaks if you have to accomodate in-transit mailservers.
He mentions the Travelling Mailman problem, that of being able to use your home e-mail address while not on your home network. His solution, having your home mailserver use authentication so that you always send via it, has it's own problem. The problem is Windows malware that e-mails itself out. Several large ISPs have responded to this by prohibiting the use of any mailserver but their own from inside their network. This puts me in a quandry: I wouldn't be able to use my domain while on my ISP's (Cox Cable) network because SPF would reject it, and I can't use my domain's mailserver because my ISP won't let me connect to it. This is, IMHO, a fatal flaw in the scheme.