At 10:26 AM 4/24/2002 -0700, Bart Schaefer wrote: >On Wed, 24 Apr 2002, Eric S. Johansson wrote: > > > At 08:51 AM 4/22/2002 -0700, Bart Schaefer wrote: > > > > > >The trouble is that any solution that places a burden on the sender is > > >lousy social engineering. > > > > unfortunately, you just defined life. Everything we do that involves > > learning or adapting ourselves puts a burden on the human. > >So what? The point is that you have to make the benefit to the learner >appear worth bearing the burden.
so far, my current pitch has a success rate of about 70 percent. It's higher among those who see Internet access as a tool and not as an end in and of itself. Yes, even among those with older, slower machines. > > You've just accumulated enough scar tissue from using bad UI software so > > that you cannot recognize the pain anymore. > >That's non sequitur. and that's a classic debating technique to devalue the opponents argument without any counterargument. It's relevant because I was trying to point out how you can't accurately state whether or not something can be adopted based on your perception of its "lousy social engineering". I asserted that you have a blind spot caused by over familiarity with technology. There are many examples of similar "lousy social engineering" aspects in every single mode of human communication since the beginning of time. Each one worked for awhile and then was replaced or augmented by something that was potentially an improvement and then network effects took over and made the new technique almost a requirement if one was going to communicate within in the larger community of the world. > > As a business owner, don't you have a mailbox or a telephone so that > > people you've never heard from can communicate with you? After all, why > > should you expect them to do anything new when they have something that > > already works. > >You've just made my argument for me. Yes, I do have a mailbox and phone. >Email is tool for me to communicate with the people who *want* to use >email in preference to other methods. I *don't* expect anyone to do >anything new; in fact, I *expect* them to keep right on doing what they >have been doing all along, and am pleasantly surprised when they change. either I've made your argument for you or you've made your argument for me. It all depends on how you perceive the change process as it relates to communications medium. I put up barriers to annoyances. On my telephone, I have turned off the ringer on one line and frequently ignore the other line unless I see the caller ID is from a client. I hope very soon to put up barriers on e-mail and if somebody wants to talk to me, it's sender pays or I don't listen. >(Which, incidentally, is why I don't expect this discussion to have any >effect on your opinions whatsoever, no matter how well I may make my >points.) the same could be said about you. I think we'll just have to agree to disagree. >Your system has to give them a *unilateral* reason to adopt it -- it has >to be good for them just for them, not because it's good for everyone. I think best argument is then that it converts e-mail to a sender pays system and that if somebody wants to interrupt you and take your time, they have to prove it by doing some work. The secondary argument is that the system will provide a degree of communications privacy when communicating with a familiar entity. > > Granted, these counter-examples are probably irritating but I am trying > > to show how your points are objections without foundation if you look at > > the larger world. > >Rather, I find your refutations to be without foundation; neither of them >even manages to be worth calling a counter-example. another classic devaluing debating technique. I believe you are not seeing the bigger picture. Everything we do with human communications is a pattern gets replicated over and over again. If you look at all the things people have done with e-mail, you'll see that there are analogies with telephones, telegraphs, written messages, and even probably paint on a cave wall. The patterns I have seen in human use of e-mail may be to believe that it will be possible to convert folks to a camram system and that the costs of a sender pays system will be borne if it provides sufficient defense against Spam. > > There's nothing in the camram system to stop a legitimate e-mail user > > from getting e-mail to you even without sending a coin. > >So what? If I can't use the absence of a coin as a point of decision, >what good does the system do me? the system still filters. Because it's necessary to accommodate non camram enabled e-mail during the transition period, the filter also has a white list and auto response mechanism in place to filter out mail but still allow the sender to do some work to get the mail delivered to you. Simply put, if I get mail without camram postage on it, you get a response asking you to reply to a message. That reply releases your original message. It's not original, there are at least three other similar type tools out there. I just added the proof of work postage stamp as an additional method for letting mail go through. Like I said, the only reason those options are there are because it's the way to accommodate a transition from old e-mail to new e-mail. > > I'm also surprised to hear you say you can't afford anything that make > > it harder for people to send e-mail. With the level of false positives > > one gets with any filtering system (not just pick on spamassassin), I'm > > surprised you would use any form of spam protection. > >Actually, in the seven weeks I've been running spamassassin on a regular >basis, I've had exactly two false positives, both of which were caused by >the clock on the sender's PC being wildly innaccurate. I've had a few >dozen false negatives, a few hundred true negatives and several thousand >true positives. SA's doing it's job just fine. > >But I don't use SA on my business mail, only on my personal mail. I may >eventually try it on the business mail, but with the threshold set a lot >higher. interesting. I get significantly more false positives than that. I typically deal with about 10 false negatives a day and I look, I get between 10 and 15 false positives a week. As you can probably guess, I just ignore my caught spam bucket unless somebody calls me and says something. > > >Unfortunately, as a sender, I have more disincentives to deploying the > > >system than incentives. > > > > good points. First, obviously, I believe it will reduce the amount of > > spam you get which is the first why you should bother. > >Note that when I say "it won't reduce the amount of spam I get," what I >means is that putting a coin on every message I *send* will not reduce my >amount of spam. Only when a significant amount of mail I *receive* has a >coin will it do me any good. I need a solution that doesn't depend on >anyone but me. if you need a solution that doesn't depend on anyone but you, then you are just plain out of luck. All the filtering people have been doing does absolutely nothing cut down on the volume of spam being sent. If anything, the volume has been increasing and, like in the virus world, the evolutionary pressures have been driving spammers to be more clever about bypassing filters. The beauty of a proof of work postage stamp is that there are no cheats except throwing bigger, faster, more expensive hardware at the problem. Filters can be bypassed, collaborative filtering can be bypassed as well as used as a denial of service attack against mailing lists, ordinary white lists become unmanageable and suffer from poor user interfaces. The only solution I have seen today that increases financial risk to a spammer is a sender pays system. The only sender pays system that does not require massive authentication databases or centralized infrastructure is something like camram. Yes, it too will exert evolutionary pressures on spammers if it becomes widely used. Spammers will adapt but fortunately camram has a variety of tricks to change the definition of coins dynamically to respond to that evolutionary pressure. > > The second why you should bother is that camram also provides 0 UI > > opportunistic encryption for e-mail which enhances in transit privacy. > >That may be enough for people who understand the need, but again it's a >benefit only when my correspondents also have the ability to undo the >encryption. obviously it would only encrypt e-mail in transit between two parties that have already established a relationship. When you send e-mail to someone with a coin, you also create an opportunity to pass your public key. When you get a response with a coin, you also get a public key therefore you've just created an opportunity to start signing/encrypting. Yes, there are a variety of attacks such as men in the middle but, if you are worried about such things, there are out of band key management opportunities to deal with the problem. >Also I'm not convinced that any such encryption would accomplish more than >providing a false illusion of privacy, but then I tend to agree with those >crypto-heads you've disparaged that poor security is worse than none. yes, poor security is worse than none but weak security is better than no security if you have your eyes open and know the risks. What I'm trying to do is create opportunistic encryption for e-mail the same way that SSL creates opportunistic encryption for Web traffic. It still an armored car carrying valuables from one cardboard box to another but the risks (carnivore/RIP) today are to in transit e-mail not the e-mail on the person's PC. > > >Historical precedent is that no extension to the email infrastructure can > > >really succeed until it's included by the major user-agent manufacturers > > >as a default part of the popular clients. End users simply won't go to > > >the effort to install add-ons. > > > > true. End users don't go to the effort to install add-ons such as > flash, > > RealAudio, Acrobat, etc.. > >Apples and oranges. The web can allow the opportunity to install things >in real time, as they're needed, and from the same source as the content >they're used to view; email can't do any of that. And again there's a >benefit to installing Flash -- I can see a website that I want to see. >But I don't have to install the receiving end of camram to read a message >from somebody using the sending end (and if I did, I'd have to know I >wanted to read their mail before it would be worth doing). actually, I disagree. It's the same behavior and reluctance. From most people's perspective, plug-ins are royal pain in the butt and and there is some evidence that says they drive users away from web sites. But at the same time, there's been sufficient uptake in plug-ins that content creators count on them. If people are accustomed to plug-ins for Web servers, then they should be as comfortable with plug-ins for e-mail clients. > > let me say it again. The coin generation happens client side. > >There is no "client side" in a web-based mailer, except the browser. No >message asembly work happens anywhere but on the web server. It's all >just an HTTP POST of the message body and some subset of the headers. again, look at the bigger picture. In a Web based e-mail system, the client is split in two. Half resides on the server and half resides on the browser. Because it uses a browser, it can also run code like I described below. > > They would need to run a Java program client side to do the calculations > > and pass the information back to the server. > >So now the free email service requires me to have a java-capable browser >to use it? I suppose that's not too unreasonable, but it's annoying. agreed. Fortunately, it's a small amount of code. >Now what about, say, a Blackberry wireless email handheld? that is one case I haven't solved. The PalmPilot case is solved because typically most e-mail goes through a higher powered machine during hot sync process. I suspect that if camram becomes popular than either blackberry will start generating coins or folks will run a coin server for a fee. the problem with creating a special out for something like a blackberry is that it becomes a cheat to bypass the proof of work filter and spammers will exploit that. > > Yes, it's work. Doing anything to defeat spam is work. Get over it. > >The problem is not that it's work, but that you're asking for volunteer >labor. yup. That's what a sender pays e-mail system is all about. > > In the meantime, small-scale users of the camram system should see a > > significant drop in spam with minimal false positives. > >Maybe there is something you haven't explained. How does one NOT get a >positive on every message that does NOT have coin? you do get a positive but you can flip it to a negative if the sender does some work. When a message comes in without a coin, I send you a message asking you to do some work (reply to message), when I get that proof of work (i.e. the reply), the message is released from jail and delivered. If you want to experiment with this send mail to [EMAIL PROTECTED] and follow instructions. The code is somewhat buggy and that it doesn't handle CC's or blind CC's correctly (it gives the wrong return address) but I'm hoping to fix that this weekend. I've still got a weird bug with my procmail filter. Whenever I get a message and throw it into jail, I give nothing back to procmail to handle. For some reason, it sticks a single linefeed into my mail spool file. It's very weird. > > I suggest if you want to debate this further, that we take it off list > > because it is significantly of the topic for spamassassin and I feel > > that I have already impose enough on the other members of the list. > >I'm keeping it on the list for this one more message, at least, because I >think the debate is more likely to sway undecided third parties than it is >to change either of our positions. well, I think I've said as much as can be said. Thank you for giving me additional input and insight that I can use in building a better argument for camram. Instead of giving anymore replies, I'm going to spend my energy on camram to improve the prototype. If any other readers would like to help, volunteers would be most welcome. ---eric _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
