Hi, Ed, I don't know everything about e-mail, although I do send and receive e-mail from time to time. I would be interested in reading reasons from others why this is a bad idea. It seems interesting to me. The only thing I'm wondering about is, since all the press reports about recent viruses say they set up zombie networks, I'm wondering if placing a CPU burden on someone who controls 100,000 PCs is harder than you think... Spencer ----- Original Message ----- From: "Ed Gerck" <egerck@xxxxxxx> To: <ietf@xxxxxxxx> Sent: Sunday, February 08, 2004 6:05 PM Subject: proposal for built-in spam burden & email privacy protection > > Email privacy and spam are such general problems today that I'd > like to ask the ietf-org list for feedback (private if you wish) > on this suggestion. There are more specific forums where this > can (and shall) be discussed. > > Suppose: > > 1. I make my public-key available wherever my email address is given; > > 2. Except for senders in a whitelist (e.g., list mail), I bounce to the sender > any email that is NOT encrypted with my public-key, providing my > public-key and instructions for the sender to resubmit the message > properly encrypted. > > This would make spammers pay FOR EACH message sent, as messages > would need to be encrypted FOR EACH recipient. At the same time, it > would promote email privacy protection en route, including at ISPs > and before mail pickup at POP boxes. > > The end points would not be authenticated at this time, making it much > simpler to implement. Sender authentication is also not effective as a > burden mechanism for each message. > > The built-in spam burden & email privacy protection afforded by this > procedure would not be costly to use as there are several free tools > available for encryption. The whitelist should provide a backward path > for those who don't want or can't use encryption at this time. > > Comments? > > Cheers, > Ed Gerck > > _______________________________________________ > This message was passed through ietf_censored@xxxxxxxxxxxxxxxxxxxx, which is a sublist of ietf@xxxxxxxxx Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator (ietf_admin@xxxxxxxx).