On Sun, 8 Feb 2004, Spencer Dawkins wrote: > 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... This would scale terribly in so many ways, and ultimately would be no more effective than anti-spam methodologies already in place. A whitelist is a whitelist, esig or not. How does this in any way alter the flow of SPAM or a spambot's operation other than to add a step? Anything at all that generates a bounce message on a mass-produced mailing acts as a "damage amplifier" from the basic internet backbone's point of view -- at least doubling the associated automated traffic and wasted/misused resources. These days such a bounce is especially fruitless, as all viruses and quite a lot of SPAM have forged headers that the stupid bounce agents cannot or do not parse. This is pet peeve of mine as it is -- I got (and continue to get) more bounce messages from mydoom reporting that mail "from me" is contaminated than I do copies of the virus itself. No virus for two years now hasn't forged mail headers -- the From field is totally irrelevant in all current viruses-- yet all the AV programs in the world think they are doing you a favor. NOT. Now imagine that sort of stupidity scaled out so that every MTA in the world is checking esigs and bouncing improperly signed mail. Imagine the loops created when a legacy mailer or improperly configured mailer bounces the bounce messages back to the bouncer, to be bounced again. Nightmarish. rgb > > 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). > > -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx