Re: The spam problem (was: re:fwd:re:cdr:etc.)
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
Re: The spam problem (was: re:fwd:re:cdr:etc.)
R. A. Hettinga wrote: --- begin forwarded text 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. the camram protocol can be embedded: at the client, or at the server. I have a mostly working version at the server and could use some help with a few things (see end) one thing folks aren't too aware of is that I have incorporated a Bayesian style filter into the camram environment in order to reduce the number of postage do notices. As many folks justifiably point out, if you don't eliminate the need for a and then the universe changes step, you won't get out of starting gates. The addition of a filter to discriminate e-mail into three categories (red/yellow/green) allows me to reduce the number of challenge messages to a small fraction what they could be. The feature that implements and friends fly free allows you to build your communications map and reduce the need for stamps in either direction. Again, this works at client side or server side. Unless and until Outlook supports wealth transfer for mail this will never happen. Unless and until MS profits from fixing the problem, Outlook will never support the notion. (and if MS does support it, mutt and evolution won't, because that's M$ hegemony. etc.) Sender-pays won't fly. 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. either plug-ins or proxies. It doesn't matter which. They both have trade-offs. by the way, real value stamps are becoming less and less appealing to me. Think about a virus that exploits a hole in your e-mail client and sends lots of mail messages on your behalf. Somebody gets rich, you lose a little bit of money. Put another way, you could deny unstamped mail from me if you wanted, with a bounce asking me to enter a credit card at the web page of your choice. Why are you not doing so? 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 figure out how to make Eudora interface with Python code and we are most of the way there. I don't run a mail server. wimp. ;-) 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. Let me know what language you prefer. Java in the camram project we're using Java only for the postage due notice web page. It needs to be rewritten a bit to be only Java 1.1, show only a big fat button that says send postage when it is done, and probably some other things which I can't think of right now. The rest of the project is written python. Help get the Camram code working. steve yea, what he said... what we have done: Basic filter sequence consisting of stamp, white list, postage due response, basic template a stamp generating SMTP proxy prototype. spam discriminator prototype based on CRM114 holding area management for spam and maybe spam mail prototype CGI for holding area operations (discarded because UI sucks eggs) prototype CGI for browser based stamp generation in response to postage due notice what we need help with: Holding area operations CGI. Must be simple UI allowing noncomputer user to correct discriminator misrecognitions and release improperly filtered messages. better CGI for browser based stamp generation. better SMTP proxy for outbound stamp generation (including proper BCC handling) proxies for pop 3 any takers? ---eric
Re: The spam problem (was: re:fwd:re:cdr:etc.)
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
Re: The spam problem (was: re:fwd:re:cdr:etc.)
R. A. Hettinga wrote: --- begin forwarded text 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. the camram protocol can be embedded: at the client, or at the server. I have a mostly working version at the server and could use some help with a few things (see end) one thing folks aren't too aware of is that I have incorporated a Bayesian style filter into the camram environment in order to reduce the number of postage do notices. As many folks justifiably point out, if you don't eliminate the need for a and then the universe changes step, you won't get out of starting gates. The addition of a filter to discriminate e-mail into three categories (red/yellow/green) allows me to reduce the number of challenge messages to a small fraction what they could be. The feature that implements and friends fly free allows you to build your communications map and reduce the need for stamps in either direction. Again, this works at client side or server side. Unless and until Outlook supports wealth transfer for mail this will never happen. Unless and until MS profits from fixing the problem, Outlook will never support the notion. (and if MS does support it, mutt and evolution won't, because that's M$ hegemony. etc.) Sender-pays won't fly. 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. either plug-ins or proxies. It doesn't matter which. They both have trade-offs. by the way, real value stamps are becoming less and less appealing to me. Think about a virus that exploits a hole in your e-mail client and sends lots of mail messages on your behalf. Somebody gets rich, you lose a little bit of money. Put another way, you could deny unstamped mail from me if you wanted, with a bounce asking me to enter a credit card at the web page of your choice. Why are you not doing so? 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 figure out how to make Eudora interface with Python code and we are most of the way there. I don't run a mail server. wimp. ;-) 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. Let me know what language you prefer. Java in the camram project we're using Java only for the postage due notice web page. It needs to be rewritten a bit to be only Java 1.1, show only a big fat button that says send postage when it is done, and probably some other things which I can't think of right now. The rest of the project is written python. Help get the Camram code working. steve yea, what he said... what we have done: Basic filter sequence consisting of stamp, white list, postage due response, basic template a stamp generating SMTP proxy prototype. spam discriminator prototype based on CRM114 holding area management for spam and maybe spam mail prototype CGI for holding area operations (discarded because UI sucks eggs) prototype CGI for browser based stamp generation in response to postage due notice what we need help with: Holding area operations CGI. Must be simple UI allowing noncomputer user to correct discriminator misrecognitions and release improperly filtered messages. better CGI for browser based stamp generation. better SMTP proxy for outbound stamp generation (including proper BCC handling) proxies for pop 3 any takers? ---eric
Re: The spam problem (was: re:fwd:re:cdr:etc.)
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. 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. 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.) Requiring a Passport(tm) account to telnet to port 25 is not my idea of good communication technology. 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. Vendors need to write software for thier own products. If you are unwilling to run the software, I can't help that. (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? Sure, 419 and Make.Viagra.Faster might go away, only to be replaced by legitimate MCI and loan-against-your-home spam.) 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. 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. -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.) steve I think we're reinventing the same goal failure we both saw on ASRG. I'm going to give this up, unless something interesting happens. I'll still write you the code, if we can agree on what the goal is. But I'm not sure this is a worthwhile discussion. -j -- Jamie Lawrence[EMAIL PROTECTED] The sign that points to Boston doesn't have to go there. - Max Scheler
Re: The spam problem (was: re:fwd:re:cdr:etc.)
At 02:56 PM 3/23/2003 -0500, Jamie Lawrence wrote: On Sat, 22 Mar 2003, Steve Schear wrote: What part of the infrastructure is being made scarce? You and I aren't part of the infrastructure. The selection of a value for our time is just another market force at work. 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 is no different than the various request-permission-to-transmit proposals, aside from adding cost to the mix. Doing so will cut down on normal person to person discourse before it fixes spam. Yes, some Balkination may occur at the outset, but this is something that is recipient controlled not something mandated by ISPsm etc. 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. Sender pays can be rolled out using PoW stamps almost immediately. Yes, some early adopters may find themselves cut off from senders who either can't or won't make the effort to create and attach computation stamps. For this reason sender-pays should be serious considered by most businesses until widely adopted. But for individuals inundated with spam it could be a quick and effective solution. Of course, the question they will ask when the spam stops is how many others aren't sending email cause they think I'm fringe. :) steve Unless and until Outlook supports wealth transfer for mail this will never happen. Unless and until MS profits from fixing the problem, Outlook will never support the notion. (and if MS does support it, mutt and evolution won't, because that's M$ hegemony. etc.) Sender-pays won't fly. 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. Put another way, you could deny unstamped mail from me if you wanted, with a bounce asking me to enter a credit card at the web page of your choice. Why are you not doing so? 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 Procmail and a CGI would allow this. I don't run a mail server. 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. Let me know what language you prefer. Java -j, who maybe gets a little excited about email because I've writing email software for too long. Help get the Camram code working. steve
The spam problem (was: re:fwd:re:cdr:etc.)
On Sat, 22 Mar 2003, Steve Schear wrote: What part of the infrastructure is being made scarce? You and I aren't part of the infrastructure. The selection of a value for our time is just another market force at work. 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. But its not cash for email transport. The transport cost is unaffected. Its cash for our eyeballs. I find this a distinction WITH a difference. Perhaps you do not. OK, I see you have a different view from many of the ASRG types. I still don't believe the approach will work, but I'll stop attributing to you views of others. Sorry. This is no different than the various request-permission-to-transmit proposals, aside from adding cost to the mix. Doing so will cut down on normal person to person discourse before it fixes spam. Yes, some Balkination may occur at the outset, but this is something that is recipient controlled not something mandated by ISPsm etc. What I was attempting to point out is that adding wealth transfer is not adding any value over request-to-transmit. The IETF anti-spam discussion seems to have broken down into a different religious camps, with many asserting that nothing that can't immediately be rolled out on a universal basis or isn't fully functional until universally accepted should even proposed. I disagree. Yeah, I agree in general. The list is a waste. I personally think the only way there is going to be movement is for Venema or (more likely) DJB to add an optional new protocol that incrementally moves us towards a Bright, Shiny Future. (As an aside that I haven't bothered to voice on ASRG because I think it is pointless, I'd like to see signed headers. MTAs can choose to validate the path. This does nothing directly to stop spam, does nothing to harm anonymous communications, is backwards-compatible, and reinforces black-holes. Building reputations as a mail server has value. AOL won't do it, but Joe-Random-Small-Business will, so incremental uptake can work. I tend to agree with you that the right approach is to _add_ something to mail to assert it is worthwhile to view. Email, like mugging, can be an opportunistic behavior.) Sender pays can be rolled out using PoW stamps almost immediately. Yes, some early adopters may find themselves cut off from senders who either can't or won't make the effort to create and attach computation stamps. For this reason sender-pays should be serious considered by most businesses until widely adopted. But for individuals inundated with spam it could be a quick and effective solution. Of course, the question they will ask when the spam stops is how many others aren't sending email cause they think I'm fringe. :) steve Unless and until Outlook supports wealth transfer for mail this will never happen. Unless and until MS profits from fixing the problem, Outlook will never support the notion. (and if MS does support it, mutt and evolution won't, because that's M$ hegemony. etc.) Sender-pays won't fly. Put another way, you could deny unstamped mail from me if you wanted, with a bounce asking me to enter a credit card at the web page of your choice. Why are you not doing so? Procmail and a CGI would allow this. I'll even write the code for you, if you'll promise to use it on all of your mail. Let me know what language you prefer. -j, who maybe gets a little excited about email because I've writing email software for too long. -- Jamie Lawrence[EMAIL PROTECTED] Politics is the entertainment branch of industry. - Frank Zappa
Re: The spam problem (was: re:fwd:re:cdr:etc.)
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. 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. 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.) Requiring a Passport(tm) account to telnet to port 25 is not my idea of good communication technology. 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. Vendors need to write software for thier own products. If you are unwilling to run the software, I can't help that. (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? Sure, 419 and Make.Viagra.Faster might go away, only to be replaced by legitimate MCI and loan-against-your-home spam.) 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. 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. -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.) steve I think we're reinventing the same goal failure we both saw on ASRG. I'm going to give this up, unless something interesting happens. I'll still write you the code, if we can agree on what the goal is. But I'm not sure this is a worthwhile discussion. -j -- Jamie Lawrence[EMAIL PROTECTED] The sign that points to Boston doesn't have to go there. - Max Scheler
