It's interesting to read the RMX draft's author's concerns that RMX would never be deployed:
10. Deployment Considerations
Is there a concise technical solution against Spam? Yes.
Will it be deployed? Certainly not.
Why not? Because of the strong non-technical interests of several parties against a solution to the problem, as described below. Since these are non-technical reasons, they might be beyond the scope of such a draft. But since they are the main problems that prevent fighting spam, it is unavoidable to address them. This chapter exists temporarily only and should support the discussion of solutions. It is not supposed to be included in a later RFC.
10.1. The economical problem
As has been recently illustrated in the initial session of the IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting, sending Spam is a business with significant revenues.
But a much bigger business is selling Anti-Spam software. This is a billion dollar market, and it is rapidly growing. Any simple and effective solution against Spam would defeat revenues and drive several companies into bankrupt, would make consultants jobless.
Therefore, Spam is essential for the Anti-Spam business. If there is no spam, then no Anti-Spam software can be sold, similar to the Anti-Virus business. There are extremely strong efforts to keep this market growing. Viruses, Worms, and now Spam are just perfect to keep this market alive: It is not sufficient to just buy a software. Databases need to be updated continuously, thus making the cash flow continuously. Have a single, simple, and permanent solution to the problem and - boom - this billion dollar market is dead.
Re:I wish I knew where I could find the MS fonts
on
Libranet 2.8 Review
·
· Score: 1
I quite agree with you. The fixed font is my choice for terminals. However, in xemacs, I do prefer Courier.
if you don't know whose key you're encrypting a message for, it may turn out to be exactly the person you wanted to keep it secret from. conversely, if you aren't sure who sent that mail that purports to have come from Foo Barfly, the fact it was encrypted for your public key is no guarantee of anything useful.
The web of trust was designed so that you could figure out which key to use for messaging a person you had not made contact with before. However, I would argue that the web of trust is so weak, broken, and misunderstood, that it is stronger to simply query the contact directly using maybe two different methods, asking which key they use.
Just look at ssh; ssh flourishes without a web of trust for its keys. I would even argue that because it doesn't take on the burden of promoting a web of trust, it is able be so much more successful than PGP.
The web of trust is an idealistic goal, but unattainable for the forseeable future.
I have to firmly agree that the web of trust has been a failed experiment. For SSL, it only helps reinforce a top-down hierarchy. For PGP, the web of trust has really failed because it's used so little; it's usually so little work to verify that a certain key belongs to a certain UID, without relying on the trust network. This is sort of why I developed keystory, which looks at the signatures used in a mailing list archive, and gives a simple report of which keys a From address has used.
You obviously misunderstand what I stated. The point is that you don't move around IP addresses, but you do change the indirection pointer (DNS A record). What I meant to imply was that telephone numbers should not be as IP addresses, but rather as indirection numbers ala DNS records. By using indirection mechanisms, you de-couple the routing mechanism from the naming mechanism.
Compare this, for instance, with trying to implement portable IP-numbers. It's not the same thing (different technology among other things), but the complexity issues are similar.
Oh, come on. It's called DNS (or more generically, indirection). Seems to have worked fine for the last 15 years or so. It's not really a hard concept to grasp or implement.
This kind of story perfectly illustrates why combatants dressing as civilians is morally apprehensible; it makes the innocent civilian population more suspect to this sort of attack.
Oh, I'm certainly not disagreeing with you about the size or readibility of XML. I just wanted to point out that if you're going to do XML, at least do XML right. Personally I don't think parsing is that difficult...that's what we have tools like bison and flex for.
First, you forgot to quote your attributes, so what you specified is not well-formed XML. Second, most people would argue that you should not be putting 'real' data in attributes, but rather in elements.
I have no problem allowing access -- to certain people and trusted networks/machines.
DEFAULT DENY policies at large organizations never let the little guy (e.g., student) who is capable of proving himself show that he can operate trustfully. The bureaucracy is just too thick. Just look at how cable companies block all incoming port 80 and 8080, instituted when Code Red or whatever came out, supposedly for the purpose of blocking webserver worms. But the worms have dwindled, and servers patched. And those who were running Apache and not IIS were affected. Yet the blocks remain. Such blocks are not done for technical reasons; that is just an excuse. And the same comes of almost any institution who imposes DEFAULT DENY blocks, saying it's for a technical solution. The block is not going to be held in place because of technical reasons; it will be held in place because of a prevailing mindset that users shouldn't be given power and freedom to provide services to others; they all be filtered through an on-high hierarchy.
Somehow, you then lump a whole bunch of solutions together:
filtering
monitoring
blocking
Monitoring is one thing. Filtering and blocking (the same thing, in essence), is a completely different problem. With DEFAULT DENY (read: DEFAULT BLOCK) policies, you are really going to stifle a lot of creative, technical people. Monitoring can be implemented in a civil manner and a DEFAULT ACCEPT environment, where it finds bad players, and then blocks on a per-case basis.
I pray for the day of host-to-host ipsec, so that middlemen who block based on content (e.g., port-filtering) are thwarted.
Jeez, what an awful road to go down. The very idea that you cannot be a participant in the internet, and provide your own services, is abhorrent. There should be no problem with a student having his own webserver, mail server (as long as it's not an open relay), finger server, or whatever. Solve problems with specific solutions, not these broad, sweeping, castrating ones.
The way of thinking that you suggest, that only "powers that be" may provide services, promotes consumerism, and prohibits the freedom of individuals.
Your suggestions are antithetical to the very principles that the net was built on, end-to-end.
To be honest, I'd be very much interested in seeing how they involve the Myst universe. The games Myst and Riven were quite good, and the books even better. There is a lot of potential for the Myst universe, given the idea that if you are trained, you can become a writer (creator/linker of worlds).
Re:This is interesting...
on
Dow vs. Parody
·
· Score: 2
I take it you don't believe in the value of common carrier laws for telephone providers? Do you think that telephone companies should be able to filter what you talk about on the telephone? Granted, ISP's are not common carriers (yet; there is debate about this), but in my mind, there is great value in having conduits of information not allowed to discriminate based upon the content of the information.
That's good to hear. I didn't mean to imply that OS X lacked everything unixy, just that it didn't have enough for my tastes.
BTW, by 'everything is a file' I mean the idea that the interface to most system things are files. E.g.,/dev/sound, network connections, etc. Plan 9 goes even further, having things like the network connection being locatable on the filesystem (/net/tcp/483/in or the like).
OS X, on the other hand, just keeps getting better, proving that user-friendly yet powerful UNIX is not only possible, but damn profitable.
However, you can't use it like unix; it and its applications are certainly not unix-like. So it really doensn't matter what's underneath. I use unix because it acts like unix, which is defined by five things in my book:
There are laws that restrict the spamming of both of those, because we recognize the problem is a social one, not primarily a technological one. And so should it be with spam.
It's not the laws that prevent large-scale spamming of these, but rather the high cost.
And have there been any problems with false positives?
Once. But benefits outweigh costs. As with anything else in life, it's a tradeoff.
What about business that was lost because your auto-ack was never replied to (perhaps because it got filtered at the other end...)
Don't assume I use auto-ack sutff.
However, that time was not billable, and thus becomes part of my overhead.
I'm feeling bitchy today, so I'll say that lots of protections you pay for in life are not 'billable' to the attacker. E.g., car alarms are not 'billable' to a future assailant.
The end analysis is that without taking forceful action (ie, illegal vigilante tactics), the next step in the battle against spam is really legal. We've blocked or closed as many open relays as we can. We have blacklists we can subscribe to. We have tools like SpamAssassin to do filtering. Marginally competent people can implement Procmail filters to get rid of e-mail worms, and selectivly build blacklists (or if they want to wall off completely, whitelists.) So either declare spam illegal, or have everyone go to whitelists, and deal with the inefficiencies associated with that...
As a general rule, I don't mind people going after spammers in the legal arena; I do agree it's a crime. But I fear that changing or imposing new law will make matters worse. There have been few good results from governments attempting to regulate the net. The net community is nimble, and will overcome this problem.
BTW, do you whitelist customers too? What if they're not a customer yet, and are just e-mailing with questions, or to request a quote? And how much CPU time and disk space would you need if every customer at your ISP had the same spam load, and decided to implement filtering?
First, I don't deal with customers, but I do get abuse@ and hostmaster@, among others. Second, if the mail got blocked at the SMTP level, then they receive a bounce message. If it got through SMTP, but put into a 'holding cell', then I do a cursory look-through every day at the From/Subject. As to filtering for all our customers, we currently don't do it. But if/when we do do it, we'll charge for it.
Techinical question - when you filter, do you trash, or do you move to a folder? Just wondering how much time you use to review items that have been filtered...
Depends on the block. Some things get rejected at the SMTP level straight out. Some things get thrown into a 'suspicious' folder which I check maybe twice a day (about 50 messages a day get into it, maybe 2 that are good). Having multiple tiers is a good thing.
I'm not trying to aim for 'perfection' when it comes to spam. That is, I'm not tryin to hit zero spam, and make sure all good messages get through. It's an ideal, but one we'll only get asymptotically close to. We deal with unwanted noise all around us, and sometimes we block out stuff that we wouldn't want to. Given the deluge of information that society is being required to deal with, this is something that we're going to have to realize and come to grips with.
FYI, I think a viable long-term solution is to impose a cost on the sender (e.g., factoring a large product of two primes).
Boy, what a great idea - email is useless because of spam, so the fix is to simply make email useless altogether! Brilliant!
For those people who use IM systems instead of email (which does not include me, BTW), it's whitelisting that solves the problems of IM not becoming heavily spammed.
My spam-killing is effective, and my email remains effective.
Spam is a social problem, not a technological one.
I am not convinced. There are many ways to solve the problem of spam, especially if you bring in economics. Make the incoming SMTP client pay to use the system with cycles (e.g., factor a large product of two primes).
It's obvious that 'security' isn't their motive in this move. If you look at the products listed, it's obvious that they're trying to block p2p applications which, among other things, distribute music files. If 'protecting people from themselves' (that their 'security' really means) is what they're after, they would also have included Freenet and GNUnet.
Of course they can and will do what they're threatening. There's a reason why it pays to have your provider be classified a common carrier, and not some entity that will block your connections at whim... If you didn't see this coming you need to be hit upside the head with a cluestick...
Slashdot Mirror
Yeah, and it's just so unfortunate that we've developed technology so that the giver doesn't have to 'lose' in order to give.
</sarcasm>
It's interesting to read the RMX draft's author's concerns that RMX would never be deployed:
I quite agree with you. The fixed font is my choice for terminals. However, in xemacs, I do prefer Courier.
The web of trust was designed so that you could figure out which key to use for messaging a person you had not made contact with before. However, I would argue that the web of trust is so weak, broken, and misunderstood, that it is stronger to simply query the contact directly using maybe two different methods, asking which key they use.
Just look at ssh; ssh flourishes without a web of trust for its keys. I would even argue that because it doesn't take on the burden of promoting a web of trust, it is able be so much more successful than PGP.
The web of trust is an idealistic goal, but unattainable for the forseeable future.
I have to firmly agree that the web of trust has been a failed experiment. For SSL, it only helps reinforce a top-down hierarchy. For PGP, the web of trust has really failed because it's used so little; it's usually so little work to verify that a certain key belongs to a certain UID, without relying on the trust network. This is sort of why I developed keystory, which looks at the signatures used in a mailing list archive, and gives a simple report of which keys a From address has used.
You obviously misunderstand what I stated. The point is that you don't move around IP addresses, but you do change the indirection pointer (DNS A record). What I meant to imply was that telephone numbers should not be as IP addresses, but rather as indirection numbers ala DNS records. By using indirection mechanisms, you de-couple the routing mechanism from the naming mechanism.
Oh, come on. It's called DNS (or more generically, indirection). Seems to have worked fine for the last 15 years or so. It's not really a hard concept to grasp or implement.
This kind of story perfectly illustrates why combatants dressing as civilians is morally apprehensible; it makes the innocent civilian population more suspect to this sort of attack.
Freedom is slavery.
Oh, I'm certainly not disagreeing with you about the size or readibility of XML. I just wanted to point out that if you're going to do XML, at least do XML right. Personally I don't think parsing is that difficult...that's what we have tools like bison and flex for.
First, you forgot to quote your attributes, so what you specified is not well-formed XML. Second, most people would argue that you should not be putting 'real' data in attributes, but rather in elements.
Yes, let's destroy more of the fundamental end-to-end principles of the net.
</sarcasm>
Man, I can't wait for ubiquitous host-to-host IPsec, so these content-based filters are thwarted.
DEFAULT DENY policies at large organizations never let the little guy (e.g., student) who is capable of proving himself show that he can operate trustfully. The bureaucracy is just too thick. Just look at how cable companies block all incoming port 80 and 8080, instituted when Code Red or whatever came out, supposedly for the purpose of blocking webserver worms. But the worms have dwindled, and servers patched. And those who were running Apache and not IIS were affected. Yet the blocks remain. Such blocks are not done for technical reasons; that is just an excuse. And the same comes of almost any institution who imposes DEFAULT DENY blocks, saying it's for a technical solution. The block is not going to be held in place because of technical reasons; it will be held in place because of a prevailing mindset that users shouldn't be given power and freedom to provide services to others; they all be filtered through an on-high hierarchy.
Somehow, you then lump a whole bunch of solutions together:
Monitoring is one thing. Filtering and blocking (the same thing, in essence), is a completely different problem. With DEFAULT DENY (read: DEFAULT BLOCK) policies, you are really going to stifle a lot of creative, technical people. Monitoring can be implemented in a civil manner and a DEFAULT ACCEPT environment, where it finds bad players, and then blocks on a per-case basis.
I pray for the day of host-to-host ipsec, so that middlemen who block based on content (e.g., port-filtering) are thwarted.
Jeez, what an awful road to go down. The very idea that you cannot be a participant in the internet, and provide your own services, is abhorrent. There should be no problem with a student having his own webserver, mail server (as long as it's not an open relay), finger server, or whatever. Solve problems with specific solutions, not these broad, sweeping, castrating ones.
The way of thinking that you suggest, that only "powers that be" may provide services, promotes consumerism, and prohibits the freedom of individuals.
Your suggestions are antithetical to the very principles that the net was built on, end-to-end.
To be honest, I'd be very much interested in seeing how they involve the Myst universe. The games Myst and Riven were quite good, and the books even better. There is a lot of potential for the Myst universe, given the idea that if you are trained, you can become a writer (creator/linker of worlds).
I take it you don't believe in the value of common carrier laws for telephone providers? Do you think that telephone companies should be able to filter what you talk about on the telephone? Granted, ISP's are not common carriers (yet; there is debate about this), but in my mind, there is great value in having conduits of information not allowed to discriminate based upon the content of the information.
That's good to hear. I didn't mean to imply that OS X lacked everything unixy, just that it didn't have enough for my tastes.
BTW, by 'everything is a file' I mean the idea that the interface to most system things are files. E.g., /dev/sound, network connections, etc. Plan 9 goes even further, having things like the network connection being locatable on the filesystem (/net/tcp/483/in or the like).
However, you can't use it like unix; it and its applications are certainly not unix-like. So it really doensn't matter what's underneath. I use unix because it acts like unix, which is defined by five things in my book:
It's not the laws that prevent large-scale spamming of these, but rather the high cost.
Once. But benefits outweigh costs. As with anything else in life, it's a tradeoff.
Don't assume I use auto-ack sutff.
I'm feeling bitchy today, so I'll say that lots of protections you pay for in life are not 'billable' to the attacker. E.g., car alarms are not 'billable' to a future assailant.
As a general rule, I don't mind people going after spammers in the legal arena; I do agree it's a crime. But I fear that changing or imposing new law will make matters worse. There have been few good results from governments attempting to regulate the net. The net community is nimble, and will overcome this problem.
First, I don't deal with customers, but I do get abuse@ and hostmaster@, among others. Second, if the mail got blocked at the SMTP level, then they receive a bounce message. If it got through SMTP, but put into a 'holding cell', then I do a cursory look-through every day at the From/Subject. As to filtering for all our customers, we currently don't do it. But if/when we do do it, we'll charge for it.
Depends on the block. Some things get rejected at the SMTP level straight out. Some things get thrown into a 'suspicious' folder which I check maybe twice a day (about 50 messages a day get into it, maybe 2 that are good). Having multiple tiers is a good thing.
I'm not trying to aim for 'perfection' when it comes to spam. That is, I'm not tryin to hit zero spam, and make sure all good messages get through. It's an ideal, but one we'll only get asymptotically close to. We deal with unwanted noise all around us, and sometimes we block out stuff that we wouldn't want to. Given the deluge of information that society is being required to deal with, this is something that we're going to have to realize and come to grips with.
FYI, I think a viable long-term solution is to impose a cost on the sender (e.g., factoring a large product of two primes).
That's because you're using Verizon as an ISP. Use another ISP that won't block, but use Verizon's DSL.
For those people who use IM systems instead of email (which does not include me, BTW), it's whitelisting that solves the problems of IM not becoming heavily spammed.
My spam-killing is effective, and my email remains effective.
I am not convinced. There are many ways to solve the problem of spam, especially if you bring in economics. Make the incoming SMTP client pay to use the system with cycles (e.g., factor a large product of two primes).
Silly you. I run an ISP.
It's obvious that 'security' isn't their motive in this move. If you look at the products listed, it's obvious that they're trying to block p2p applications which, among other things, distribute music files. If 'protecting people from themselves' (that their 'security' really means) is what they're after, they would also have included Freenet and GNUnet.
Of course they can and will do what they're threatening. There's a reason why it pays to have your provider be classified a common carrier, and not some entity that will block your connections at whim... If you didn't see this coming you need to be hit upside the head with a cluestick...