At 05:12 PM 3/23/2003 -0500, Jamie Lawrence wrote: >On Sun, 23 Mar 2003, Steve Schear wrote: > > > >Unless MTAs can reject mail for lack of postage, this approach will not > > >fix a large majority of the problems of spam. Unless clearing is built > > >into the protocol, sender pays is a non-starter. > > > > I agree that there are lots of good reasons for sender-pays to be built > > into the MTA, but for users on broadband connections (like myself) I don't > > really care that the amount of email bandwidth may increase a bit if I > > don't see the spam. In the U.S. this amount to about 15% of the user > > base. Not a bad initial tareget. > >This seems to be the root of the disconnect. We're trying to solve >different problems. > >I'm enjoying a mostly spam free mailbox right now, thanks to various >procmail rules and spamassassin. I'm extremely annoyed that I'm spending >real money for spammers to send me traffic that I'm going to toss. It >may be a difference in outlook, I'm running a business that requires >connectivity.
I already get less spam in my inbox than I get in my postal box and do little filtering beyond pigeonholing the mail into mailboxes. My high speed connection is un-metered and I could care less (to a point) how much bandwidth it would take up. My time is something else again. For individuals most of the problem can be solved using throwaway mail boxes with high entropy names, not your last name if its Smith. Business faces a much bigger problem. > > > >What I was attempting to point out is that adding wealth transfer is not > > >adding any value over request-to-transmit. > > > > Sure it does once the stamps have real value and I get to keep them if I > > don't like the message. > >If your goal is to stop spam, keeping a penny after allowing transit is not >significantly different than any other method of allowing transit. Who says it a penny? How about a dollar? I'd imagine that high a hurdle would amount to almost a disconnection of email service :) > > Plug-ins for both Outlook and Eudora plug-in would go a long way toward a > > solution. M$ and IBM are both looking into real value stamps as a > solution. > >Yes. Involving central servers to collect postage, at least in one case. >Which is precisely the scenario I have a big problem with, cf. >atrificial scarcity. (I have no idea what IBM is up to. Maybe they're >more reasonable, but I doubt it.) That's why I want my client to handle all of this. >Requiring a Passport(tm) account to telnet to port 25 is not my idea of >good communication technology. True > > > CC aren't a solution. What I want is > > - a Eudora plugin to check for hashcash stamps, send bounce messages, auto > > generate my hashcash stamps, and help create and maintain my white list. > > - a web site which offers a hashcash stamp generator applet and simple > > instructions for > >Not what I was offering. I'll write you a front end website tool where people >can pay you to accept mail, and a backend filter to verify that you are >only accepting mail from people who have payed you or are whitelisted. CC, incl. paypal, won't work for low value transactions. E-gold will but its not widely used. On the better prospects is Lucrative http://lucrative.thirdhost.com but this is still in the development stage. I'd settle for them doing 60 GHz-seconds of hash computation using a downloaded applet and sending me the stamp. It will prepare email users for sender-pays and debug the overall process. >(Never mind the fact that generating stamps would become a sales >oppurtunity in that world. Machines are cheap - why wouldn't someone sell >cycles to the same folks that bug you during dinner? I assume they would. I'm betting that by the time many spammers see it on their radar sender-pays will have already morphed into a real value system and present them with an entirely different set of hurdles. >Sure, 419 and >Make.Viagra.Faster might go away, only to be replaced by "legitimate" >MCI and loan-against-your-home spam.) Right. Most of the scams would vanish and only those with some "reasonable" economics behind them would likely remain. Not getting messages from NIgerians -- I'd call that a victory of sorts. > > >Procmail and a CGI would allow this. > > > > I don't run a mail server. > >As I said, we appear to be attacking different problems. Procmail does >not require a mail server, and our theoretical commerce-for-mail tool is >web based. If you don't like procmail, there are many other incoming >filters you can use until a protocol that limits abusive email emerges. OK. > > >I'll even > > >write the code for you, if you'll promise to use it on all of your mail. > > > > Write the above code and I will. > >I absolutely will, if we can agree on the problem space. > > > >Let me know what language you prefer. > > > > Java > >Ick. Or Python if you please. > > >-j, who maybe gets a little excited about email because I've writing > > >email software for too long. > > > > Help get the Camram code working. > >I like some of the features of camram, but it is fundamentally flawed. >(hashcash is neat, but nobody will use it.) I will if someone deploys it. steve
