From TFA: With Open Source software there are no licences to track and no legal risks.
Duh, of course there are licenses to track. A GNU GPL or BSD license is a license like any other. You have to accept what the license tells you in order to use or modify the software.
You can use All Music Guide. Put in some of your favorite bands and see what it suggests, to see which bands are similar. Or check out the genres to which your favorite bands belong, and find possibly interesting bands through that.
Here's the link to AMG. AMG likes you to register, otherwise you won't get all the things it offers (such as full listing of bands in a genre).
For example, if you were to search for some band, you'd find e.g. the genre "Stoner Metal" and from there you'd find some bands, which you might (or might not) like.
I'd like to see an open alternative to AMG. Something which would allow linking!
In a properly built sauna there is an always-open air intake at the bottom of the sauna. At the top there's another one; if some ventilation is needed, it's opened. Also, hot air rises up so sometimes it's nice to open the small hatch.
The floor is usually very cold, it's often some stone or ceramics, rarely wood. The wooden benches can get very hot so you usually sit over a towel anyway. Lean against the wall if you can, if not, throw some water over it and try again, if it's still impossible then don't lean against the wall. It does wonders for the back to lean against a hot wall, it's like a small massage.
Very few can sit up straight in a super-hot sauna, because then your head would be about touching the ceiling. Your hair starts feeling awkwardly hot, even if you pour water over your head from time to time, so usually everyone sits in a kind of a slouched position.
In some countryside saunas you could probably catch a cold by sitting at the lowest bench with your feet in the cold floor...
No, you don't "die or pass out" within few seconds.
The temperature of the AIR can be 225 F (~107 C). That's really, really hot, but manageable. You throw water around, even the benches. And the wood temperature is not that hot. Besides, you can walk on flaming coals, like they do in Hawaii, but your feet won't burn.
Dry heat is nasty. That's why there's water thrown to the stoves, to create moisture. When you're in Vegas in 116 F you have all of your clothes on, and the air is dry. It's not comparable.
You are nuts. 120 F (~50 C) is not even warm! It feels pretty damn cold inside the sauna with that kind of temperature. 140 F (~60 C) is when you start telling people they can go into the sauna in half an hour or so.
Water probably boils at that temperature, but you must understand that air does is not a good heat-conductor.
212 F does not boil you from the inside. (I'm a living proof of that if you find it hard to believe) The air is also very moist, because you throw small buckets of water over the rocks (the resulting steam + heat wave is called "löyly").
If you have never been to a sauna, you should try it. I don't know if you can get a good and proper sauna where you live. But here's some checkpoints: if it's near 212 F (80 to 100 C is good) and you can throw water on the rocks, and nobody is chasing you out or monitoring your time inside or other such nonsense (they do this in Central Europe for "health reasons" (!!)), then go for it.
Or visit Finland, you'll probably be hauled to a sauna before you're even fully out of the airplane.
Once you pay anything as taxes it is no longer your money.
You have a say of how it's supposed to be used by voting appropriately. But it is definitely not "your money". The tax money pays for things such as roads, the electric grid, water pipes, and in some countries, even universal daycare and medical treatment for all.
If you start thinking the $50 k as "your money" then you might think who's road you're driving on, who's water pipes are you using.
The tax money originating from you, in total, spread over everything tax money is used for probably doesn't account even to one dollar. Tax money is not earmarked to specific purposes. How can you claim something to be "your money", then? That's just an illusion. It's your money if and only if it's in your bank account.
Whatever you paid as taxes ceased to be your money from the point when you paid it.
I'm reading this as totally contradictory to your original post.
Why is that? As far as I know, only USA is planning to shoot satellites down. And reading the article, it wasn't about defense but rather offense - to shoot down satellites of "the enemy" first before they can see troop deployments or other things.
What I'm trying to say is that the very fact that an offensive in space is planned will give other countries the reason to plan the same thing with both defensive AND offensive capabilities.
And the big point of this arms race in outer space is that a lot of satellites (possibly larger installations as well) would be lost as the result of it, should things ever escalate to a war on the ground. This will be bad for everyone, as the article says.
When the action comes, it's too late to do anything to save the satellites. When just the thought is there, you can still do something to prevent the action, as the thought rarely comes after the action.
Whoever does the cpu work is irrelevant. It would be reasonable to assume that during the process of the client calculating the proper response, a socket would remain open to the server, thus wasting precious resources.
No, it is not quite irrelevant. The client has to do it - it has to be done by the one who is sending. It would also not be reasonable to keep the socket open due to the DoS possibility, as you mentioned.
And in the stateless environment of the Internet, how does the server allow the client to reconnect and validate itself? I guess the server has the burden of maintaining an elaborate database of IP state information... creating yet another drain of resources and an additional point of attack and method by which the server can be brought to its knees.
There is no reason to be overly complex, a database of IP state information would be like shooting a mosquito with a cluster bomb. A simple randomly created session id would suffice: the server gives it to the client, and the client then gives it back to the server (along with the response) once it has calculated things. That's the basic idea, some simple cryptography can make it more robust.
Beyond this, you're proposing that a single mail transaction require twice as many TCP connections, which cuts performance in half and doubles peak resource requirements.
No, I am not proposing such things. There would be two distinct connections, but the performance would not be halved.
First of all, the TCP connections are not simultaneous. Second, the first transaction is very simple, something along the lines of 500 bytes needs to be transmitted. This payload can easily fit inside one packet (of course depending on exact OSI layer 2 technology used). Third, the second transaction contains the actual message and it is larger, but it would be very easy to design a protocol which would, in overall, require less transmitted bytes and therefore bandwidth than SMTP uses for a mail transaction. It would perform at par, or even better, when measured with accepted transactions per second. (Of course the offline calculation of the challenge would make the overall transaction take more time).
The whole thing would go like: 1. connect to server, receive the challenge and session id. 2. Disconnect. 3. Calculate offline. 4. Connect back to server, send the responses and session id. There's two distinct connections in steps 1 and 4.
Connection setup in modern TCP/IP networks is not an issue, and does not really burden the server excessively. But in the normal SMTP, for instance the tribal dance of HELO/EHLO is a nonsensical remnant which wastes bytes needed to fully complete the transaction. HELO was useful in the time when all Internet trusted each other, when nobody played evil. But it is not so nowadays, and the HELO greeting cannot be trusted. So for instance clearly such a "HELO blah", "220 Nice to see you" thing would not be needed in a new kind of protocol.
I agree that RBL is more bandwidth efficient if the recipient has been blacklisted, as the connection can just be dropped immediately and there will be few bytes transmitted. But RBL does not work well with zombies, since zombie machines can be anywhere.
I can assure you, the database would not be a bottleneck in this kind of system. Accessing a couple of values based on the session id needs just a simple hash table variant, can be done very fast and easy without the need of complex DBMS solutions.
As an end user, or someone who doesn't manage mission critical mail services, you may not be aware of some of these issues, but they indirectly affect you each and every day, in the general performance of the Internet; in the efficiency of your ISP's mail service, and more.
I have not done much system administration of a mail system, but in the past one consulting-like gig did involve me getting administrator access to the platform running the production mail systems in the biggest ISP of my country. From that
So... if this is put the other way around, it goes like this: China can decide that they must keep their perceived "space superiority" and exercise their "freedom to attack" in space. China will want to kill the devices which aid the adversary, and then they'll go and blast five US satellites and a shuttle (with crew inside) to pieces in orbit.
I think that would be totally unacceptable.
That's why I also think it would be totally unacceptable for the US to think of doing similar things at all.
Like it says in the article, in a modern world, an orbital war would leave the world deaf and blind. We rely too much on satellites for communication, remote sensing, surveillance, everything. Only fools would play with such a risk.
Yes, a normal person doesn't send 100s of mail an hour, BUT a normal mail server DOES handle 100s of legitimate mail an hour. And if you impose a stupid computational hash routine on each connection, you cut down on the efficiency of the mail server exponentially.
Yes, relaying would be problematic, and that's why the protocol itself would have to undergo some changes. Or the "exchangeable hashcash" could be utilized as a Proof-of-Work in the receiving end (still can't remember the author!!).
But you did realize that all the calculation is done on the client end? Not in the server end. The server does not bruteforce anything. The server just makes a large random number r, runs MD5 (or what ever one-way hash function) to get H, sends H to client along with some bits of the r and tells the client to figure out the original r.
For example, using 4 bits, the server creates 0011, H(0011)=111. The server sends 111 and the last bit 1 to client. The client then knows H(???1) = 111. Then it can go through all those question marks in order and see which bits fit. There are no shortcuts to finding that in a proper hash function, because you cannot invert a one-way hash function. (MD5 was maybe not so good an example but it's perhaps the most widely known so I used it). The example used 4 and 3 bits, in reality it would be like 128 and 90 bits, perhaps.
The client can (and should!) work off-line, it does not have to be connected to the server while it does the computation.
When the client connects back, the server can verify that r,H was actually sent to the client at some time in the past (e.g. by looking at a random session id and verifying r, H in its database), and that MD5(r) == H in an instant.
If it's OK, the mail is accepted. Otherwise, sorry no bonus.
So, in the new system as those zombies connect, the server is unaffected, it can process 20 connections simultaneously easily. The server just makes the puzzle and gives it to the connecting client, then kills the connection. But the zombies end up being tied up each for a short duration of time as they build the hashcash, i.e. bruteforce the hash. So the system is not about tarpitting the spammer by keeping the connection open for 7 seconds (or whatever duration).
Only if they provide properly the correct r do they have any chance of getting the mail through.
For a normal person sending mails not too often, 7 seconds of wait (or whatever the length of time is) is acceptable.
That's like creating a web site that can only handle one visitor every seven seconds. What's the point? Why even bother?
If you have a web server running on a Gameboy with 10 bits per second bandwidth, you might want to do this. In other words, if the bandwidth resource or server resource is very scarce, you might want to limit the usage.
Also, I don't see how the mail service would be slowed down beyond usage. People poll their mail (POP/IMAP/web interface/whatever) with intervals being in minutes, so as not to place a load on the servers. If the entire chain of mail coming would take one minute more time, it would not make any difference whatsoever to the end user.
yes, you get less spam, but you also get less legitimate mail
No, no, no, no! Less spam, yes. But the legitimate mail would not be affected that much. Why? BECAUSE a normal person does NOT send 100s of mails per hour. They send maybe 2 or 3 (amortized over the duration of the day). For them the new kind of system wouldn't make any differences.
Of course going through relays would be problematic, but afaik some Israeli cryptographer (Biryukov? Can't remember) had a solution to exchangeable hashcash. Unfortunately I don't remember the details, but I think I saw it as a preprint on IACR. Anyway it would be the best to connect to the server nearest to the recipient, and skip the relays altogether.
I'm curious, are you the author of the CAN-SPAM act?
No, I am not. Do you have some vested interest in allowing spamming to continue or are you afraid of losing your job as an SMTP box admin, or what's the issue here? You seem to be very temperamentic about this discussion.
I got an idea for you that uses the same analogy. If you're worried about burglars breaking into your house, why don't you BURN IT DOWN? That way there won't be anything to break into. It's as good an ideas your computational hash challenge smtp circle jerk protocol.
That's not the same analogy. The analogy would be about taking the stuff worth stealing somewhere else (such as a bank vault), so that there would be nothing to steal. Of course burning the house down would work too, but only an idiot would even think of such a thing.
Take a deep breath and this time please READ at least the following three paragraphs before answering, since what you answered to was definitely not the reasons why I consider SMTP to be obsolete.
1. By redefining the protocol I want the protocol to be simpler, and utilize a hashcash-like system in its very core. (If you don't know what hashcash is, Google it up now or read paragraph 2)
2. By using a hashcash-like computational puzzles, it just is PHYSICALLY IMPOSSIBLE for anyone to send large numbers of mails. (The machine which is to receive the message gives a computational puzzle for the client to solve, and will accept the message only after the result has been verified. This can be done in such a way that it WILL require e.g. 7 seconds of calculation per mail. And it cannot be bypassed. For instance the client has to bruteforce a collision for an n-bit hash function, given m bits, where m < n (m chosen suitably to make the computation of desired length).)
3. Why RBLs are not the "ONLY way to go": RBL systems break down the moment someone 0wns the machine and uses that zombie box to send the mails. You cannot avoid this. It's a reality that systems are insecure. If you allow large numbers of mails to be sent by any machine, you will have spam. Also, RBLs are not fair, because you will end up blocking entire networks just because there was one compromised machine as the origin of spam.
Of course you could retrofit SMTP to use hashcash-like systems, and those exist already, but I bet it would be simpler just to rewrite the mess and make it more modern in the first place.
The basic idea, however, was not to dick around with the SMTP header validity, as you misunderstood my intentions, but rather to make it physically and computationally and algorithmically impossible to send mass mails. Period. Do you now see the difference between "thou shalt not send spam" vs. "thou cannot send spam"?
Adding headers which can be trusted (through cryptographical means) is one aspect through how SMTP and its message representation could also be modernized.
The only real change in protocol that will work is one which checks the validity of the remote relay against a list of acceptable/unacceptable hosts - everything else can be subverted.
If you answer, please give an answer how a hashcash system can be subverted. I'm sure many people would like to know.
Ah but you can make multiple trips with the same reusable device, in essence you could take up the parts of, say, a small satellite and then assemble them high up, in which case it would be a lot cheaper per gram than a shuttle or a rocket, don't you think?
If the ISP can't control their internal clients, then they deserve to lose their SMTP license.
How the hell do you expect some ISP to control what's being run and downloaded in some Windows box of a home user who has no clue of security? It's impossible. The ISPs can't even keep each Windows box in their network up-to-date with security patches! So it's just not going to happen. The ISP can shut the box down, but that is after the damage has been done.
You obviously don't have much experience in this area.
Maybe so. I've once implemented a minimal RFC2821/2822 SMTP implementation (with some extensions and MIME supported as well) for a protocol converter. I became quite familiar with the specification. From that experience, it is my opinion that SMTP is fundamentally broken especially with regard to the spam problem.
I would like to ask you, how did you feel when Telnet was replaced with SSH? That required phasing out a (security-wise) broken protocol with something that works a whole lot better. You could have insisted on policies which say "thou shalt not eavesdrop" but that clearly doesn't work. A better solution is to just make it technically/computationally impossible (or at least as hard as possible) to eavesdrop.
Do you see from the previous example the difference between "thou shalt not send spam" vs. "thou cannot send spam"?
Selling virus protection for a phone is a good way to to get money. IF you don't have it, you could be vulnerable to the most devastating, horrible virus which does all kinds of bad things, deletes your contacts, fills your calendar with crap, melts your phone and rots your brains, right? Get the virus protection and you will be safe, right?
And remember to upgrade your protection, otherwise you won't be safe, right? So let's make a deal, 9.99 e for a yearly subscription.
Now you are safe!
Until the next horrible virus... So don't ever forget to pay. OR ELSE!!
How is this any form of improvement? Penalize everyone on the planet because of spammers? Force an entire worldwide network systems upgrade? Slow down mail service exponentially?
How many times do you send more than 100 mails per day? How many times do you send more than 5 mails per minute? A normal user doesn't. And those who legitimately do, are so few that a new kind of system could be worked out for them.
Make it impossible to send large numbers of mail. That's a solution which works. Systems upgrade, yes, since SMTP is broken and it cannot be fixed. I also argue that it shouldn't be fixed with some hack. Rewrite it to be better!
Mail servers should be "licensed" to operate on the Internet
This doesn't work. Think zombie machines in some ISP's network.. Windoze machines which the ISP considers trusted, most likely, since it's their customers we're talking about. The mail server is licensed, all right, but the zombie client can pump out a million messages through that licensed server.
Whitelists and blacklists just don't work. Then when you end up blacklisting an entire ISP block due to the aforementioned problem, there will be no mail service for others in that ISP block who attempt to mail to a place which blocks that ISP.
So no, white/blacklisting is not a solution. It helps, but it's not a solution.
You see, the problem with spamming is that the spammers do not follow the system: they'll break into a licensed SMTP box if need be. To beat spam, you just have to make it (physically) impossible to send large numbers of mail messages. It's that simple.
You can only go so far technologically as long as spammers are allowed to compromise peoples' computers and use them for improper activities.
So, rewrite the mail system in such a way that each mail sent requires the sender's computer to crack a small computational puzzle, which takes e.g. 10 seconds. That's a technological solution. It restricts you so that you can only send 6 mails per minute. For normal use, this is more than enough: in 10 minutes you can send 60 mails. However, you cannot achieve throughput in the rate of many tens of mails per second. Rate of spamming is thereby reduced.
This would hopefully drive the spammers to better focus their "offerings" (the reason we have spam is that some idiots do buy something based on spam!!) and leave the rest of the world out of the collateral damage of their mail bombing.
Ever ask yourself why this doesn't happen with POTS?
But it does. Magazine salesmen, organizations, donation drives, etc. call people, and some people receive more calls. Of course this harassment is not in the level of e-mail systems, because using POTS for spamming is way, way more expensive than email.
Spam doesn't cost so much for an individual person, since the individual person doesn't pay per mail, but it does cost a lot in terms of time spent. Also, the bandwidth usage is significant, considering that this is just "empty" traffic which gets nuked in the receiving end...
Sure. In the meanwhile, why don't you have a look at how X.400 mail was done, for some perspective. At the protocol level, SMTP works but only if everyone plays nice, I'm sorry to say. The protocol state machine is also too complex, it could be much simpler: 1. here's the recipient, 2. here's the mail. The server could disconnect the sender in either 1 or 2. Sender and other stuff is matter of the message representation (if you need signatures to prove the identity, or what ever).
HELO/EHLO is a hack in SMTP. It works, but it's a hack nevertheless.
I do think there's a technological solution to spam. Spam is not a social problem. If you take away the means to send meaningless unwanted mails, there will be no spam.
So you just have to make mass-spamming impossible. And do it in the receiving end, so that the first hop is where the unwanted mail stops, when the unwanted mail goes out from a spammer ISP, a zombie machine, whatever. For this, we could utilize systems which are based on brute-forcing a certain space of a one-way function when receiving the mail (like hashcash).
Legal bulk emailers should of course be re-thought too. Perhaps we could use a RSS feed leecher at the ISP (clueful people could of course run their own RSS feed checkers), which would then deliver to their customers who are subscribed to some feed. Something like the Usenet News, but a more modern one. Offer a web interface for users to subscribe to whatever place.
So.. in other words, bulk emailing is really useless for anything. So replace it with methods which disallow spam. Sorry, but it can be done way better with different methods (like RSS). Use the hashcashed email (whatever kind of email system it's based on) only for private correspondence (or with just a few recipients).
If you cannot compile the given source to a fully working Microsoft Access (or whatever source is provided), how can you be sure that the program you buy from the store contains the same source code?
You can't, since you most likely can't compile the given source, and keep on using that compiled version!
This is just smoke and mirrors. Now Microsoft can say their code has been provided for auditing by some instance, so it's got to be safe. However, there is no guarantee that the defects found will be fixed at all, and that the fixes will ever be found in the actual product. There is also no guarantee that the software you obtain from the store is the same as that for which the source was provided.
You can easily implant backdoors to the supposedly "audited" source code: just don't give the newly modified source code with the backdoor back to auditing...
It boggles the mind to think about how much bandwidth is wasted on the useless trash that spam is. Not to mention just time spent with dealing with that. How much money is lost each year overall due to spam... the number must be huge. This is an unnecessary loss of money and time.
I think this problem will just escalate for as long as we have SMTP in use. So maybe SMTP as a protocol needs a rehaul, or a revision to rewrite it completely (and call it something different). I think it wouldn't be impossible to pull off.
In BSD-style licenses there is no incentive or legal necessity for anyone, including (big) corporations, to give back anything for what they take.
This is parasitic behavior and is not constructive to the whole software ecosystem. GPL is way better in the sense that the modifications must flow back to the community, thus ensuring a healthy and thriving ecosystem for as long as the software is used by anyone.
As the source is available and will always be available, the fittest of the software species (most users, most utility for users) will evolve even more to be "the perfect tool". The availability of the source guarantees the most eyeballs and the developers interested in that software. Just getting a closed source product derived from a BSD-licensed software is of little joy to a user/programmer who needs a certain functionality, or wants to fix a certain bug.
Giving back to the community is vitality for the software. If giving back stops, the process which renews the software is lessened or dies altogether. This can not be good for the software.
Slashdot Mirror
You cannot trust the operating system either. The client provides it. It can be anything. It's not guaranteed to be correct.
You'd probably get a more accurate list by asking people in an on-line poll.
Lies, damn lies, statistics, politicians...
From TFA: With Open Source software there are no licences to track and no legal risks.
Duh, of course there are licenses to track. A GNU GPL or BSD license is a license like any other. You have to accept what the license tells you in order to use or modify the software.
Its unfair because it hurts our economy more than any other countries.
USA is the biggest polluter. You cut the most there where the problem is the biggest, isn't this only logical?
Of course, to do that much it has to seriously hurt the economies of a lot of countries, especially the US.
So we should risk the entire planet just to make a quick buck now?
You can use All Music Guide. Put in some of your favorite bands and see what it suggests, to see which bands are similar. Or check out the genres to which your favorite bands belong, and find possibly interesting bands through that.
Here's the link to AMG. AMG likes you to register, otherwise you won't get all the things it offers (such as full listing of bands in a genre).
For example, if you were to search for some band, you'd find e.g. the genre "Stoner Metal" and from there you'd find some bands, which you might (or might not) like.
I'd like to see an open alternative to AMG. Something which would allow linking!
In a properly built sauna there is an always-open air intake at the bottom of the sauna. At the top there's another one; if some ventilation is needed, it's opened. Also, hot air rises up so sometimes it's nice to open the small hatch.
The floor is usually very cold, it's often some stone or ceramics, rarely wood. The wooden benches can get very hot so you usually sit over a towel anyway. Lean against the wall if you can, if not, throw some water over it and try again, if it's still impossible then don't lean against the wall. It does wonders for the back to lean against a hot wall, it's like a small massage.
Very few can sit up straight in a super-hot sauna, because then your head would be about touching the ceiling. Your hair starts feeling awkwardly hot, even if you pour water over your head from time to time, so usually everyone sits in a kind of a slouched position.
In some countryside saunas you could probably catch a cold by sitting at the lowest bench with your feet in the cold floor...
No, you don't "die or pass out" within few seconds.
The temperature of the AIR can be 225 F (~107 C). That's really, really hot, but manageable. You throw water around, even the benches. And the wood temperature is not that hot. Besides, you can walk on flaming coals, like they do in Hawaii, but your feet won't burn.
Dry heat is nasty. That's why there's water thrown to the stoves, to create moisture. When you're in Vegas in 116 F you have all of your clothes on, and the air is dry. It's not comparable.
You are nuts. 120 F (~50 C) is not even warm! It feels pretty damn cold inside the sauna with that kind of temperature. 140 F (~60 C) is when you start telling people they can go into the sauna in half an hour or so.
Have you ever been to a real sauna?
Water probably boils at that temperature, but you must understand that air does is not a good heat-conductor.
212 F does not boil you from the inside. (I'm a living proof of that if you find it hard to believe) The air is also very moist, because you throw small buckets of water over the rocks (the resulting steam + heat wave is called "löyly").
Here's some links for you: at Virtual Finland, and a nice site written by a non-Finnish person.
If you have never been to a sauna, you should try it. I don't know if you can get a good and proper sauna where you live. But here's some checkpoints: if it's near 212 F (80 to 100 C is good) and you can throw water on the rocks, and nobody is chasing you out or monitoring your time inside or other such nonsense (they do this in Central Europe for "health reasons" (!!)), then go for it.
Or visit Finland, you'll probably be hauled to a sauna before you're even fully out of the airplane.
Once you pay anything as taxes it is no longer your money.
You have a say of how it's supposed to be used by voting appropriately. But it is definitely not "your money". The tax money pays for things such as roads, the electric grid, water pipes, and in some countries, even universal daycare and medical treatment for all.
If you start thinking the $50 k as "your money" then you might think who's road you're driving on, who's water pipes are you using.
The tax money originating from you, in total, spread over everything tax money is used for probably doesn't account even to one dollar. Tax money is not earmarked to specific purposes. How can you claim something to be "your money", then? That's just an illusion. It's your money if and only if it's in your bank account.
Whatever you paid as taxes ceased to be your money from the point when you paid it.
I'm reading this as totally contradictory to your original post.
Why is that? As far as I know, only USA is planning to shoot satellites down. And reading the article, it wasn't about defense but rather offense - to shoot down satellites of "the enemy" first before they can see troop deployments or other things.
What I'm trying to say is that the very fact that an offensive in space is planned will give other countries the reason to plan the same thing with both defensive AND offensive capabilities.
And the big point of this arms race in outer space is that a lot of satellites (possibly larger installations as well) would be lost as the result of it, should things ever escalate to a war on the ground. This will be bad for everyone, as the article says.
When the action comes, it's too late to do anything to save the satellites. When just the thought is there, you can still do something to prevent the action, as the thought rarely comes after the action.
Whoever does the cpu work is irrelevant. It would be reasonable to assume that during the process of the client calculating the proper response, a socket would remain open to the server, thus wasting precious resources.
No, it is not quite irrelevant. The client has to do it - it has to be done by the one who is sending. It would also not be reasonable to keep the socket open due to the DoS possibility, as you mentioned.
And in the stateless environment of the Internet, how does the server allow the client to reconnect and validate itself? I guess the server has the burden of maintaining an elaborate database of IP state information... creating yet another drain of resources and an additional point of attack and method by which the server can be brought to its knees.
There is no reason to be overly complex, a database of IP state information would be like shooting a mosquito with a cluster bomb. A simple randomly created session id would suffice: the server gives it to the client, and the client then gives it back to the server (along with the response) once it has calculated things. That's the basic idea, some simple cryptography can make it more robust.
Beyond this, you're proposing that a single mail transaction require twice as many TCP connections, which cuts performance in half and doubles peak resource requirements.
No, I am not proposing such things. There would be two distinct connections, but the performance would not be halved.
First of all, the TCP connections are not simultaneous. Second, the first transaction is very simple, something along the lines of 500 bytes needs to be transmitted. This payload can easily fit inside one packet (of course depending on exact OSI layer 2 technology used). Third, the second transaction contains the actual message and it is larger, but it would be very easy to design a protocol which would, in overall, require less transmitted bytes and therefore bandwidth than SMTP uses for a mail transaction. It would perform at par, or even better, when measured with accepted transactions per second. (Of course the offline calculation of the challenge would make the overall transaction take more time).
The whole thing would go like: 1. connect to server, receive the challenge and session id. 2. Disconnect. 3. Calculate offline. 4. Connect back to server, send the responses and session id. There's two distinct connections in steps 1 and 4.
Connection setup in modern TCP/IP networks is not an issue, and does not really burden the server excessively. But in the normal SMTP, for instance the tribal dance of HELO/EHLO is a nonsensical remnant which wastes bytes needed to fully complete the transaction. HELO was useful in the time when all Internet trusted each other, when nobody played evil. But it is not so nowadays, and the HELO greeting cannot be trusted. So for instance clearly such a "HELO blah", "220 Nice to see you" thing would not be needed in a new kind of protocol.
I agree that RBL is more bandwidth efficient if the recipient has been blacklisted, as the connection can just be dropped immediately and there will be few bytes transmitted. But RBL does not work well with zombies, since zombie machines can be anywhere.
I can assure you, the database would not be a bottleneck in this kind of system. Accessing a couple of values based on the session id needs just a simple hash table variant, can be done very fast and easy without the need of complex DBMS solutions.
As an end user, or someone who doesn't manage mission critical mail services, you may not be aware of some of these issues, but they indirectly affect you each and every day, in the general performance of the Internet; in the efficiency of your ISP's mail service, and more.
I have not done much system administration of a mail system, but in the past one consulting-like gig did involve me getting administrator access to the platform running the production mail systems in the biggest ISP of my country. From that
So... if this is put the other way around, it goes like this: China can decide that they must keep their perceived "space superiority" and exercise their "freedom to attack" in space. China will want to kill the devices which aid the adversary, and then they'll go and blast five US satellites and a shuttle (with crew inside) to pieces in orbit.
I think that would be totally unacceptable.
That's why I also think it would be totally unacceptable for the US to think of doing similar things at all.
Like it says in the article, in a modern world, an orbital war would leave the world deaf and blind. We rely too much on satellites for communication, remote sensing, surveillance, everything. Only fools would play with such a risk.
Yes, a normal person doesn't send 100s of mail an hour, BUT a normal mail server DOES handle 100s of legitimate mail an hour. And if you impose a stupid computational hash routine on each connection, you cut down on the efficiency of the mail server exponentially.
Yes, relaying would be problematic, and that's why the protocol itself would have to undergo some changes. Or the "exchangeable hashcash" could be utilized as a Proof-of-Work in the receiving end (still can't remember the author!!).
But you did realize that all the calculation is done on the client end? Not in the server end. The server does not bruteforce anything. The server just makes a large random number r, runs MD5 (or what ever one-way hash function) to get H, sends H to client along with some bits of the r and tells the client to figure out the original r.
For example, using 4 bits, the server creates 0011, H(0011)=111. The server sends 111 and the last bit 1 to client. The client then knows H(???1) = 111. Then it can go through all those question marks in order and see which bits fit. There are no shortcuts to finding that in a proper hash function, because you cannot invert a one-way hash function. (MD5 was maybe not so good an example but it's perhaps the most widely known so I used it). The example used 4 and 3 bits, in reality it would be like 128 and 90 bits, perhaps.
The client can (and should!) work off-line, it does not have to be connected to the server while it does the computation.
When the client connects back, the server can verify that r,H was actually sent to the client at some time in the past (e.g. by looking at a random session id and verifying r, H in its database), and that MD5(r) == H in an instant.
If it's OK, the mail is accepted. Otherwise, sorry no bonus.
So, in the new system as those zombies connect, the server is unaffected, it can process 20 connections simultaneously easily. The server just makes the puzzle and gives it to the connecting client, then kills the connection. But the zombies end up being tied up each for a short duration of time as they build the hashcash, i.e. bruteforce the hash. So the system is not about tarpitting the spammer by keeping the connection open for 7 seconds (or whatever duration).
Only if they provide properly the correct r do they have any chance of getting the mail through.
For a normal person sending mails not too often, 7 seconds of wait (or whatever the length of time is) is acceptable.
We have had a good discussion here! That is nice.
The original parent was talking in the imaginary context of Rutan's craft being capable of orbital flight.
That's like creating a web site that can only handle one visitor every seven seconds. What's the point? Why even bother?
If you have a web server running on a Gameboy with 10 bits per second bandwidth, you might want to do this. In other words, if the bandwidth resource or server resource is very scarce, you might want to limit the usage.
Also, I don't see how the mail service would be slowed down beyond usage. People poll their mail (POP/IMAP/web interface/whatever) with intervals being in minutes, so as not to place a load on the servers. If the entire chain of mail coming would take one minute more time, it would not make any difference whatsoever to the end user.
yes, you get less spam, but you also get less legitimate mail
No, no, no, no! Less spam, yes. But the legitimate mail would not be affected that much. Why? BECAUSE a normal person does NOT send 100s of mails per hour. They send maybe 2 or 3 (amortized over the duration of the day). For them the new kind of system wouldn't make any differences.
Of course going through relays would be problematic, but afaik some Israeli cryptographer (Biryukov? Can't remember) had a solution to exchangeable hashcash. Unfortunately I don't remember the details, but I think I saw it as a preprint on IACR. Anyway it would be the best to connect to the server nearest to the recipient, and skip the relays altogether.
I'm curious, are you the author of the CAN-SPAM act?
No, I am not. Do you have some vested interest in allowing spamming to continue or are you afraid of losing your job as an SMTP box admin, or what's the issue here? You seem to be very temperamentic about this discussion.
I got an idea for you that uses the same analogy. If you're worried about burglars breaking into your house, why don't you BURN IT DOWN? That way there won't be anything to break into. It's as good an ideas your computational hash challenge smtp circle jerk protocol.
That's not the same analogy. The analogy would be about taking the stuff worth stealing somewhere else (such as a bank vault), so that there would be nothing to steal. Of course burning the house down would work too, but only an idiot would even think of such a thing.
Take a deep breath and this time please READ at least the following three paragraphs before answering, since what you answered to was definitely not the reasons why I consider SMTP to be obsolete.
1. By redefining the protocol I want the protocol to be simpler, and utilize a hashcash-like system in its very core. (If you don't know what hashcash is, Google it up now or read paragraph 2)
2. By using a hashcash-like computational puzzles, it just is PHYSICALLY IMPOSSIBLE for anyone to send large numbers of mails. (The machine which is to receive the message gives a computational puzzle for the client to solve, and will accept the message only after the result has been verified. This can be done in such a way that it WILL require e.g. 7 seconds of calculation per mail. And it cannot be bypassed. For instance the client has to bruteforce a collision for an n-bit hash function, given m bits, where m < n (m chosen suitably to make the computation of desired length).)
3. Why RBLs are not the "ONLY way to go": RBL systems break down the moment someone 0wns the machine and uses that zombie box to send the mails. You cannot avoid this. It's a reality that systems are insecure. If you allow large numbers of mails to be sent by any machine, you will have spam. Also, RBLs are not fair, because you will end up blocking entire networks just because there was one compromised machine as the origin of spam.
Of course you could retrofit SMTP to use hashcash-like systems, and those exist already, but I bet it would be simpler just to rewrite the mess and make it more modern in the first place.
The basic idea, however, was not to dick around with the SMTP header validity, as you misunderstood my intentions, but rather to make it physically and computationally and algorithmically impossible to send mass mails. Period. Do you now see the difference between "thou shalt not send spam" vs. "thou cannot send spam"?
Adding headers which can be trusted (through cryptographical means) is one aspect through how SMTP and its message representation could also be modernized.
The only real change in protocol that will work is one which checks the validity of the remote relay against a list of acceptable/unacceptable hosts - everything else can be subverted.
If you answer, please give an answer how a hashcash system can be subverted. I'm sure many people would like to know.
Ah but you can make multiple trips with the same reusable device, in essence you could take up the parts of, say, a small satellite and then assemble them high up, in which case it would be a lot cheaper per gram than a shuttle or a rocket, don't you think?
If the ISP can't control their internal clients, then they deserve to lose their SMTP license.
How the hell do you expect some ISP to control what's being run and downloaded in some Windows box of a home user who has no clue of security? It's impossible. The ISPs can't even keep each Windows box in their network up-to-date with security patches! So it's just not going to happen. The ISP can shut the box down, but that is after the damage has been done.
You obviously don't have much experience in this area.
Maybe so. I've once implemented a minimal RFC2821/2822 SMTP implementation (with some extensions and MIME supported as well) for a protocol converter. I became quite familiar with the specification. From that experience, it is my opinion that SMTP is fundamentally broken especially with regard to the spam problem.
I would like to ask you, how did you feel when Telnet was replaced with SSH? That required phasing out a (security-wise) broken protocol with something that works a whole lot better. You could have insisted on policies which say "thou shalt not eavesdrop" but that clearly doesn't work. A better solution is to just make it technically/computationally impossible (or at least as hard as possible) to eavesdrop.
Do you see from the previous example the difference between "thou shalt not send spam" vs. "thou cannot send spam"?
Always think 10 years to the future.
And remember to upgrade your protection, otherwise you won't be safe, right? So let's make a deal, 9.99 e for a yearly subscription.
Now you are safe!
Until the next horrible virus... So don't ever forget to pay. OR ELSE!!
How is this any form of improvement? Penalize everyone on the planet because of spammers? Force an entire worldwide network systems upgrade? Slow down mail service exponentially?
How many times do you send more than 100 mails per day? How many times do you send more than 5 mails per minute? A normal user doesn't. And those who legitimately do, are so few that a new kind of system could be worked out for them.
Make it impossible to send large numbers of mail. That's a solution which works. Systems upgrade, yes, since SMTP is broken and it cannot be fixed. I also argue that it shouldn't be fixed with some hack. Rewrite it to be better!
Mail servers should be "licensed" to operate on the Internet
This doesn't work. Think zombie machines in some ISP's network.. Windoze machines which the ISP considers trusted, most likely, since it's their customers we're talking about. The mail server is licensed, all right, but the zombie client can pump out a million messages through that licensed server.
Whitelists and blacklists just don't work. Then when you end up blacklisting an entire ISP block due to the aforementioned problem, there will be no mail service for others in that ISP block who attempt to mail to a place which blocks that ISP.
So no, white/blacklisting is not a solution. It helps, but it's not a solution.
You see, the problem with spamming is that the spammers do not follow the system: they'll break into a licensed SMTP box if need be. To beat spam, you just have to make it (physically) impossible to send large numbers of mail messages. It's that simple.
You can only go so far technologically as long as spammers are allowed to compromise peoples' computers and use them for improper activities.
So, rewrite the mail system in such a way that each mail sent requires the sender's computer to crack a small computational puzzle, which takes e.g. 10 seconds. That's a technological solution. It restricts you so that you can only send 6 mails per minute. For normal use, this is more than enough: in 10 minutes you can send 60 mails. However, you cannot achieve throughput in the rate of many tens of mails per second. Rate of spamming is thereby reduced.
This would hopefully drive the spammers to better focus their "offerings" (the reason we have spam is that some idiots do buy something based on spam!!) and leave the rest of the world out of the collateral damage of their mail bombing.
Ever ask yourself why this doesn't happen with POTS?
But it does. Magazine salesmen, organizations, donation drives, etc. call people, and some people receive more calls. Of course this harassment is not in the level of e-mail systems, because using POTS for spamming is way, way more expensive than email.
Spam doesn't cost so much for an individual person, since the individual person doesn't pay per mail, but it does cost a lot in terms of time spent. Also, the bandwidth usage is significant, considering that this is just "empty" traffic which gets nuked in the receiving end...
Sure. In the meanwhile, why don't you have a look at how X.400 mail was done, for some perspective. At the protocol level, SMTP works but only if everyone plays nice, I'm sorry to say. The protocol state machine is also too complex, it could be much simpler: 1. here's the recipient, 2. here's the mail. The server could disconnect the sender in either 1 or 2. Sender and other stuff is matter of the message representation (if you need signatures to prove the identity, or what ever).
HELO/EHLO is a hack in SMTP. It works, but it's a hack nevertheless.
I do think there's a technological solution to spam. Spam is not a social problem. If you take away the means to send meaningless unwanted mails, there will be no spam.
So you just have to make mass-spamming impossible. And do it in the receiving end, so that the first hop is where the unwanted mail stops, when the unwanted mail goes out from a spammer ISP, a zombie machine, whatever. For this, we could utilize systems which are based on brute-forcing a certain space of a one-way function when receiving the mail (like hashcash).
Legal bulk emailers should of course be re-thought too. Perhaps we could use a RSS feed leecher at the ISP (clueful people could of course run their own RSS feed checkers), which would then deliver to their customers who are subscribed to some feed. Something like the Usenet News, but a more modern one. Offer a web interface for users to subscribe to whatever place.
So.. in other words, bulk emailing is really useless for anything. So replace it with methods which disallow spam. Sorry, but it can be done way better with different methods (like RSS). Use the hashcashed email (whatever kind of email system it's based on) only for private correspondence (or with just a few recipients).
Here's just some ideas from the top of my head.
If you cannot compile the given source to a fully working Microsoft Access (or whatever source is provided), how can you be sure that the program you buy from the store contains the same source code?
You can't, since you most likely can't compile the given source, and keep on using that compiled version!
This is just smoke and mirrors. Now Microsoft can say their code has been provided for auditing by some instance, so it's got to be safe. However, there is no guarantee that the defects found will be fixed at all, and that the fixes will ever be found in the actual product. There is also no guarantee that the software you obtain from the store is the same as that for which the source was provided.
You can easily implant backdoors to the supposedly "audited" source code: just don't give the newly modified source code with the backdoor back to auditing...
It boggles the mind to think about how much bandwidth is wasted on the useless trash that spam is. Not to mention just time spent with dealing with that. How much money is lost each year overall due to spam... the number must be huge. This is an unnecessary loss of money and time.
I think this problem will just escalate for as long as we have SMTP in use. So maybe SMTP as a protocol needs a rehaul, or a revision to rewrite it completely (and call it something different). I think it wouldn't be impossible to pull off.
In BSD-style licenses there is no incentive or legal necessity for anyone, including (big) corporations, to give back anything for what they take.
This is parasitic behavior and is not constructive to the whole software ecosystem. GPL is way better in the sense that the modifications must flow back to the community, thus ensuring a healthy and thriving ecosystem for as long as the software is used by anyone.
As the source is available and will always be available, the fittest of the software species (most users, most utility for users) will evolve even more to be "the perfect tool". The availability of the source guarantees the most eyeballs and the developers interested in that software. Just getting a closed source product derived from a BSD-licensed software is of little joy to a user/programmer who needs a certain functionality, or wants to fix a certain bug.
Giving back to the community is vitality for the software. If giving back stops, the process which renews the software is lessened or dies altogether. This can not be good for the software.
Hope you like this rational discourse.