Re: Engineering to deal with the social problem of spam
On Wed, 11 Jun 2003 [EMAIL PROTECTED] wrote: On Tue, 10 Jun 2003 10:08:15 PDT, james woodyatt [EMAIL PROTECTED] said: And as for those too poor to keep their CPU's current, Let Them Eat SMTP. They clearly have an unhealthy interest in paying to receive MAKE MONEY FAST spam, so we should encourage them to continue using SMTP anyway. The Internet interprets censorship as damage and routes around it. Let SMTP continue to serve the useful function it serves: carrying spam messages. Ahem. I have several million dollars of compute resources at my disposal. It will take a fairly large hashcash request to make it painful for me. Then you obviously have too much compute power for the number of users that you have. If you get more users, the compute power to implement hashcash increases. Hashcash just makes you more vulneralble to a DOS attack, and does nothing to deter spam. Spammers will still send something that is cheaper than a postcard. If you make email cost more than a postcard, _that_ will kill email. Nothing else will. There is junk fax - and the Berlin Wall was brought down by fax machines. Let's not get this wrong. Let's not forget that it was UUCP and not the internet that foiled the coup that imprisoned Gorbachev for 3 days. --Dean
Re: Engineering to deal with the social problem of spam
everyone-- Here's a silly idea: let's try adding an option for hashcash to APEX. (Or has someone already done that?) If the problem with hashcash is that worms can steal CPU cycles to generate hashcash, then let's attack the problem of worms separately from the problem of spam suppression. If the problem with hashcash is that poor people are taxed more heavily than rich people for the utility of spam suppression, then-- well-- they should upgrade their CPU's, now shouldn't they? And as for those too poor to keep their CPU's current, Let Them Eat SMTP. They clearly have an unhealthy interest in paying to receive MAKE MONEY FAST spam, so we should encourage them to continue using SMTP anyway. The Internet interprets censorship as damage and routes around it. Let SMTP continue to serve the useful function it serves: carrying spam messages. -- j h woodyatt [EMAIL PROTECTED]
Re: Engineering to deal with the social problem of spam
On Tue, 10 Jun 2003 10:08:15 PDT, james woodyatt [EMAIL PROTECTED] said: And as for those too poor to keep their CPU's current, Let Them Eat SMTP. They clearly have an unhealthy interest in paying to receive MAKE MONEY FAST spam, so we should encourage them to continue using SMTP anyway. The Internet interprets censorship as damage and routes around it. Let SMTP continue to serve the useful function it serves: carrying spam messages. Ahem. I have several million dollars of compute resources at my disposal. It will take a fairly large hashcash request to make it painful for me. There's a *large* number of people still in the 386 world, who are financially unable to upgrade. That same hashcash request that will not inconvenience my hardware will probably kill their box for the better part of an hour. You are concluding that they therefor have an interest in paying to receive spam??? If anything, spam is a *bigger* problem for those on older hardware, simply because they have fewer computrons available to process it - so you're basically creating a regressive tax here. Just because the Internet routes around censorship doesn't mean that we have the moral right to censor those people who need it the most - those in underdeveloped countries with repressive regimes. Just because the Great Firewall of China exists doesn't mean we should add injury to insult by disenfranchising those who manage to get around the firewall. There is junk fax - and the Berlin Wall was brought down by fax machines. Let's not get this wrong. pgp0.pgp Description: PGP signature
Re: Engineering to deal with the social problem of spam
On Tuesday, Jun 10, 2003, at 22:12 US/Pacific, [EMAIL PROTECTED] wrote: [...] There's a *large* number of people still in the 386 world, who are financially unable to upgrade. That same hashcash request that will not inconvenience my hardware will probably kill their box for the better part of an hour. You are concluding that they therefor have an interest in paying to receive spam??? Yup. I am. If anything, spam is a *bigger* problem for those on older hardware, simply because they have fewer computrons available to process it - so you're basically creating a regressive tax here. And I'm not going to apologize for proposing it. Look, the phenomenon of spam is already a regressive tax, in and of itself. I'm just looking for a way to get some useful work done in exchange for receiving it. And I certainly won't mind if someone else is interested in paying me for the option to use the result of whatever useful work your CPU has to do to get your message in front of my eyeballs. Just because the Internet routes around censorship doesn't mean that we have the moral right to censor those people who need it the most - those in underdeveloped countries with repressive regimes. Who's talking about censorship? I'm not proposing that we outlaw SMTP. -- j h woodyatt [EMAIL PROTECTED] that's my village calling... no doubt, they want their idiot back.
Re: Engineering to deal with the social problem of spam
i think that we could write [hashcash] up as open source and widely distribute it and publicize the hell out of it for the rest of our careers without ever having it become common practice to reject-with-explaination all e-mail that comes from unauthorized senders. therefore it can become, at best, a system that radical and highly technical recipients can use. we've got a number of those already. (this one sounds new and better.) In order for this to work, the request for the Hashcalc calculation has to be done automatically. If it requires manual intervention where the user sees the reject notice and then has to manually take action --- of course, it's doomed to fail. So this is something which would require modification to the MTA's in order for this to work. ah. then the right way to think about this is an option for trust where one way to feel the trust is to know that someone else has performed the hashcash ritual on your behalf. this is workable. The easist way to automate such a scheme would be in the context of your replace SMTP proposal; it's just a matter of using bare keys + hashcash-style solution, instead of requiring a global PKI. hashcash-style solutions are prone to computational cost diversity problems, such that someone you want to exchange e-mail with might still have a 2GHz 32-bit CPU even though 90GHz 64-bit CPU's are what's being sold at that time. a requirement that someone do some work that takes 1 CPU minute on the fast (future) CPU's will tend to lock out owners of older (current) CPU's. a requirement that would only take one CPU minute of time for an older (current) CPU would allow in any spammer who wanted to buy (lots of) modern hardware. but more germane to the problem at hand is the fact that the community Will Not Move To A New Protocol if all it offers is hashcash, with or without the computational cost diversity problems, with or without other problems. my children are relatively wise in the ways of the world but the age at which i want them to have ibcs(*) access is lower than the age at which i'd be comfortable letting anyone with hashcash in their pocket send us traffic. so while hashcash might be a form of trust for some, it wouldn't be one here. -- Paul Vixie (*) ibcs == interpersonal batch communication system, which is my generic term for whatever will follow 821/822 email.
Re: Engineering to deal with the social problem of spam
1. does the ietf as a community generally believe that provable mutual consent between a sender and recipient is an achievable (technically) and desireable (by the global user base) goal? What's that about a community? Individuals can believe things, but communities can only argue. that's how it feels, i know. however, even the most bitterly disappointed individual contributor to the IPng effort knows that IPv6, warts and all, could only have come from a community. because of the number of adopters needed to deploy it before it could become relevant, the technology had to be developed in a sausage factory of some kind. note that i am not sure that ietf is the right such community for ibcs(*) but i am very sure that it won't get done by a small team working in dark and quiet and then thrusting a working solution into the spotlight with a bit USE ME! sign painted on it. 2. if #1, does this same community believe #1 can be accomplished by means of negative pressure (bayesian, dcc, blackhole lists, hashcash, etc) on the current e-mail system (smtp, rfc822, mime)? I see no consensus on what to do about spam and don't believe one is possible for any of those efforts or any group of them. this isn't about spam, it's about trust. with MAPS and DCC my early thoughts were in terms of disabling nonconsensual communications and what i've gone over to in recent years is enabling consensual communications which is not at all as similar as it sounds. 3. if !#2, then does this same community have any interest in being a creative, ambitious force that brings this functionality to the masses, or should this work be pursued independently/elsewhere? The continuing history of IPng is cautionary for IETF Manhattan-project style community efforts. therein lies the rub. nothing like DNS or HTTP could be created in the kind of sausage factory the ietf has become. there are too many witnesses now, and too many helpers. if someone hears that something interesting is going to be worked on, they join the mailing list and come to meetings since they're at ietf for the week anyway. with 750 people on the mailing list and 300 in every meeting, all actual work stops, or moves into design teams which mimic the IETF of olde (or so i'm told -- my first rfc was in the 1800 series, so most of the history predates my participation.) however, i do not consider IPng to be a failure. it's taking a while to get deployed, that's true, but at least (unlike DNSSEC) the last flag day has passed and there are multiple interoperable implementations. so the choice of whether to do ibcs inside IETF isn't dictated (in either direction) by what's happened with IPng. however, the choice to do ibcs outside IETF may be dictated by what's had to happen with HTML and its related standards. The little I've understood is that you've said something about mutual consent and vendors or notaries of the same, which for me evokes like Verisign? and a little more best unsaid. no, not like verisign. in [EMAIL PROTECTED] i wrote as follows: | s/mime relies on the x.509 pks industry which in is turn based on the goal | of enriching a small number of ca's who have to pay for relationships to | browser/useragent vendors who then make the certs worthwhile. that can't | scale and hasn't scaled, other than in the case of server certs. no way | will the average user be willing to pay money for a personal cert signing | if the companies on the list have all spammed them. sorry to evoke the wrong thing. i really am trying to be very clear, here. -- Paul Vixie
Re: Engineering to deal with the social problem of spam
From: Paul Vixie [EMAIL PROTECTED] ... computational cost diversity problems, with or without other problems. my children are relatively wise in the ways of the world but the age at which i want them to have ibcs(*) access is lower than the age at which i'd be comfortable letting anyone with hashcash in their pocket send us traffic. so while hashcash might be a form of trust for some, it wouldn't be one here. Why would you trust or even both with ibcs? Why not just configure your children's mail system to accept only mail that is signed with any of a handful of cryptographic keys, using S/MIME, PGP, or whatever? That solution is currently available only to a very few people, but fixing that needs only modest work in user interfaces and no effort by the IETF. Some browser-MUAs can already be used to click on a URL to add a certificate to a private, trusted list. What would be wrong with having the controls on your children's browser-MUAs locked with a password that only you know, and then visiting the web sites of tour children's teachers and sites of (the parents of) their peers to add keys (certificates, or whatever) to a list of trusted senders? ] From: Paul Vixie [EMAIL PROTECTED] ] ... ] The little I've understood is that you've said something about mutual ] consent and vendors or notaries of the same, which for me evokes ] like Verisign? and a little more best unsaid. ] ] no, not like verisign. in [EMAIL PROTECTED] i wrote as follows: ] ] | s/mime relies on the x.509 pks industry which in is turn based on the goal ] | of enriching a small number of ca's who have to pay for relationships to ] | browser/useragent vendors who then make the certs worthwhile. that can't ] | scale and hasn't scaled, other than in the case of server certs. no way ] | will the average user be willing to pay money for a personal cert signing ] | if the companies on the list have all spammed them. ] ... That Verisign is an industry pioneer and continuing leader in unsolicited bulk commercial advertising is irrelevant. Ethical outfits would not suffer that problem. The main problem is what you touched on by talking about the x.509 pks industry. The problem with third party signers, notaries, and so forth is that at the price points that people will pay in time and effort as well as money, the third parties cannot do a competent job or anything useful. People insist on using Outlook and Outlook Express instead of MUAs that are not designed to be user friendly virus and worm transports. They can't even be bothered to lock down their security preferences. I can't imagine people going to the equivalent of the trouble of finding an old fashioned notary and paying $3 to get their keys or whatever registered. Note that those who know apparently don't trust old fashioned notaries. Why else does the U.S. stock and bond industry refuse to use ordinary notarized signatures? From what I've seen, the few financial institutions that can certify your signature on a stock certificate or similar paper work are also ordinary notaries. The problem is not lack of interest in the IETF, but among users. Some of us are obsessed with some dangers, but most people have more balanced views. Most people don't pay any attention to the current terrorism color scheme. They did not buy generators and flee to the woods to wait for the collapse of civilization due to the Y2K bug. Only a few people in the military and civilian police prepared for the great wave of terrorism that was supposed to sweep the nation during the 1976 Bicentenial celebrations. (The U.S. Army Reserve unit in which I was working off my draft dodging was one.) People who are really vulnerable to nonconsensual communications such as your children can use whitelists to better effect than any sevices from third parties. Vernon Schryver[EMAIL PROTECTED]
RE: The spam problem is political (Re: Engineering to deal with the social problem of spam)
Spam costs nothing. It costs you using your bandwidth.
Re: Engineering to deal with the social problem of spam
[EMAIL PROTECTED] (Vernon Schryver) writes: What do you expect me to do? I won't answer your draft notice hell no I won't go! but I'm not going to enlist until I have a glimmer of where you're sailing and what's under the decks. at this point I'm still looking for the answer to some simple questions. 1. does the ietf as a community generally believe that provable mutual consent between a sender and recipient is an achievable (technically) and desireable (by the global user base) goal? 2. if #1, does this same community believe #1 can be accomplished by means of negative pressure (bayesian, dcc, blackhole lists, hashcash, etc) on the current e-mail system (smtp, rfc822, mime)? 3. if !#2, then does this same community have any interest in being a creative, ambitious force that brings this functionality to the masses, or should this work be pursued independently/elsewhere? there are other issues, like whether there has to be a flag day for e-mail and whether gateways into/outof old style e-mail can exist, but frankly those are details which won't matter (to this mailing list) if the answers to the above continue to be not really, well probably and elsewhere as they have been since may 25 when i entered this thread. -- Paul Vixie
Re: Engineering to deal with the social problem of spam
[EMAIL PROTECTED] (Theodore Ts'o) writes: Bare keys will do; consider a system where people keep a list of those keys that they will accept mail. If someone tries to send mail and their key is not on the recipient's list, the mail is returned to them until they can perform a Hashcash calculation consuming a non-trivial amount of CPU time, at which point their key is placed on the recipient's list, and the sender can retry to send the message. If a recipient receives SPAM, they simply drop the key of the sender from their ok-to-receive list. i think that we could write this up as open source and widely distribute it and publicize the hell out of it for the rest of our careers without ever having it become common practice to reject-with-explaination all e-mail that comes from unauthorized senders. therefore it can become, at best, a system that radical and highly technical recipients can use. we've got a number of those already. (this one sounds new and better.) -- Paul Vixie
Re: Engineering to deal with the social problem of spam
Paul writes: i want the digital equivilent of a peephole in my front door so i can ignore the doorbell if i don't like what i see. One of the big problems of spam is that it takes up more than half the total bandwidth used by e-mail. If you want a peephole, then all spam must still be delivered, so that you can examine it and reject it. That may keep it out of your mailbox, but the entire network is still being used to route and deliver it, which seems wasteful. i believe, and have always believed, that all communications ought to be mutually consensual. Most human communications do not involve any explicit consent. They are initiated by one party and accepted by another. If a person refuses any communication to which he has not consented, he spends his life alone. plenty, no, *many* are the humans who can reach me by digital communications for whom my consent is seen as irrelevant (or worse.) The same is true for your telephone, your postal mailbox, your person on the street, radio, television, and newspapers. my son has been receiving pornographic spam for five years, and he just now turned twelve years old. Another 24 months or so and you may not be the only person examining it. did you all who contributed to the creation of e-mail as a media believe that it should be rated R, no children under the age of 17 admitted without a parent? Children are not interested in porn, so spamming them with it isn't nearly as harmful as their elders would like to believe. Only adults care about sex. or consider the e-mail appending data miners, who believe that my consent to receive a magazine by postal mail somehow implies my consent to receive anything else that publishing conglomerate wants to send me by e-mail. That seems like a rational assumption. Did you tell them otherwise? ... one is sender-paid, the other is not, and my consent cannot be implied. Why not? due to accidents of fate, the CIX.NET MX RR points at my personal server. it turns out that there are now many millions of valid @COX.NET mailboxes, and that through normal error rates i receive several dozen misaddressed messages per day, usually several of them being microsoft passport ACK's containing enough information for me to commit identity theft if i so desired. a lot of the mail is quite personal in nature, too. How do you know the e-mail is quite personal in nature, if you are just discarding it without reading it? is this how we thought e-mail would grow up and meet its larger audience? not me! It seems pretty inevitable with the increasing use of e-mail, even if it was not a design goal. the current system is utterly laughable and if it were proposed apriori it would be laughed out of the room. No, the current e-mail system works admirably well. I don't care much for spam, but the advantages to receiving legitimate e-mail are so great that I'm not about to sacrifice the latter to eliminate the former. ... that which was suitable for polite early adopters in the RE community is completely unsuiable for the full global population ... They why have they embraced it so willingly? if we had end-to-end personal certificates that were widely deployed and universally presented, it would become reasonable to try to wire an smtp listener to reject all but certified traffic ... Maybe, but how would you reduce the bandwidth expended on spam, and the processor time required to screen for it? ... but since pornospammers could and would acquire signed certificates, we'd have to do some kind of pgp-like kevinbacon-like degrees of separation logic to find out about trust. This is sounding more and more complicated. Why not just use the delete key? it turns out both of those are missing. and creating them is a bigger problem than rewiring smtp would be. SMTP is pretty much cast in concrete and will likely be with us for decades to come, at the absolute minimum; so it's best to try to work within it. as usual, i would be happiest if someone else would take this on: i'm Busy. No so busy that you don't have time to open spam messages and examine them to see if they contain pornography, or personal messages to other people, or the like. my goal at the moment is to discover whether the ietf possesses a collective will and if so, whether it is willing to take on this much larger problem. so far the answer seems to be not just no but hell no! Probably because, in the final analysis, spam is an annoyance, but that's about all. Like postal junk mail.
Re: Engineering to deal with the social problem of spam
Paul writes: 1. does the ietf as a community generally believe that provable mutual consent between a sender and recipient is an achievable (technically) and desireable (by the global user base) goal? It's certainly achievable technically, since other protocols already do it. I don't see it as desirable, though, since it would generate more overhead than spam does, and it would significantly slow and impede e-mail communication overall. Additionally, it might take decades for everyone on the Internet to adopt it, and those who did not would eventually be at a disadvantage, even if they were not spammers. 2. if #1, does this same community believe #1 can be accomplished by means of negative pressure (bayesian, dcc, blackhole lists, hashcash, etc) on the current e-mail system (smtp, rfc822, mime)? No. 3. if !#2, then does this same community have any interest in being a creative, ambitious force that brings this functionality to the masses, or should this work be pursued independently/elsewhere? Not applicable, given the answer to #2.
RE: Engineering to deal with the social problem of spam
One way to deal with is to use a firewall theory. I contain a list of e-mail address of people. So if I receive a e-mail, if it is not in my e-mail address list, it is discarded. The only problem is e-mail addresses can be faked. For example, its configuration could be: Allow [EMAIL PROTECTED] Deny [EMAIL PROTECTED]
Re: Engineering to deal with the social problem of spam
If someone tries to send mail and their key is not on the recipient's list, the mail is returned to them until they can perform a Hashcash calculation consuming a non-trivial amount of CPU time, at which point their key is placed on the recipient's list, and the sender can retry to send the message. Hashcash has one big problem: worms.CPU time is free for them.. There are many reports in the press suggesting that spammers are using worms such as Jeem to deploy open relays; they could also use them to deploy hashcash generators. - Bill
Re: Engineering to deal with the social problem of spam
Eric writes: This sounds quite dangerous a way of thinking to me. Nothing particularly dangerous about it. Adults seem to readily forget that they were completely uninterested in sex prior to puberty; things sexual (including pornography) were nothing more than curiosities that rapidly became boring on those rare occasions when they were encountered. Adults have a built-in obsession with sex; prepubescent children do not. It's rather like gambling addicts assuming that anyone who walks past a casino cannot resist running in and squandering his life's savings on gambling. That may well be a danger for gambling addicts, but it is not a danger for anyone else, and in fact the addict is just projecting his own behavior and preoccupations onto others. Thus, the general public doesn't need to be kept away from casinos, because most people don't care about casinos, anyway--even though gambling addicts may behave self-destructively when exposed to casino activity. And proven to be quite erroneous ... I'm not aware of any invalidation of this principle, and it is regularly confirmed. ... look at how the cigarette manufacturers focus on youth as the ideal target for advertising. Sex and cigarettes are not the same thing. Nobody is interested in sex prior to puberty; everyone is interested in it after puberty. In contrast, an interest in cigarettes is strictly acquired, and in fact must be explicitly sought out, since smoking is not by nature a pleasant activity at any age. They know they must attack them very young to bind them on the long run and make them addicted customers later, when they are grown-up. There is no need to attack youngsters with pornography; they will become potential consumers at puberty, whether they are exposed to it prior to that age or not. And conversely, they won't care about pornography until they reach puberty--they'll just see it as something icky and boring, if they run across it at all. So, in short : *maybe* only adults care about cigarettes and sex (not sure of), but I think both are - or could be - the target of choice for advertisers, because it seems that when you catch them young enough, you create a bigger, deeper addiction. No spammers are deliberately advertising porn to children; apart from legal risks, it's a waste of time, rather like advertising refrigerators to Eskimos. They are trying to spam _adults_ with porn ads. And given how much traffic on the Internet is dedicated to porn, they probably get quite a return on their investment--from the grown-ups, not from kids. P.S.: and it appears to be similar with alcohol, candies, cars, computers, drugs, gambling, guns, pets, etc. None of these have a biological basis. Sex does. The distinction is important.
Re: Engineering to deal with the social problem of spam
On Sun, 8 Jun 2003, Anthony Atkielski wrote: Paul writes: i want the digital equivilent of a peephole in my front door so i can ignore the doorbell if i don't like what i see. One of the big problems of spam is that it takes up more than half the total bandwidth used by e-mail. Which is still practically nothing, compared to the bandwidth consumed by http (gifs and jpegs), IM (and its picture sharing), (legal) movie and MP3 downloads, and other stuff. Also, you mentioned something about porn to children. This is already illegal. If its a Type 1 or Type 2 operation, they are easy to shutdown. Unfortunately, quite a lot of this type of spam is Type 3 spam, just meant to shock and annoy, and not meant to really sell porn. Probably because, in the final analysis, spam is an annoyance, but that's about all. Like postal junk mail. Agreed. --Dean
Re: Engineering to deal with the social problem of spam
Dean writes: Which is still practically nothing, compared to the bandwidth consumed by http (gifs and jpegs), IM (and its picture sharing), (legal) movie and MP3 downloads, and other stuff. I know, which is why I specified e-mail bandwidth specifically. One cannot say that spam is actually putting a load on network bandwidth, since there are much greater bandwidth hogs on the Internet Also, you mentioned something about porn to children. This is already illegal. If its a Type 1 or Type 2 operation, they are easy to shutdown. Of course, spammers tend to send to e-mail addresses, not to human beings. Whoever has access to the mailbox receives the mail. But I don't see any reason why pornographers would target children, since their only real market is adults. Unfortunately, quite a lot of this type of spam is Type 3 spam, just meant to shock and annoy, and not meant to really sell porn. I don't even know what is Type 1 or Type 3 in my mailbox, since I delete it all without reading it.
Re: Engineering to deal with the social problem of spam
Paul writes: s/mime relies on the x.509 pks industry which in is turn based on the goal of enriching a small number of ca's who have to pay for relationships to browser/useragent vendors who then make the certs worthwhile Hmm and the cost of MAPS would be? It costs money to perform authentication and issue certificates, less than the amount charged for but the total cost to the end user in terms of time is still significant and in the case of spam control you have certified the wrong party. The party that is generally held responsible for users actions is the ISP, not the user. So that is the level at which you want to certify, not the end user. S/MIME is not designed to do the job being proposed here. You want to hold the ISPs responsible, there is no point in having greater granularity in your authentication system than you intend to use in the revocation system. I don't know what a class 3 cert for an ISP would cost but I would guess rather less than is charged for MAPS these days. Phill
Re: Engineering to deal with the social problem of spam
- Original Message - From: Theodore Ts'o [EMAIL PROTECTED] To: Paul Vixie [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, June 08, 2003 1:47 PM Subject: Re: Engineering to deal with the social problem of spam On Sun, Jun 08, 2003 at 07:29:32AM +, Paul Vixie wrote: [EMAIL PROTECTED] (Theodore Ts'o) writes: Bare keys will do; consider a system where people keep a list of those keys that they will accept mail. If someone tries to send mail and their key is not on the recipient's list, the mail is returned to them until they can perform a Hashcash calculation consuming a non-trivial amount of CPU time, at which point their key is placed on the recipient's list, and the sender can retry to send the message. If a recipient receives SPAM, they simply drop the key of the sender from their ok-to-receive list. i think that we could write this up as open source and widely distribute it and publicize the hell out of it for the rest of our careers without ever having it become common practice to reject-with-explaination all e-mail that comes from unauthorized senders. therefore it can become, at best, a system that radical and highly technical recipients can use. we've got a number of those already. (this one sounds new and better.) In order for this to work, the request for the Hashcalc calculation has to be done automatically. If it requires manual intervention where the user sees the reject notice and then has to manually take action --- of course, it's doomed to fail. So this is something which would require modification to the MTA's in order for this to work. The easist way to automate such a scheme would be in the context of your replace SMTP proposal; it's just a matter of using bare keys + hashcash-style solution, instead of requiring a global PKI. - Ted Good Idea. Sounds like a Pretty Good Protocol.
Re: Engineering to deal with the social problem of spam
on 6/8/2003 12:47 PM Theodore Ts'o wrote: In order for this to work, the request for the Hashcalc calculation has to be done automatically. If it requires manual intervention where the user sees the reject notice and then has to manually take action --- of course, it's doomed to fail. So this is something which would require modification to the MTA's in order for this to work. The easist way to automate such a scheme would be in the context of your replace SMTP proposal; it's just a matter of using bare keys + hashcash-style solution, instead of requiring a global PKI. If a key was linked to a sender address, wouldn't that give somebody everything they'd need to send me mail (just send it as me, since I'm going to read my own mail even if nobody else does)? What's to prevent a group of blackhats in the ~Ukraine from having their farm of 3Ghz PCs generate error responses all day, just to gather keys to sell along with the associated addresses? How would I replace the key/address pair in all of the good repositories -- but not the bad ones -- after my key were compromised, especially if my own delivery server is responding to requests on my behalf? Isn't the only way out of this to require senders use certificates that can be validated, proving that the sender has access to a private key which roughly corresponds to that address? I'm in agreement that we don't need a global PKI to do any of this. We only (ha!) need a relatively simple and lightweight way to locate and retrieve public keys associated with specific resources (additional vouching systems would be useful but aren't immediately necessary). That particular problem isn't too tough to solve when limited to a scope that is somewhat smaller than global PKI, and I think we'll actually get something like that relatively quickly. I also think this is mostly a chicken-and-egg problem at that level, and that we might find both the chicken and the egg at the same time if we're willing to look a bit. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Engineering to deal with the social problem of spam
Tony, TH I would like to see the outcome of a bof be identification of an TH approach to globally verifiable authenticated email. I have no doubt TH there will be many gaps in our current tool set (starting with a TH deployable PKI), and a truck load of operational guidelines to develop. What is wrong with PGP and/or S/MIME? How do they fail to provide 'globally verifiable authenticated mail? How would something else be different? Given 10 years of public key authenticated mail, why would something new succeed? d/ -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253, fax:+1.866.358.5301
Re: Engineering to deal with the social problem of spam
What is wrong with PGP and/or S/MIME? both are unusable by average nontechnical personnel. not just the daily use but the initial setup and anything out of the ordinary requires too much expertise, by far, for many of my current e-mail correspondants to use. both rely on nonpermuting gateways and forwarders. as long as microsoft outlook strips e-mail addresses out of forwarded e-mail, we're screwed. as long as line wrapping, mime stripping/mangling, ascii-ebcdic-ascii translations, and other foul arts are present in the world, neither s/mime nor pgp can reach a wide enough population to create the network effect whereby either one of them becomes useful, on average, to me or to others who want them to be useful on average. s/mime relies on the x.509 pks industry which in is turn based on the goal of enriching a small number of ca's who have to pay for relationships to browser/useragent vendors who then make the certs worthwhile. that can't scale and hasn't scaled, other than in the case of server certs. no way will the average user be willing to pay money for a personal cert signing if the companies on the list have all spammed them. How do they fail to provide 'globally verifiable authenticated mail? by appealing only to small communities, they have never created enough benefit for anyone, anywhere, ever, to be willing to say if inbound mail was not signed, just drop it, don't even store it in my inbox which is a slightly different question but more apropos to the issue of consensuality. How would something else be different? by starting from the assumption that all successul communications must be provably consensual, and by making the network agent (think listening mta) synchronous with user agent policy (i don't want mail that isn't provably beneficial to me, based on the sender's identity, on the trust path from them to me, and on their authentic promises that this communication does not have assymmetric benefit to the sender), and by planning for universal scalability (no way for thawte or verisign or even rsadsi to get monopoly economic power or results from it). Given 10 years of public key authenticated mail, why would something new succeed? because everything designed or deployed to date has been done by engineers for engineers. because this will be made to fit the full spectrum of the global community, including those at the low end who want assymetric benefit from nonconsensual communications, and those at the high end who can't cope with mangled encodings or key rings or signatures. because (e)smtp has run its course and its model (data model, security model, you name the model) is bankrupt. because holding onto it like it was salvageable if only we could find a vaccine for the plague of spam has limited the ambitions of all who have tread this path to date. because the position of trust broker cannot be a tiered monopoly in a system that has to have global scale, and the only people who can think their way that far out of the loop think that key signing parties are a reasonable alternative. nevertheless you are still asking the wrong questions and i almost feel bad for trying (above) to answer them. don't ask is this really necessary? or why do we have to discard the current system? but rather how long will the world population tolerate current and increasing levels of mangled or nonconsensual communication? and also who will develop technology to meet this gaping and obvious need? (i don't hold out much hope that ietf will do it, now that i think harder; the current mix of scientists and vendors and loudmouths aren't sensitive to the needs or aware of the nature of the broader spectrum of humanity outside themselves and their current customers. damn. i guess i'm wasting my time and yours on these rants.) -- Paul Vixie
Re: Engineering to deal with the social problem of spam
I would like to see the outcome of a bof be identification of an approach to globally verifiable authenticated email. I have no doubt there will be many gaps in our current tool set (starting with a deployable PKI), and a truck load of operational guidelines to develop. globally verifiable isn't a useful condition. universally consensual is what the market is demanding. don't make people pay in bandwidth to receive noncredentialled traffic. don't let there be a mix of credentialled and noncredentialled traffic that a user has to spend a percentage of their lifetime sorting. if traffic isn't provably desireable by the recipient then it ought not be transmittable. if that proof turns out to be based on false data then the trust path (possibly including one or more trust brokers) should be poisoned against future falsity. and in this bof, i suggest that gateways to the current system be shat upon and never again considered. when we move, we'll MOVE. -- Paul Vixie
Re: Engineering to deal with the social problem of spam
on 6/7/2003 1:40 PM Paul Vixie wrote: and in this bof, i suggest that gateways to the current system be shat upon and never again considered. when we move, we'll MOVE. That's not globally-applicable. Probably better to specify the gateway tagging, and then ~Paul can reject mail that has the markers, while ~Sales can devalue mail with those markers in their post-transfer filters. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Engineering to deal with the social problem of spam
At 03:28 PM 6/7/2003, Eric A. Hall wrote: on 6/7/2003 1:40 PM Paul Vixie wrote: and in this bof, i suggest that gateways to the current system be shat upon and never again considered. when we move, we'll MOVE. That's not globally-applicable. Probably better to specify the gateway tagging, and then ~Paul can reject mail that has the markers, while ~Sales can devalue mail with those markers in their post-transfer filters. Indeed, some level of gatewaying will likely be necessary for transition, and to accomodate intra-company use of embedded devices which transmit email alerts (e.g. UPSs, NAS boxes, etc.).
Re: Engineering to deal with the social problem of spam
From: Paul Vixie [EMAIL PROTECTED] ... why do we have to discard the current system? but rather how long will the world population tolerate current and increasing levels of mangled or nonconsensual communication? and also who will develop technology to meet this gaping and obvious need? ... A contrary view that we have seen the crest of the flood of spam can be argued: - spam filtering is a major selling point for all major ISPs, - the mass media is talking about spam filtering and spam, with ever decreasing sympathy for the ethikal biznezmen who are harmed by various anti-spam mechanisms, decreasing talk about evil, nasty vigilantes, and increasing sympathy for even abusive spam defenses. - there are some amazing legal attacks going on. See for example Legislators Call for Fix to Law Against Unsolicited E-Mails in http://online.wsj.com/article/0,,SB105484626839598400,00.html (may require a subscription) - the DMA is getting its fingers squashed in some state do-not-call lists and the continuing federal DNC evolution. See http://www.the-dma.org/cgi/disppressrelease?article=444 http://www.the-dma.org/government/donotcalllists.shtml - since the start of the recent series of legal attacks on the worst spammers, I've seen a possible leveling off in the total number of streams of spam in the system. The bend in the curve on http://www.dcc-servers.net/dcc/graphs/db-size coincident with the announcement of some legal attacks on spam might be an artifact or it might be real. All of those could be coincidences or illusions, but all of them were either conceivable or silly jokes 12 months ago. It is possible that people have had enough and aren't going to take it any more, much as people in neighborhoods in some cities in Iraq reportedly decided enough lawlessness was enough and took steps to control it. Extrapolating from peaks of lawlessness in Iraq, the Balkans, Lebanon, and elsewhere implies that the old system of a few, easily broken locks and a few lightly armed police must be replaced with a full-up prison state. However, the local residents eventually decide to deal with the worst problem makers one way (e.g. vigilantes) or another (e.g. cooperating with old or external/U.N. civil authorities) and the apparent need for extreme measures ebbs. Sometimes, it takes years for the residents to decide and overcome the problems including external pressures, but eventually things get better and the old system prevails. In other words, Paul, are you sure you're not calling for an ashcroft? Personally I'm equally convinced of the validity of both Paul's and the view above. I'm not convinced either is all or even most of the truth. Vernon Schryver[EMAIL PROTECTED]
Re: Engineering to deal with the social problem of spam
Disclaimer: there are people who know more about e-mail than I do, and some of them are on this list. But, to press on. Ummm, I'm wondering... in my own naive way. My memories of mail gateways involved SMTP-to-non-SMTP mail gateways, and the ones I hung around existed because one network didn't speak SMTP. I can't imagine that there's a meaningful mail system deployed today that doesn't speak SMTP (even if it's through a gateway). Why wouldn't we have mail sending applications that spoke (I'm making this up) SMTP and MT2, with different URL schemes (mailto: for SMTP, mailtoauth: for MT2) associated with our correspondents, let correspondents advertise both ways of being reached on Vcards, etc., and not worry about gateways? The idea would be that after I get my friends trained that they can send me mail at mailtoauth:[EMAIL PROTECTED], and get subscribed to my mailing lists with this address, I could move away from mailto:[EMAIL PROTECTED] on my own schedule. If I hope I never miss an unsolicited e-mail (from my high school reunion group, for example), I might never move away. If I get tired of looking at UBE in languages I don't have the privilege of understanding, I might move away more quickly. But waiting for the deployment of a gateway infrastructure wouldn't affect my timeline, either way. I know this is the dual-stack IPv6 migration strategy two protocol stack levels higher - would that make any difference? He asked naively, hoping that an MT2-to-SMTP gateway wouldn't be necessary... isn't a lot of our mail munging the result of gateways now? Spencer --- Daniel Senie [EMAIL PROTECTED] wrote: At 03:28 PM 6/7/2003, Eric A. Hall wrote: on 6/7/2003 1:40 PM Paul Vixie wrote: and in this bof, i suggest that gateways to the current system be shat upon and never again considered. when we move, we'll MOVE. That's not globally-applicable. Probably better to specify the gateway tagging, and then ~Paul can reject mail that has the markers, while ~Sales can devalue mail with those markers in their post-transfer filters. Indeed, some level of gatewaying will likely be necessary for transition, and to accomodate intra-company use of embedded devices which transmit email alerts (e.g. UPSs, NAS boxes, etc.). ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
Re: Engineering to deal with the social problem of spam
on 6/7/2003 3:57 PM Spencer Dawkins wrote: Why wouldn't we have mail sending applications that spoke (I'm making this up) SMTP and MT2, with different URL schemes (mailto: for SMTP, mailtoauth: for MT2) associated with our correspondents, let correspondents advertise both ways of being reached on Vcards, etc., and not worry about gateways? Let's separate those concepts. First, regarding the need for gateways, people will use them no matter what we say, since there will always be people with mixed installations, people who need mail from both networks (eg, sales and support), and so forth. If we dont specify the gateway behavior, the only predictable outcome is that people will build them without guidance. If we specify that they cannot be made, people will still make them, and without guidance. Clearly, the only workable strategy is to specify them, and to do so in such a way that folks like Paul can reject mail that ever travelled across a legacy network (that's going to be tough in toto, considering that MUAs will probably be built to use SMTP as the first-hop service for a very long time to come). As for the use of an alternate URI, those are used to tell the viewer which protocol to use. In the case of outbound mail, it would effectively be a way for the message recipient to tell the message sender that they have to use MT2 for the first-hop of the message, which doesn't make a lot of sense outside closed environments. Furthermore, what happened to the message after the first-hop would be a result of the mail-routing information in between the first and last hops, and would not necessarily be determined by the protocol that the sender used for the first-hop. So, URIs can't really be used to control the delivery path. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Engineering to deal with the social problem of spam
Dave writes: How do they fail to provide 'globally verifiable authenticated mail? Neither is universally supported.
Re: Engineering to deal with the social problem of spam
and in this bof, i suggest that gateways to the current system be shat
upon and never again considered. when we move, we'll MOVE.
That's not globally-applicable.
yes, it is.
Probably better to specify the gateway tagging, ...
and we're going to convey trust and credence through a nontrusted system How?
Indeed, some level of gatewaying will likely be necessary for transition,
no, it's not. i really mean it.
and to accomodate intra-company use of embedded devices which transmit
email alerts (e.g. UPSs, NAS boxes, etc.).
let me explain what i mean, in case there's room for compromise. ibcs will
have to be an end to end system. there won't be MX RRs for RHS's, but
rather SRV RRs for destinations -- almost exactly like SIP, i suspect. so,
rather than the current logic of
($lhs, $rhs) = split /@/, $dest;
@mxset = lookup($rhs, 'MX');
foreach $mx (sort { $a-prio = $b-prio } @mxset) {
return 1 if try($mx-host, 25);
}
return 0;
we'll see logic of the form
(($srvname = $dest) ~= s/\./\\./go) ~= s/@/./;
@ibcsset = lookup(_ibcs._tcp.$srvname, 'SRV');
foreach $srv (sort { $a-prio = $b-prio } @srvset) {
return 1 if try($srv-host, $srv-port);
}
return 0;
this means any destination needs a SRV RR. instead of cracking [EMAIL PROTECTED]
on the @ and looking for the MX RRset for vix.com, it'll get translated into
_ibcs._tcp.paul.vix.com and the SRV RRset will be used to find the possible
agents for this destination.
if smtp fallback is desired, it must be done in the sending user agent, who
upon not finding the SRV RR, could ask try smtp instead?. if there's a
NAT or firewall or gateway involved, then the submission protocol between
the user agent and local gateway has to have enough infowidth to express
these conditions and offer these choices.
the idea of an ibcs agent who nexthops through smtp is just right out, other
than because the user's own avatar decides to punch it through smtp to reach
a pager or something like that.
the idea of an smtp agent who can gain a sender's credentials in order to
make promises about mail that came from smtp and has to reach an ibcs
recipient is likewise nonsequitur.
--
Paul Vixie
Re: Engineering to deal with the social problem of spam
In other words, Paul, are you sure you're not calling for an ashcroft? completely. i have met the enemy, and i have also met the potential enemy, and i know that recipient privacy is nowhere on anybody's mind. consider what would happen if the ITU ever finished its debate about e164.arpa and there a few hundred million voip-reachable phones (either IP to the station or IP to the central office and analog to the station). all it would take a telemarketer is a simple NAPTR/SRV sweep, with SYN-probe, to build a list of tens of millions of reachable endpoints. ten racks of linux PC's later, we'd all be getting round the clock robotic calls from some telespamketer with some viagra to sell. i need ibcs to make it possible to keep doing what i used to do in e-mail, but more importantly i need the ashcroft you speak of in order to gain confidence about SIP callers, or instant messenger or SMS senders. right now the security people call this the PKI problem and calling it that is exactly what makes it unsolvable. i sweartagod the next time i meet an ivorytowermathtype who wants to tell me how hard something is, i'm just going to do something unsavory. We Know How To Do This! not only that, but We Know What The Market Demands! note that brokered anonymity will still be possible. knowing someone's identity means knowing that they are somebody in particular, and not necessarily knowing their meatspace-corredpondance identity. i'd be one of many people who would set my acceptance-filters to allow e-mail traffic based on transitive recourse toward a well-heeled trust broker (who has much to lose if their clients misbehave), even if i might not accept an e-commerce transaction from someone who didn't want me to know their name and address in meatspace. Personally I'm equally convinced of the validity of both Paul's and the view above. I'm not convinced either is all or even most of the truth. i have faith in human nature. if you build a world wide communications system to make communications easier, It Will Be Used. by the full spectrum of humanity. anybody who wants 1:1 odds against this should just gimme yer money right now, because it's not even a fair bet. -- Paul Vixie
Re: The spam problem is political (Re: Engineering to deal with the social problem of spam)
Marc writes: Spam can only be fought through a worldwide police and justice system. If so, that does not bode well for the future. As far as I can remember, _nothing_ has been successfully fought worldwide, except perhaps smallpox. This cannot by achieved by an RFC. Send this problem to ICANN. ICANN can't do anything about it.
Re: Engineering to deal with the social problem of spam
Paul writes: if you build a world wide communications system to make communications easier, It Will Be Used. by the full spectrum of humanity. Then logically, the only way to exclude any part of that spectrum is to make a communications system harder to use. I'm not sure that making things harder is a desirable goal.
Re: Engineering to deal with the social problem of spam
on 6/7/2003 6:01 PM Paul Vixie wrote: Probably better to specify the gateway tagging, ... and we're going to convey trust and credence through a nontrusted system How? We can discover without question who the first MT2 system in the path was, and (assuming that identity information is required, which I do) that gateway will also have had to present identity information about the sender. All rules, recommendations, and supportive integrity mechanisms aside, those are going to be your primary actionable knobs. Assume that somebody like AOL embraces this system for private transfers with some other large-scale provider. They probably won't update all of their submission services beforehand, but instead will just map their existing authenticated submission services to this system. EG, they'll see who a particular mail message is from, locate the appropriate user certificate in their private directory, and feed that into the system. This same model can hold true for private Exchange, GroupWise, or SMTP AUTH submission services. All of these are examples of gateways that can leverage authentication services to map a sender certificate, even if those networks aren't running MT2 as the native service. So the problem isn't with gateways it's with unauthenticated senders. Simply put, messages won't make it to the next-hop inside the MT2 transfer network UNLESS the gateway provides a user cert for the sender identity; the next-hop would otherwise just reject the message. Gateway rules (which weren't discussed in any of the above) can give you more information to act on. For example, you can set your defenses higher if you see remnants of more than one legacy Received header, or if there are other characteristics you don't like. Obviously gateways are going to be necessary, so it's really going to be a question of being able to apply the right kind of heuristics. if smtp fallback is desired, it must be done in the sending user agent, who upon not finding the SRV RR, could ask try smtp instead?. Conversion in either direction could theoretically occur at any point. What cannot easily happen is for any message to get past the first hop of the MT2 network without having entered at a system which did not have access to user credentials. [not to Paul, who already gets it: On the subject of identity-tracking, this subject is a non-starter. Folks can gather and use all of the identities they want from any number of ISPs and mail services (you can call yourself [EMAIL PROTECTED] and nobody will care as long as it validates). This is, in the end, the same level of anonymity that is available with SMTP today] -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Engineering to deal with the social problem of spam
From: Paul Vixie [EMAIL PROTECTED] In other words, Paul, are you sure you're not calling for an ashcroft? completely. i have met the enemy, and i have also met the potential enemy, and i know that recipient privacy is nowhere on anybody's mind. consider what would happen if the ITU ever finished its debate about e164.arpa and there a few hundred million voip-reachable phones (either IP to the station or IP to the central office and analog to the station). all it would take a telemarketer is a simple NAPTR/SRV sweep, with SYN-probe, to build a list of tens of millions of reachable endpoints. ten racks of linux PC's later, we'd all be getting round the clock robotic calls from some telespamketer with some viagra to sell. I can't see enough difference between that rhetoric and the doomsday scenarios of anthrax in cropdusting airplanes, dirty nuclear bombs, and the rest of the conceivable catastrophes that rationalize locking us up in our homes in front network TV. You can't and shouldn't even try to engineer perfect safety from all conceivable disasters. Before getting excited about such a viagra-VoIP bomb, think the likelihood of the first bombing, whether it could happen a second time after the perpetrators of the first were drawn and quartered, and whether the costs (not just in money) of preventing the first detonation are worthwhile. i need ibcs to make it possible to keep doing what i used to do in e-mail, but more importantly i need the ashcroft you speak of in order to gain confidence about SIP callers, or instant messenger or SMS senders. right ... By an ashcroft I mean extremely costly (mostly not in money), insufficiently or entirely unjustified, so called defenses against potential disasters, where the defenses are of dubious or no real use (e.g. the new airplane passenger screening) against the ostensible potential disaster. I don't understand enough of your notions to see whether I think it would work or be worse than spam, but I have dark suspicions that they would turn out like the new and forthcoming defenses against terrorism (and drugs, child porn, etc.) from the U.S. DOD and DOJ. Cassandra was right, but her proscription was only to send one woman home to her lawful husband. So how about turning down the heat a little and being more technically specific about your replacement for the Internet? Since that viagra-VoIP bomb has nothing to do with SMTP, it seems you're talking about a far bigger progject than merely replacing SMTP. Vernon Schryver[EMAIL PROTECTED]
Re: Engineering to deal with the social problem of spam
By an ashcroft I mean extremely costly (mostly not in money), insufficiently or entirely unjustified, so called defenses against potential disasters, where the defenses are of dubious or no real use (e.g. the new airplane passenger screening) against the ostensible potential disaster. ah. then that's not what i'm advocating. i want the digital equivilent of a peephole in my front door so i can ignore the doorbell if i don't like what i see. I don't understand enough of your notions to see whether I think it would work or be worse than spam, but I have dark suspicions that they would turn out like the new and forthcoming defenses against terrorism (and drugs, child porn, etc.) from the U.S. DOD and DOJ. i believe, and have always believed, that all communications ought to be mutually consensual. that philosophy underlaid my initial thoughts about both MAPS and DCC, and is part of my motive for trying to get DNSSEC deployed. plenty, no, *many* are the humans who can reach me by digital communications for whom my consent is seen as irrelevant (or worse.) my son has been receiving pornographic spam for five years, and he just now turned twelve years old. did you all who contributed to the creation of e-mail as a media believe that it should be rated R, no children under the age of 17 admitted without a parent? for my part, i did not. or consider the e-mail appending data miners, who believe that my consent to receive a magazine by postal mail somehow implies my consent to receive anything else that publishing conglomerate wants to send me by e-mail. (one is sender-paid, the other is not, and my consent cannot be implied.) due to accidents of fate, the CIX.NET MX RR points at my personal server. it turns out that there are now many millions of valid @COX.NET mailboxes, and that through normal error rates i receive several dozen misaddressed messages per day, usually several of them being microsoft passport ACK's containing enough information for me to commit identity theft if i so desired. a lot of the mail is quite personal in nature, too. is this how we thought e-mail would grow up and meet its larger audience? not me! the current system is utterly laughable and if it were proposed apriori it would be laughed out of the room. that which was suitable for polite early adopters in the RE community is completely unsuiable for the full global population, And This Should Come As No Surprise To Anybody. So how about turning down the heat a little and being more technically specific about your replacement for the Internet? Since that viagra-VoIP bomb has nothing to do with SMTP, it seems you're talking about a far bigger progject than merely replacing SMTP. here's the problem. if we had end-to-end personal certificates that were widely deployed and universally presented, it would become reasonable to try to wire an smtp listener to reject all but certified traffic -- but since pornospammers could and would acquire signed certificates, we'd have to do some kind of pgp-like kevinbacon-like degrees of separation logic to find out about trust. it turns out both of those are missing. and creating them is a bigger problem than rewiring smtp would be. and that once they exist they will have equal applicability to IM/ICQ/SIP/etc. as usual, i would be happiest if someone else would take this on: i'm Busy. however, that's not why i don't write a detailed proposal. my goal at the moment is to discover whether the ietf possesses a collective will and if so, whether it is willing to take on this much larger problem. so far the answer seems to be not just no but hell no! -- Paul Vixie
Re: Engineering to deal with the social problem of spam
From: Paul Vixie [EMAIL PROTECTED] ... So how about turning down the heat a little and being more technically specific about your replacement for the Internet? .. here's the problem. if we had end-to-end personal certificates that were widely deployed and universally presented, it would become reasonable to try to wire an smtp listener to reject all but certified traffic -- but since pornospammers could and would acquire signed certificates, we'd have to do some kind of pgp-like kevinbacon-like degrees of separation logic to find out about trust. it turns out both of those are missing. and creating them is a bigger problem than rewiring smtp would be. and that once they exist they will have equal applicability to IM/ICQ/SIP/etc. as usual, i would be happiest if someone else would take this on: i'm Busy. however, that's not why i don't write a detailed proposal. my goal at the moment is to discover whether the ietf possesses a collective will and if so, whether it is willing to take on this much larger problem. so far the answer seems to be not just no but hell no! Imagine if you will (since it's true), that I don't have any real idea what you're talking about. I understand only that you think that PKI is hopelessly broken (golly gee, what a surprise) and that something else easy and obvious (to you but not me) is The Solution. Assume (since it's also true) that I've lost track of the number of times someone has announced Third/Forth/Fifth Generation Computing, Artificial Intelligence, True Artificial Intelligence, For Sure This Time Really True Artifical Intelligence, the Solution to the Von Neumann Bottleneck, Real Computer Security, Really Real Computer and Network Security, The Solution To Spam, and any and everthing else. Many of those announcements came from bright and sincere people who were only overstating their points. All I can see is the truth of your point that pornospammers could and would acquire signed certificates, that each of us have a single digit kevinbacon-like separation from any pornospammers, and that most of us are closer to some pornospammer than to someone else we'd like to hear from. What do you expect me to do? I won't answer your draft notice hell no I won't go! but I'm not going to enlist until I have a glimmer of where you're sailing and what's under the decks. Vernon Schryver[EMAIL PROTECTED]
Re: Engineering to deal with the social problem of spam
On Sat, Jun 07, 2003 at 07:28:12AM -0700, Dave Crocker wrote: Tony, TH I would like to see the outcome of a bof be identification of an TH approach to globally verifiable authenticated email. I have no doubt TH there will be many gaps in our current tool set (starting with a TH deployable PKI), and a truck load of operational guidelines to develop. What is wrong with PGP and/or S/MIME? How do they fail to provide 'globally verifiable authenticated mail? Again, I'd like to repeat my observation that we don't need to provide globally verifiable authenticated mail in order to solve the SPAM problem. Given the notable lack of success in setting up a global PKI after more than decade of trying, assuming that this is a prerequisite for solving the SPAM problem is merely setting ourselves up for failure. Bare keys will do; consider a system where people keep a list of those keys that they will accept mail. If someone tries to send mail and their key is not on the recipient's list, the mail is returned to them until they can perform a Hashcash calculation consuming a non-trivial amount of CPU time, at which point their key is placed on the recipient's list, and the sender can retry to send the message. If a recipient receives SPAM, they simply drop the key of the sender from their ok-to-receive list. This avoids the whole requirement of binding identities to names via a global system that everyone trusts, and it avoids the problem of determining who to trust regarding whether someone is or isn't a spammer. I'm sure this isn't the only way to do things, but I'm also sure this is far more practical than any scheme that requires a global PKI. - Ted
RE: Engineering to deal with the social problem of spam
Iljitsch van Beijnum wrote: Just adding authentication only solves a very small part of the problem: we can then accurately whitelist known senders. Two points: 1) besides white listing, the approach also provides irrefutable evidence to law enforcement about spam sources. 2) it is clear from the related threads that many would rather continue the lively exchange debating nirvana, rather than tackle the small parts of the problem that are technically achievable. A new interpersonal batch communication system certainly sounds like a good idea. The problem with email is that it is incredibly ill-suited for transferring larger files. A new protocol should be able to do much better in this area. However, this doesn't have much to do with spam issues and might make the whole thing much more complex. We can always make it more complex than necessary, but it is pointless to compare the complexity of a new system that does the job with a system that is proven to be open to abuse. No one believes that a house lock keeps out all intruders, and indeed some do get in. But we *do* believe that house locks reduce the threat to a socially acceptable level. The trouble is that on the internet, you can go from house to house and try to break locks and nobody will stop you. In the real world, you wouldn't be able to do that for very long. Adopt draft-hain-ipv6-pi* as the standard addressing plan, provide automated intrusion detection reporting, and Internet prowlers wouldn't be able to attack for very long either. So let's show some adaptability of our own and plug those SMTP holes. Or simply leave SMTP to the spammers and move on. Why look at individual messages? How much non-bulk mail can someone possibly need to send? 10 messages per hour? 100? 1000? @ 5kB/message on a 10MB/sec link, 2k/sec. That's why it's important to look at ALL mail rather than just copies of one message. Spammers by now know how to make messages look different even though they're essentially identical. Exactly how would you coorelate email across multiple accounts, on multiple service providers? Someone's home MTA sould be able to simply rate limit the number of messages an individual user gets to inject into the global email distribution system. Then all we need is a system to differentiate between trusted MTAs and rogue ones run by spammers. Why would a spammer limit themselves to a single MTA, or account. Run VMware on a laptop, and there could easliy be 10 parallel rate-limited sessions going on. If the rates are low enough, each virtual system could automatically log into another account on another MTA, then come back when the timer goes off. Tony
Re: Engineering to deal with the social problem of spam
(I really wanted to stop this thread with my previous message, but...) On woensdag, jun 4, 2003, at 02:54 Europe/Amsterdam, Tony Hain wrote: Just adding authentication only solves a very small part of the problem: we can then accurately whitelist known senders. Two points: 1) besides white listing, the approach also provides irrefutable evidence to law enforcement about spam sources. Ok, there's some value in that if we build a good key infrastructure. Wouldn't say irrefutable even then, though. What I meant to say: we need more than authentication. A new interpersonal batch communication system certainly sounds like a good idea. The problem with email is that it is incredibly ill-suited for transferring larger files. A new protocol should be able to do much better in this area. However, this doesn't have much to do with spam issues and might make the whole thing much more complex. We can always make it more complex than necessary, but it is pointless to compare the complexity of a new system that does the job with a system that is proven to be open to abuse. SMTP shouldn't be used to transfer binary files. It leads to all kinds of problems: clogged mailboxes, wasted bandwidth (base64, aargghh!), you name it. A better batch interpersonal communication system would be able to send the message, but then negotiate what to do with the attachment. From some people you may want to always immediately receive the attachment, from others you may want to read the message first and then decide whether to inititate the transfer of the attachment. This would be very cool except that it breaks current email systems at a fairly fundamental level. Adding authentication on the other hand, can be done in a way that may not be compatible with current ESTMP, but it does (or at least: could) fit into the current email architecture without too much trouble. The trouble is that on the internet, you can go from house to house and try to break locks and nobody will stop you. In the real world, you wouldn't be able to do that for very long. Adopt draft-hain-ipv6-pi* as the standard addressing plan, provide automated intrusion detection reporting, and Internet prowlers wouldn't be able to attack for very long either. Only if someone cares enough to go to the place where the prowler deploys his activities. There was a time when this was a reasonable assumption; but this time is now in the past. So let's show some adaptability of our own and plug those SMTP holes. Or simply leave SMTP to the spammers and move on. Fine by me. Why look at individual messages? How much non-bulk mail can someone possibly need to send? 10 messages per hour? 100? 1000? @ 5kB/message on a 10MB/sec link, 2k/sec. And how exactly would those messages be non-bulk? I mean, I type fast, but even then it takes a second or so to even find the recipients for a message. That's why it's important to look at ALL mail rather than just copies of one message. Spammers by now know how to make messages look different even though they're essentially identical. Exactly how would you coorelate email across multiple accounts, on multiple service providers? We push this back to the source MTA. Then if the source MTA does a bad job, we revoke the MTA's not-a-spammer accreditation so only messages with whitelisted senders can get through. Alternatively, we can build a serial number system. An MTA must then add a serial number that starts from 0 every day or every week to every message. This way everyone who receives a message from this MTA knows how many messages the MTA has already transmitted this period. Obviously spammers will fake the serial number so we also build a system that makes it possible to check if a serial number wasn't used more than once afterwards. This shouldn't be much of a problem for spammers if they can set up a new MTA in five minutes, but if they (for instance) have to get three people in good standing to sign the new MTA's key in order to be able to start a new spam run, then it gets more troublesome for them. Someone's home MTA sould be able to simply rate limit the number of messages an individual user gets to inject into the global email distribution system. Then all we need is a system to differentiate between trusted MTAs and rogue ones run by spammers. Why would a spammer limit themselves to a single MTA, or account. Run VMware on a laptop, and there could easliy be 10 parallel rate-limited sessions going on. If the rates are low enough, each virtual system could automatically log into another account on another MTA, then come back when the timer goes off. At a limit of 1000 messages per hour per account, they need 1 account-hours to send out 10 million spam messages. Assuming it takes 64 hours (on the weekend) to get an account yanked for spamming that's 160 accounts. This is a good start. Add some additional stuff such as limiting the number of messages per hour based on the number of bounces
Engineering to deal with the social problem of spam
Tony, TH I agree with the idea of a BOF, but 'anti-spam' is the wrong focus. Spam TH is a social problem, not an engineering one. I contend that is why we TH already have a research group dealing with it (social problems are TH inherently difficult for engineers, thus requiring research to figure TH out). Focus the group on a tangible engineering problem, deployable TH authenticated email. Or as Vixie labeled the more generic, interpersonal TH batch communication system. The example of theft vs. locks provides a good perspective on both the truth of your observation and the necessity that we take (appropriate) action. The key insight that comes from saying social problem is not that we should do nothing, but that we need to have a shared agreement on the details of the problem and the level of protection required. And we need to respond to it with appropriate, but limited, changes. We are all quite comfortable making a distinction between the protection needed for a home vs. protection for a facility holding a nuclear bomb. We even are reasonably comfortable distinguishing what is needed for a home in a idyllic safe environment versus one in a strife-torn hell-hole. No one believes that a house lock keeps out all intruders, and indeed some do get in. But we *do* believe that house locks reduce the threat to a socially acceptable level. We have no such clarity or consensus about spam. Worse, we *all* are seriously ignorant about solutions. Anyone who says that they know the magic fix is blowing smoke. First of all, there is not yet any existence proof for the reduction of spam. Some interventions have reduced some aspects of spam, but the total size of the beast has only been growing, and rapidly. There is a key lesson here and it is mostly missed. The lesson is that spammers are adaptable and -- as is true for all security threats -- raising the bar keeps out the riff-raff but the truly serious attackers will develop a different technique. In the case of spam, those serious attackers have disproportionate leverage, because their software can be used by less-serious drones. More importantly, by saying social problem we are correctly implying social *complexity*. Messaging touches core aspects of social processes. No one knows how to engineer one property of a complex social process without accidentally impacting others. And they key import of the word accidentally is that these unintended consequences are typically undesired. This does not mean we should do nothing. Nor does it mean that there should be no technical interventions. It *does* mean that we need to treat this as an incremental systems change process. It *does* mean that we will need multiple types of changes, not just one cure-all. It *does* mean that we should approach those changes very cautiously, even experimentally. The place to start is with a modest, objective, operationalizable definition of the thing we all agree needs to be handled differently. So, let's not worry about the all-encompassing definition of spam. Let's just -- hah! just he said -- target a single type of spam that is massive and is massively offensive. My personal favorite definition, these days, is Unsolicited Bulk Mail (UBE) (Commercial is too constrained, for me. I do not care whether the message asks me for money, my vote, my religious affiliation, or simply wants to share a bit of personal silliness with me. In other words, the detail of the content is irrelevant to me. It does not even need to be soliciting.) Not all unsolicited mail is bad. Not all bulk mail is bad. But the combination is universally reviled. So we then need to define unsolicited properly. We must make sure to permit me to make contact with someone for the first time. Not all cold calls are bad; in fact they are essential to many desirable aspects of social intercourse. We need to make sure that we define permission properly -- as a kind of opposite to unsolicited -- and so we can then enjoy wonderful debates about details such as double opt-in. And so on. Still, I think the question of unsolicited is well-enough understood to make it possible to get community rough consensus on a technical definition that the engineering community can work with. And we need to define bulk properly. This will be difficult. If I send an unsolicited message to 2 people, does it qualify? What about 10 people, 100, 1000? Why? Why not? The problem, here, is that I believe the qualifier bulk captures an essential aspect of the problematic mail, so we can't simply drop the term or say anything greater than one. Worse, the instant we choose a number, the spammers will simply send batches that are one addressee fewer than that maximum. For that matter, the number of addressees per message might not be a useful attribute, as marketeers have become good at tailoring content to individual recipients, thereby producing one addressee per message. So bulk requires considering behavior across
