Yes, I do, and my decision is that distributing his films would not be profitable because of the tawdry nature of his films. He should seek the use of someone else's property to distribute films. He is in no way limited to using my distribution company even though he may prefer mine over any others. Or Miramax's.
Only governments can censor, because only a government can create the anti-monopoly needed to stop everyone from distributing his films. Surely you have heard someone say "I am being censored!" They are lying, obviously, because you have heard them. -russ
It was already a "problem" at the 1986 X Conference. Bob Scheifler specifically emphasized it in his talk. "It's Window System called X, not X Windows." -russ
No, it's Linux. We don't just call it that, it *is* that. If you replaced everything on Solaris with GNU programs, it would still be Solaris. If you replaced everything on FreeBSD with GNU programs, it would still be FreeBSD. Only in RMS's pointy little head (and his syncophants) does Linux become GNU/Linux simply because Linux ships with GNU programs. -russ
o It's far from trivial to spoof DNS queries. If spoofing is a concern, then run djbdns instead of BIND. djbdns's cache uses 32-bit identifiers by incorporating the source port into the id.
o DomainKeys allows user-level granularity. You can use as many keys as you want to administer.
Moore was told very early on that Miramax would not distribute his film. He chose to make a big deal about it so that the film would get more attention. I would note that I, also, am not distributing any Moore films. Am I censoring Michael Moore? -russ
Sigh, no. First, it's worthwhile to Yahoo, because so many people forge Yahoo email. Because Yahoo will be an early adoptor, anybody who is blocking Yahoo but would really rather not need merely check the signature on Yahoo email, and refuse it if it's unsigned. Second, it will be worthwhile to Paypal, because you'll be able to trust email From: service@paypal.com because it'll be cryptographically signed. Third, even before everyone is sending signed email, you'll be able to hold unsigned email to a higher standard. If it's not signed and it smells even a little like spam, it's spam. -russ
The problem is that somebody could then patent it. So, then, you say "Well, Yahoo should patent it, and put the patent in the public domain." That's nice, but if you read the patent grant, it says that if you use DomainKeys, and somebody thinks you're infringing their patent, and they sue you, *Yahoo* (deep corporate pockets) can sue them for infringing Yahoo's patent license.
The trouble with the patent office is that they have completely lost the concept of unpatentable subject matter. -russ
DK-signed email is signed with a selector, which is a name of a private/public key pair. You get the public key by looking up selector._domainkey.example.com. You can have as many current keys as you want.
Yes, a spammer could replay the message, but you'll get a DNS lookup from every recipient. Might want to publish a per-person selector so you have accountability, or watch the DNS lookups to do rate limiting.
This isn't encryption, it's authentication. Only encryption is prohibited by export laws. And anyway, my library uses openssl which is not under the control of US export laws.
Mailing lists don't *have* to damage the signed section of incoming email. But yes, it might prove necessary to rely on the Sender: header; trouble there is that not enough MTAs show the Sender: header. -russ
Yes, they have applied for a patent. That's why they're giving everybody a patent grant. They don't plan to make any money from licensing the software, but instead they plan to change their response to complaints about forged Yahoo mail from "sorry" to "well, install DK, then". -russ
Read the license more closely. You have to sue someone (not just Yahoo) over your patent needed to implement DomainKeys. We fought hard to make it irrevocable, but the lawyers thought this license protected open-source interests best. -russ
Yes, you will need the ability to publish TXT records. SPF, EMail Caller ID, FreeS/WAN, and DomainKeys all require TXT records, so you won't be the only person beating up your DNS service to get the ability to publish them.
No, DomainKeys does not require reverse DNS. -russ
It's quite possible for a site to give a separate selector (public and private key pair identifer) to each user. That would let you verify that the sender is the real sender. The trouble right now is that we have no way to advertise that policy. We need a policy advertisement specification, and we're trying to have DomainKeys NOT be that spec.
DomainKeys signs the entire message, not just the From: header. DomainKeys lets anybody send regardless of IP address as long as they have a private key whose public key is published under that domain. A domain may have multiple keys, and generating a new key takes but a second.
The trouble with SPF is that it's based on IP addresses, and forwarding completely breaks SPF. That's why they need SRS in order to be able to forward at all.
It's not that your opinion isn't popular with me. It's that your opinion is wrong. Let me try another tactic:
You act as if there is a fixed amount of work, so that if a job appears in one country, a job must disappear from another country. If that were the case, how is it that new jobs are created? -russ
Slashdot Mirror
Yes, I do, and my decision is that distributing his films would not be profitable because of the tawdry nature of his films. He should seek the use of someone else's property to distribute films. He is in no way limited to using my distribution company even though he may prefer mine over any others. Or Miramax's.
Only governments can censor, because only a government can create the anti-monopoly needed to stop everyone from distributing his films. Surely you have heard someone say "I am being censored!" They are lying, obviously, because you have heard them.
-russ
Uhhhhh..... who ever said anything about KDE being Linux? KDE is an application, and Linux is an OS.
-russ
Uhhhhhhhh, so now everybody has to have both an SPF and an XML parser in their MTA? And that's an improvement ... how?
-russ
Dude, there's a gazillion formats which can be extensible and self-documenting. XML is a religion, and you obviously drank the kool-aid.
-russ
Uhhhhhhhh, because a DNS packet is limited to 512 octets??
-russ
Yes, coroutines in assembly are trivial. But then, unlike the kids around here, we're experienced programmers. Hehe.
-russ
No, you mean the Apple Lisa had Windows(R).
Windows is a registered trademark of the Microsoft Corporation.
It was already a "problem" at the 1986 X Conference. Bob Scheifler specifically emphasized it in his talk. "It's Window System called X, not X Windows."
-russ
No, it's Linux. We don't just call it that, it *is* that. If you replaced everything on Solaris with GNU programs, it would still be Solaris. If you replaced everything on FreeBSD with GNU programs, it would still be FreeBSD. Only in RMS's pointy little head (and his syncophants) does Linux become GNU/Linux simply because Linux ships with GNU programs.
-russ
A few misconceptions.
o It's far from trivial to spoof DNS queries. If spoofing is a concern, then run djbdns instead of BIND. djbdns's cache uses 32-bit identifiers by incorporating the source port into the id.
o DomainKeys allows user-level granularity. You can use as many keys as you want to administer.
Moore was told very early on that Miramax would not distribute his film. He chose to make a big deal about it so that the film would get more attention. I would note that I, also, am not distributing any Moore films. Am I censoring Michael Moore?
-russ
DomainKeys.
-russ
Sigh, no. First, it's worthwhile to Yahoo, because so many people forge Yahoo email. Because Yahoo will be an early adoptor, anybody who is blocking Yahoo but would really rather not need merely check the signature on Yahoo email, and refuse it if it's unsigned. Second, it will be worthwhile to Paypal, because you'll be able to trust email From: service@paypal.com because it'll be cryptographically signed. Third, even before everyone is sending signed email, you'll be able to hold unsigned email to a higher standard. If it's not signed and it smells even a little like spam, it's spam.
-russ
The problem is that somebody could then patent it. So, then, you say "Well, Yahoo should patent it, and put the patent in the public domain." That's nice, but if you read the patent grant, it says that if you use DomainKeys, and somebody thinks you're infringing their patent, and they sue you, *Yahoo* (deep corporate pockets) can sue them for infringing Yahoo's patent license.
The trouble with the patent office is that they have completely lost the concept of unpatentable subject matter.
-russ
DK-signed email is signed with a selector, which is a name of a private/public key pair. You get the public key by looking up selector._domainkey.example.com. You can have as many current keys as you want.
Yes, a spammer could replay the message, but you'll get a DNS lookup from every recipient. Might want to publish a per-person selector so you have accountability, or watch the DNS lookups to do rate limiting.
This isn't encryption, it's authentication. Only encryption is prohibited by export laws. And anyway, my library uses openssl which is not under the control of US export laws.
Mailing lists don't *have* to damage the signed section of incoming email. But yes, it might prove necessary to rely on the Sender: header; trouble there is that not enough MTAs show the Sender: header.
-russ
Is this written in an RFC anywhere?? Appending headers is Just Wrong(tm).
Yes, they have applied for a patent. That's why they're giving everybody a patent grant. They don't plan to make any money from licensing the software, but instead they plan to change their response to complaints about forged Yahoo mail from "sorry" to "well, install DK, then".
-russ
Read the license more closely. You have to sue someone (not just Yahoo) over your patent needed to implement DomainKeys. We fought hard to make it irrevocable, but the lawyers thought this license protected open-source interests best.
-russ
Yes, you will need the ability to publish TXT records. SPF, EMail Caller ID, FreeS/WAN, and DomainKeys all require TXT records, so you won't be the only person beating up your DNS service to get the ability to publish them.
No, DomainKeys does not require reverse DNS.
-russ
It's quite possible for a site to give a separate selector (public and private key pair identifer) to each user. That would let you verify that the sender is the real sender. The trouble right now is that we have no way to advertise that policy. We need a policy advertisement specification, and we're trying to have DomainKeys NOT be that spec.
DomainKeys signs the entire message, not just the From: header. DomainKeys lets anybody send regardless of IP address as long as they have a private key whose public key is published under that domain. A domain may have multiple keys, and generating a new key takes but a second.
The trouble with SPF is that it's based on IP addresses, and forwarding completely breaks SPF. That's why they need SRS in order to be able to forward at all.
In the short-term, you're right. In the longer term, when spammers can't lie about who they are, we'll have an easier time blocking them.
-russ
Not for many years, and by then your MTA will have implemented DomainKeys.
It's not that your opinion isn't popular with me. It's that your opinion is wrong. Let me try another tactic:
You act as if there is a fixed amount of work, so that if a job appears in one country, a job must disappear from another country. If that were the case, how is it that new jobs are created?
-russ