Why couldn't "a technological measure" refer to SpamAssasin?
The question then, what copyrighted material does spamassasin protect?
Since they are sending YOU something, it doesn't. (Unless you have an autoresponder that sends a copyrighted work to whoever sends you email.)
my email address is not necessarily a fact, since I do run my own server and have the ability to change it whenever I like.
Yes, it is necessarily a fact. Just because you can change something doesn't mean that it's not a fact.
Changeability isn't a test of copyrightability, in any case. Think about what you're saying "I can change something, so therefore I can copyright it." You might as well say "I can eat something, so therefore I can ignore it." The two have no bearing on one another.
if I sold you that contract in the first place, I can't exactly claim to be ignorant of the entire relationship, can I?
I wasn't aware that you could sell a contract.
If you were a party to the contract, then sold it to someone (provided the contract permitted transfer of party) then you might have a point, but I've worked in the software world - there's no contract saying you must take it back if someone returns it.
If you sold a piece of paper, then you sold a piece of paper. A contract is an agreement.
you bought it and have the right to use it, but you do not have the right to copy it.
Actually, you DO have the right to copy it for personal use. It falls under the classification of fair use.
Some court case held that loading the program into RAM qualified as copying.
True. The case in question also was also about a third party (in this case a contractor) using the software... the contractor was "making a copy", and since he didn't "own" the software, the "copy" he made when he used the program was considered infringing.
You need additional license to copy the program into RAM
Copyright law has since been revised to remove this loophole. (Limited copies of computer programs can lawfully be made for archival purposes or "as an essential step in the utilization of the computer program in conjunction with a machine." 17 U.S.C. 117.)
I could be completely wrong. Someone please correct me otherwise.
Do you see a contradiction in RMS's pressure to have people prefix Linux with GNU (credit where credit is due), and his assertion that the BSD license isn't (wasn't?) "Free" because it forced you to include copyright notices (which is also "credit where credit is due")?
as commercial speech, spam isn't entitled to any particular first amendment protection
It doesn't matter if it's entitled to protection or not - it's theft.
The first amendment guarantees the right to say whatever you want - it does not guarantee the right to an audience, or to force people to pay to hear you. (Both of which apply better to spam than "commercial speech.")
The whole "free speech" argument is a red herring.. spam is as deserving of "free speech" as any other type of harrassment - which is to say NONE.
I don't see why the e-mail clients need to do the work.
An email client needs to do the work, because it's the only thing that can verify that the person doing the sending is actually the person doing the sending.
Imagine this scenario:
Someone (mail client) gives you (mail server) a letter that claims to be from me. How do you verify that it actually came from me? You look for my signature. If I haven't signed it, there is nothing you can do to verify that I am in fact the originator of that letter.
Using electronic signatures to verify a sender can only work if the sender is the one to do the signing.
Without a server, there is no connection to the network, so they are the conduit.
But a server CANNOT verify identity, because the server didn't originate the email.
Validation can and should be done there
No, if you think that validation can be done there, then you simply don't understand crypto.
How can anything verify a fact that it doesn't know is true?
Why do you say this?
BECAUSE IT'S TRUE
The servers must know if an e-mail address or a bounce address exists in order to deliver the e-mail to the recipient.
No, they don't. A mail server doesn't know if an address is valid until it attempts to send mail to it
So a request of the server responsible for receiving e-mail to a given address can provide the verification that is was indeed sent
Read my other posts. The mail server responsible for receiving email to a given address cannot be guaranteed to know if any particular address is valid or not.
Here's a tip:
Go buy the Oreilly Sendmail book. Read it cover to cover, and understand how a mail server actually works.
Then come and argue your points.
Re:They're just not saying, 'cause...
on
Baked Apple
·
· Score: 2, Insightful
Apple has a danged clear set of policies about dealing with customers -- you don't ridicule and you don't bitch
So you can't ask a question without ridiculing or bitching?
How about "Can you tell us why it was in the oven?"
That's the route this verification process should probably follow.
Bounced mail goes to whoever's email address is on the envelope. (The envelope isn't part of the email, it's created from the SMTP commands sent to the mail server.)
If you want your mail server to block bogus envelope-from addresses, simply configure it to do a VRFY on envelope-FROM.
This is already do-able without relying on encryption; however, many existing mail servers disable VRFY, as it can be used by spammers to get lists of valid addresses (although if spam were eliminated, this wouldn't be a problem) - note that it also breaks some setups (see my earlier email with the example of our customer in the Arctic.) Another drawback is that it can't stop people from using forged email addresses.
I've given some thought to your original proposal, and I think I understand what you're trying to do, and you've overengineered it.. here's how it should be done:
All email clients (not servers, as in your post) must include PGP (or something similar), and all email must be signed. It's useless to try to do this between servers, as the servers can't verify if someone sent an email or not.
All email servers must include PGP functionality - they must be able to check that the signature for an address is valid. Note that this isn't a trivial step.
Basically, whenever an email comes into a mail server, it must check that the PGP signature is valid - this will solve your problem of forged email addresses.
This is pretty simple in theory, but (as the saying goes) the difference between theory and reality is that in theory, there is no difference between theory and reality:o)
You need a reliable PKI You need to get all mail clients to use the PKI You need to get all servers to use the PKI
Note that it (probably) won't do a damn thing to stop spam, as spam is a social problem, not a technological one. All you'll do is force the spammers to use PGP and throwaway email addresses.
As I understand it, the "From" field and "Reply-to" fields don't have to be the same.
It's not that they don't have to be the same, it's that they don't have to contain valid (or any) information - or even exist (an email without a "From:" and/or "Reply-To:" is perfectly legal.)
Mail servers don't use any fields in the email header to route mail - they use the email envelope to do that.
wouldn't e-mails from non-existent domains or domains not associated with the server indicated by the TCP info be the easiest to block?
Yes, however there is no guarantee that the sending mail server is authoritative for the domain - in the case of SMTP smart-hosts, or forwarders, for example.. you'd be blocking lots of legitimate mail...
Blocking mail based on a non-existant domain is against the applicable RFCs - what happens if a domain's DNS servers are unreachable?
How does an e-mail address get resolved?
An email address gets resolved as follows:
The mail server looks at the domain. It then does a DNS lookup on the domain, checking for the 'best' MX (mail exchanger) record.
MX records each have a priority.. the mail server starts with the lowest number (highest priority) server.
If a mail server is unreachable, or gives a temporary error message, the mail server continues with the next-best mail exchanger for the domain - if all mail servers are unreachable, or give temporary errors, then the server queues the mail, to attempt delivery at a later date. (Most mail servers try every 15 minutes for a few days, then bounce the email.)
Once a mail server for the domain is reachable, the sending mail server simply gives it the email, telling who it's from, and who it's for..
It's important to note that the mail server that the sending server delivers the mail to may not know if the email address is valid (in the case of a backup mail server, or mail hub, for example.)
Now, with all of this in mind, this still has no bearing on whether you use crypto or not... the reason I asked that question was because I fail to see how a server can guarantee something that it doesn't know, simply by using crypto.
1. If the sending server doesn't serve the domain, then it's a bogus return address.
Incorrect assumption. If the sending server doesn't serve the domain (I assume you mean the sender's domain) this is no guarantee of the return address being bogus or not.
2. If the server does handle the domain, but the e-mail address itself isn't recognized, it's a bogus return address.
A better assumption, but still wrong, as it ignores mail hubs or backup mail servers that operate as smarthosts. (A smarthost is a mail server that's operated by a provider, that their clients can use to send mail through.)
I operate an ISP. We have clients that can only get dialup connectivity (north of the arctic circle), and they run their own mail server (for speed.) Our mail server is their primary (and only) MX. A few times a day, their mail server will dial the internet, and collect the email destined for their domain, and deliver it locally. Then it delivers any outbound email, only to avoid queuing the mail unneccessarily, it sends all of it's outbound mail to our mail server, to forward to the appropriate server.
Your assumption would break this arrangement, because our mail server is a MX for the domain, but doesn't have any knowledge of which email addresses are valid or not.
The sending server does not have to keep keys around. It uses a standard process to create a content key from the contents of the e-mail before it is sent. It uses a private key plus this e-mail key to create the validation key that is sent with the e-mail. The receiving server reconstructs the content key that is sent back to the originating server, along with the embedded validation key. Then the originating server simply uses the content key and its private key to reconstruct the validation key and if they match, the e-mail is valid!
No - again, there's no reason to bother with keys at all.
Assuming that all three of your assumptions above are correct (which they aren't.) There's still no reason to use crypto, unless you kept all the keys around. Otherwise to verify that an email actually came from a server, you'd have to transmit both the mail's key, and the mail itself (so that the server can check it.)
If a mail server makes a key for an email, then sends it to another server, the only thing the key can possibly be used for is to check that the mail hasn't been corrupted in transit - which the TCP protocol already does.
I think you have a fundamental misunderstanding of both SMTP and cryptography.
For your solution to work, the mail would have to be signed by the sender's mail client, not the sending server.
I get almost exclusively SPAM with spoofed return addresses. How about this solution:
OK, I read your solution a couple of times. I'm still a bit puzzled about how it's supposed to solve your problem.
You're basically having an SMTP server sign the email... how (exactly) will that prevent someone from spoofing their return address? From your description, all you're doing is using cryptography to ensure that the mail server that's sending the mail is in fact the mail server that's sending the mail... but this is pretty much guaranteed by the TCP protocol, and doesn't address the spoofability of an email address at all.
How does using crypto between servers ensure that an email address isn't spoofed?
If your goal is to make sure that a mail server is an authoritative mail server for a domain (which your approach doesn't do - at least not the way you described it), why not simply do a MX lookup? It's faster, easier, and doesn't involve changing the protocol.
The keys are in place to keep the SPAMmer from tagging along on a valid return address with mail that address didn't send
How, exactly does the server know whether the "email address" sent email or not? Are you suggesting that the mail servers keep a list of keys around indefinitely? What happens if you use a different server? (Perhaps clustering, or from a 'road warrior', who's sending email from a hotel on the other side of the country?)
I'm not trying to flame you, I just fail to see how you can authenticate a peice of information (an email) when you're only working with two intermediaries (the mail servers), and not at all with what's generating the information in the first place.
It *is* security through obscurity, as is a password.
NO A password is NOT security through obscurity.
If you believe it is, then you simply don't know what obscurity really is.
"Obscurity" is reliance on hiding information, in the hopes that nobody finds it. Since a properly-administered password scheme (such as storing the password hash) is not hiding anything, then it's not obscurity.
Windows and Linux interpret font sizes differently
Actually, no. Internet Explorer interprets font sizes differently than everything else..
what looks good on windows just looks too small on Linux, and we have to zoom in to the page
Again, what looks good on IE looks too small on Netscape.. it's a result of the browser wars.. MS deliberately made the equivalent font sizes one size larger, so if someone was designing a page and viewing it only with IE, they'd make the fonts too small to be readable on Netscape, to 'encourage' Netscape users to switch.
If you want the consumer-grade stuff (the 3com or dlink RTUs that you buy to hook up to your telco's network), then no. They need a DSLAM.
If you want to spend a few bucks ($1000 per end), Adtran makes some good HDSL gear - such as the Express-L768, and Express-L1.5, that will do what you want. The L-768 is probably what you want, as it uses a single pair, and runs 768K bidirectional. (The 1.5 runs at 1.5M, but uses 2 pairs.. it can also run 768K on a single pair.)
We use these at a number of sites, and they work pretty well.
There are caveats.. the maximum distance you can drive them is 18000 feet.. and if you're leasing copper from the telco, you have to watch the distance.. the telco here bills length as crow-flies distance, so unless you know their distribution network, you may not know the exact footage.. for example, we have two schools that are about 3 feet away from each other (next door), but the actual cable distance was over 20000 Feet. (The copper for each site runs back to the telco's distribution point.)
If you own the land between the sites, I'd do as another poster suggested, and run fiber)
Where in the Constitution is Freedom of Privacy stated? You may be able to infer it from other amendments but it is not nearly as clearly stated as Freedom of Speech.
The previous poster is clearly in error. "Freedom of speech" is a diversion - this has absolutely nothing to do with free speech.
"Freedom of speech" means "you can say what you want." It does not mean "you can force people to listen to you."
If someone says "I don't want to hear from you", you can't force them to listen by claiming "free speech." Since that is exactly what a DNC list is, the whole "free speech" argument is BS.
Yes, it validates your email address. So does the fact that the spam didn't bounce
Yeah, because spammers would never use a fake From: or Reply-To: address, right?
Spammers never see their bounce messages, because they relay-rape someone server in Korea, and/or use fake addresses, so the bounce messages go somewhere else.
They ran out of money for the Aztec 3/4 of the way back:)
I had the same thought about the Honda CRX, about 10 years ago.. or, I figured the designers took the blueprints to management, management said "hmm, it won't fit in our manufacturing bays!" so the designers said "No problem", and tore off the rear 1/4 of the blueprint.
In any case, the first time I saw an Aztek, I thought - "Ahh, so that's what a CRX looks like when it grows up!" (Which also explains why you never see CRXs on the road anymore:o)
Does anyone believe for a second that MS will allow things like bnetd to continue to exist?
OK, I'm usually the first guy to bash MS, but in this case, I think it might be good for bnetd.
MS doesn't usually try to bully it's competition through the use of fraudulent lawsuits.. it bullies them in other ways..
The bnetd lawsuit is basically groundless - Vivendi claims that the bnetd guys stole their server code, but the only "proof" is that the code does the same thing.. (which it's supposed to) if the code really was (c)Vivendi, then they'd just look at the bnetd code (which they have access to, because it's open source), look at their server code, and say "see, it's the same"... instead they construct some cock-and-bull "it has the same bugs" story - without any reference as to how someone from bnetd managed to break into their servers, and steal one tiny piece of their server code.
MS really does things differently... yes, they have a ton more money to throw at the lawyers, but I'd be surprised if those lawyers didn't take a look at the merits of the case and just say "don't push this - find another way to bury it"
it would be illegal if they were to use the money (regardless of source) to buy up all the gaming companies and thus choke out the competition.
OK, maybe I missed something, but what's the difference between buying all the gaming companies one at a time, and buying them all at once?
Seems to me that if buying them all is illegal, then buying them one at a time would be illegal too - or do we wait until there is only one left, and say "you're not allowed to buy that one!"? (At which point it're pretty irrelevant, because one small company competing against a near-monopoly is pretty much doomed anyway.)
So, the question is - at what point do we say "Ok, now you're leveraging your monopoly?"
Your history may be correct, but you could think a bit more before posting, too
OK, I hate doing a "me too", but that's not really what I'm worried about..
Since they already have a competing product to battle.net, wouldn't they want to merge them into one service? If that's the case, what happens?
A) They kill Zone, and move everything over to battle.net (extremely unlikely) B) They kill battle.net, but (before doing so) add support for all it's games to Zone. C) They kill battle.net by adding support for current games (WC3, etc) to Zone, and by dropping support for older titles (Diablo 1)
In any case, things don't look good for battle.net..
Slashdot Mirror
The data on the CDs is still owned by the manufacturer (MS), and you must agree to their terms in order to legally use it.
Bullshit. I paid for it, it's mine.
They own the copyright, and that's all the leverage they have.
I didn't sign anything when I bought it, so any conditions they attempt to place upon me after the fact are null and void.
Why couldn't "a technological measure" refer to SpamAssasin?
The question then, what copyrighted material does spamassasin protect?
Since they are sending YOU something, it doesn't. (Unless you have an autoresponder that sends a copyrighted work to whoever sends you email.)
my email address is not necessarily a fact, since I do run my own server and have the ability to change it whenever I like.
Yes, it is necessarily a fact. Just because you can change something doesn't mean that it's not a fact.
Changeability isn't a test of copyrightability, in any case. Think about what you're saying "I can change something, so therefore I can copyright it." You might as well say "I can eat something, so therefore I can ignore it." The two have no bearing on one another.
if I sold you that contract in the first place, I can't exactly claim to be ignorant of the entire relationship, can I?
I wasn't aware that you could sell a contract.
If you were a party to the contract, then sold it to someone (provided the contract permitted transfer of party) then you might have a point, but I've worked in the software world - there's no contract saying you must take it back if someone returns it.
If you sold a piece of paper, then you sold a piece of paper. A contract is an agreement.
you bought it and have the right to use it, but you do not have the right to copy it.
:o)
Actually, you DO have the right to copy it for personal use. It falls under the classification of fair use.
Some court case held that loading the program into RAM qualified as copying.
True. The case in question also was also about a third party (in this case a contractor) using the software... the contractor was "making a copy", and since he didn't "own" the software, the "copy" he made when he used the program was considered infringing.
You need additional license to copy the program into RAM
Copyright law has since been revised to remove this loophole. (Limited copies of computer programs can lawfully be made for archival purposes or "as an essential step in the utilization of the computer program in conjunction with a machine." 17 U.S.C. 117.)
I could be completely wrong. Someone please correct me otherwise.
Consider yourself corrected
When you agree to the EULA, you get the right to use the software
But I already have the right to use the software - I got it when I purchased it.
Do you see a contradiction in RMS's pressure to have people prefix Linux with GNU (credit where credit is due), and his assertion that the BSD license isn't (wasn't?) "Free" because it forced you to include copyright notices (which is also "credit where credit is due")?
as commercial speech, spam isn't entitled to any particular first amendment protection
It doesn't matter if it's entitled to protection or not - it's theft.
The first amendment guarantees the right to say whatever you want - it does not guarantee the right to an audience, or to force people to pay to hear you. (Both of which apply better to spam than "commercial speech.")
The whole "free speech" argument is a red herring.. spam is as deserving of "free speech" as any other type of harrassment - which is to say NONE.
I don't see why the e-mail clients need to do the work.
An email client needs to do the work, because it's the only thing that can verify that the person doing the sending is actually the person doing the sending.
Imagine this scenario:
Someone (mail client) gives you (mail server) a letter that claims to be from me. How do you verify that it actually came from me? You look for my signature. If I haven't signed it, there is nothing you can do to verify that I am in fact the originator of that letter.
Using electronic signatures to verify a sender can only work if the sender is the one to do the signing.
Without a server, there is no connection to the network, so they are the conduit.
But a server CANNOT verify identity, because the server didn't originate the email.
Validation can and should be done there
No, if you think that validation can be done there, then you simply don't understand crypto.
How can anything verify a fact that it doesn't know is true?
Why do you say this?
BECAUSE IT'S TRUE
The servers must know if an e-mail address or a bounce address exists in order to deliver the e-mail to the recipient.
No, they don't. A mail server doesn't know if an address is valid until it attempts to send mail to it
So a request of the server responsible for receiving e-mail to a given address can provide the verification that is was indeed sent
Read my other posts. The mail server responsible for receiving email to a given address cannot be guaranteed to know if any particular address is valid or not.
Here's a tip:
Go buy the Oreilly Sendmail book. Read it cover to cover, and understand how a mail server actually works.
Then come and argue your points.
Apple has a danged clear set of policies about dealing with customers -- you don't ridicule and you don't bitch
So you can't ask a question without ridiculing or bitching?
How about "Can you tell us why it was in the oven?"
That's the route this verification process should probably follow.
:o)
Bounced mail goes to whoever's email address is on the envelope. (The envelope isn't part of the email, it's created from the SMTP commands sent to the mail server.)
If you want your mail server to block bogus envelope-from addresses, simply configure it to do a VRFY on envelope-FROM.
This is already do-able without relying on encryption; however, many existing mail servers disable VRFY, as it can be used by spammers to get lists of valid addresses (although if spam were eliminated, this wouldn't be a problem) - note that it also breaks some setups (see my earlier email with the example of our customer in the Arctic.) Another drawback is that it can't stop people from using forged email addresses.
I've given some thought to your original proposal, and I think I understand what you're trying to do, and you've overengineered it.. here's how it should be done:
All email clients (not servers, as in your post) must include PGP (or something similar), and all email must be signed. It's useless to try to do this between servers, as the servers can't verify if someone sent an email or not.
All email servers must include PGP functionality - they must be able to check that the signature for an address is valid. Note that this isn't a trivial step.
Basically, whenever an email comes into a mail server, it must check that the PGP signature is valid - this will solve your problem of forged email addresses.
This is pretty simple in theory, but (as the saying goes) the difference between theory and reality is that in theory, there is no difference between theory and reality
You need a reliable PKI
You need to get all mail clients to use the PKI
You need to get all servers to use the PKI
Note that it (probably) won't do a damn thing to stop spam, as spam is a social problem, not a technological one. All you'll do is force the spammers to use PGP and throwaway email addresses.
As I understand it, the "From" field and "Reply-to" fields don't have to be the same.
It's not that they don't have to be the same, it's that they don't have to contain valid (or any) information - or even exist (an email without a "From:" and/or "Reply-To:" is perfectly legal.)
Mail servers don't use any fields in the email header to route mail - they use the email envelope to do that.
wouldn't e-mails from non-existent domains or domains not associated with the server indicated by the TCP info be the easiest to block?
Yes, however there is no guarantee that the sending mail server is authoritative for the domain - in the case of SMTP smart-hosts, or forwarders, for example.. you'd be blocking lots of legitimate mail...
Blocking mail based on a non-existant domain is against the applicable RFCs - what happens if a domain's DNS servers are unreachable?
How does an e-mail address get resolved?
An email address gets resolved as follows:
The mail server looks at the domain. It then does a DNS lookup on the domain, checking for the 'best' MX (mail exchanger) record.
MX records each have a priority.. the mail server starts with the lowest number (highest priority) server.
If a mail server is unreachable, or gives a temporary error message, the mail server continues with the next-best mail exchanger for the domain - if all mail servers are unreachable, or give temporary errors, then the server queues the mail, to attempt delivery at a later date. (Most mail servers try every 15 minutes for a few days, then bounce the email.)
Once a mail server for the domain is reachable, the sending mail server simply gives it the email, telling who it's from, and who it's for..
It's important to note that the mail server that the sending server delivers the mail to may not know if the email address is valid (in the case of a backup mail server, or mail hub, for example.)
Now, with all of this in mind, this still has no bearing on whether you use crypto or not... the reason I asked that question was because I fail to see how a server can guarantee something that it doesn't know, simply by using crypto.
1. If the sending server doesn't serve the domain, then it's a bogus return address.
Incorrect assumption. If the sending server doesn't serve the domain (I assume you mean the sender's domain) this is no guarantee of the return address being bogus or not.
2. If the server does handle the domain, but the e-mail address itself isn't recognized, it's a bogus return address.
A better assumption, but still wrong, as it ignores mail hubs or backup mail servers that operate as smarthosts. (A smarthost is a mail server that's operated by a provider, that their clients can use to send mail through.)
I operate an ISP. We have clients that can only get dialup connectivity (north of the arctic circle), and they run their own mail server (for speed.) Our mail server is their primary (and only) MX. A few times a day, their mail server will dial the internet, and collect the email destined for their domain, and deliver it locally. Then it delivers any outbound email, only to avoid queuing the mail unneccessarily, it sends all of it's outbound mail to our mail server, to forward to the appropriate server.
Your assumption would break this arrangement, because our mail server is a MX for the domain, but doesn't have any knowledge of which email addresses are valid or not.
The sending server does not have to keep keys around. It uses a standard process to create a content key from the contents of the e-mail before it is sent. It uses a private key plus this e-mail key to create the validation key that is sent with the e-mail. The receiving server reconstructs the content key that is sent back to the originating server, along with the embedded validation key. Then the originating server simply uses the content key and its private key to reconstruct the validation key and if they match, the e-mail is valid!
No - again, there's no reason to bother with keys at all.
Assuming that all three of your assumptions above are correct (which they aren't.) There's still no reason to use crypto, unless you kept all the keys around. Otherwise to verify that an email actually came from a server, you'd have to transmit both the mail's key, and the mail itself (so that the server can check it.)
If a mail server makes a key for an email, then sends it to another server, the only thing the key can possibly be used for is to check that the mail hasn't been corrupted in transit - which the TCP protocol already does.
I think you have a fundamental misunderstanding of both SMTP and cryptography.
For your solution to work, the mail would have to be signed by the sender's mail client, not the sending server.
No flame taken.
OK, I was afraid I was being a little harsh..
I get almost exclusively SPAM with spoofed return addresses. How about this solution:
OK, I read your solution a couple of times. I'm still a bit puzzled about how it's supposed to solve your problem.
You're basically having an SMTP server sign the email... how (exactly) will that prevent someone from spoofing their return address? From your description, all you're doing is using cryptography to ensure that the mail server that's sending the mail is in fact the mail server that's sending the mail... but this is pretty much guaranteed by the TCP protocol, and doesn't address the spoofability of an email address at all.
How does using crypto between servers ensure that an email address isn't spoofed?
If your goal is to make sure that a mail server is an authoritative mail server for a domain (which your approach doesn't do - at least not the way you described it), why not simply do a MX lookup? It's faster, easier, and doesn't involve changing the protocol.
The keys are in place to keep the SPAMmer from tagging along on a valid return address with mail that address didn't send
How, exactly does the server know whether the "email address" sent email or not? Are you suggesting that the mail servers keep a list of keys around indefinitely? What happens if you use a different server? (Perhaps clustering, or from a 'road warrior', who's sending email from a hotel on the other side of the country?)
I'm not trying to flame you, I just fail to see how you can authenticate a peice of information (an email) when you're only working with two intermediaries (the mail servers), and not at all with what's generating the information in the first place.
It *is* security through obscurity, as is a password.
NO A password is NOT security through obscurity.
If you believe it is, then you simply don't know what obscurity really is.
"Obscurity" is reliance on hiding information, in the hopes that nobody finds it. Since a properly-administered password scheme (such as storing the password hash) is not hiding anything, then it's not obscurity.
The error here, believe it or not, isn't all upon Microsoft
No, but most of it is.
First off, they didn't patch. Microsoft had the patch available since June
Yes, this is true, but ignores the fact that Microsoft themselves were hit.
If the people who wrote the damn thing in the first place can't keep up with their own patches, why do you expect everybody else to be able to?
Microsoft explicitly warns users of SQL databases to not put them openly on the internet, for obvious reasons.
And again, MS is guilty of doing exactly what they tell others not to do... why?
And what exactly are those obvious reasons? Could one of them be "the software has too damn many holes"?
You can blame Microsoft for this if you want, but it isn't car companies' fault that people get killed because they can't drive.
No, but it is the car company's fault if thier car blows up in a minor collision. (Which is a much more fitting analogy, although still flawed.)
Windows and Linux interpret font sizes differently
Actually, no. Internet Explorer interprets font sizes differently than everything else..
what looks good on windows just looks too small on Linux, and we have to zoom in to the page
Again, what looks good on IE looks too small on Netscape.. it's a result of the browser wars.. MS deliberately made the equivalent font sizes one size larger, so if someone was designing a page and viewing it only with IE, they'd make the fonts too small to be readable on Netscape, to 'encourage' Netscape users to switch.
If you want the consumer-grade stuff (the 3com or dlink RTUs that you buy to hook up to your telco's network), then no. They need a DSLAM.
If you want to spend a few bucks ($1000 per end), Adtran makes some good HDSL gear - such as the Express-L768, and Express-L1.5, that will do what you want. The L-768 is probably what you want, as it uses a single pair, and runs 768K bidirectional. (The 1.5 runs at 1.5M, but uses 2 pairs.. it can also run 768K on a single pair.)
We use these at a number of sites, and they work pretty well.
There are caveats.. the maximum distance you can drive them is 18000 feet.. and if you're leasing copper from the telco, you have to watch the distance.. the telco here bills length as crow-flies distance, so unless you know their distribution network, you may not know the exact footage.. for example, we have two schools that are about 3 feet away from each other (next door), but the actual cable distance was over 20000 Feet. (The copper for each site runs back to the telco's distribution point.)
If you own the land between the sites, I'd do as another poster suggested, and run fiber)
Where in the Constitution is Freedom of Privacy stated? You may be able to infer it from other amendments but it is not nearly as clearly stated as Freedom of Speech.
The previous poster is clearly in error. "Freedom of speech" is a diversion - this has absolutely nothing to do with free speech.
"Freedom of speech" means "you can say what you want." It does not mean "you can force people to listen to you."
If someone says "I don't want to hear from you", you can't force them to listen by claiming "free speech." Since that is exactly what a DNC list is, the whole "free speech" argument is BS.
I don't think MySQL is susceptible to this worm
It's also not suitable for 90% of the work that SQL-server does.
Maybe if you'd said Postgres..
Yes, it validates your email address. So does the fact that the spam didn't bounce
Yeah, because spammers would never use a fake From: or Reply-To: address, right?
Spammers never see their bounce messages, because they relay-rape someone server in Korea, and/or use fake addresses, so the bounce messages go somewhere else.
They ran out of money for the Aztec 3/4 of the way back :)
:o)
I had the same thought about the Honda CRX, about 10 years ago.. or, I figured the designers took the blueprints to management, management said "hmm, it won't fit in our manufacturing bays!" so the designers said "No problem", and tore off the rear 1/4 of the blueprint.
In any case, the first time I saw an Aztek, I thought - "Ahh, so that's what a CRX looks like when it grows up!" (Which also explains why you never see CRXs on the road anymore
Does anyone believe for a second that MS will allow things like bnetd to continue to exist?
OK, I'm usually the first guy to bash MS, but in this case, I think it might be good for bnetd.
MS doesn't usually try to bully it's competition through the use of fraudulent lawsuits.. it bullies them in other ways..
The bnetd lawsuit is basically groundless - Vivendi claims that the bnetd guys stole their server code, but the only "proof" is that the code does the same thing.. (which it's supposed to) if the code really was (c)Vivendi, then they'd just look at the bnetd code (which they have access to, because it's open source), look at their server code, and say "see, it's the same"... instead they construct some cock-and-bull "it has the same bugs" story - without any reference as to how someone from bnetd managed to break into their servers, and steal one tiny piece of their server code.
MS really does things differently... yes, they have a ton more money to throw at the lawyers, but I'd be surprised if those lawyers didn't take a look at the merits of the case and just say "don't push this - find another way to bury it"
it would be illegal if they were to use the money (regardless of source) to buy up all the gaming companies and thus choke out the competition.
OK, maybe I missed something, but what's the difference between buying all the gaming companies one at a time, and buying them all at once?
Seems to me that if buying them all is illegal, then buying them one at a time would be illegal too - or do we wait until there is only one left, and say "you're not allowed to buy that one!"? (At which point it're pretty irrelevant, because one small company competing against a near-monopoly is pretty much doomed anyway.)
So, the question is - at what point do we say "Ok, now you're leveraging your monopoly?"
Your history may be correct, but you could think a bit more before posting, too
OK, I hate doing a "me too", but that's not really what I'm worried about..
Since they already have a competing product to battle.net, wouldn't they want to merge them into one service? If that's the case, what happens?
A) They kill Zone, and move everything over to battle.net (extremely unlikely)
B) They kill battle.net, but (before doing so) add support for all it's games to Zone.
C) They kill battle.net by adding support for current games (WC3, etc) to Zone, and by dropping support for older titles (Diablo 1)
In any case, things don't look good for battle.net..
There are millions of cats in shelters and with rescue groups that need homes
:o)
Hmm, these rescue groups wouldn't be run by a man with a wooden leg named Bob, would they?