"Robert G. Brown" wrote: > > Currently, email addresses are relatively "simple" objects and as such > are easy enough to remember (for humans) and communicate (for humans). > You propose to make an address a "complex" object: the simple address > plus kilobyte-sized blocks of text or binary data such as: > > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: GnuPG v1.0.7 (GNU/Linux) > > mQGiBDprOxURBADW+ybmMpoBfbRADv3OzXaaIQVWGDoaNsR4uxstcJgo+FYMcO9B > Ag7eXRLfOQFPPS3211W/f1/GaQa70ZaPZaQV/A9POIGfRIbcfePHaIUUXYulO3Nh > Bqewb5JZjzkj0yZWdjzK/OSBEPITXMXyTDVnG0+Y4YHHLDOODnnkSOlZKwCg453O > ....(much much more) The key can be given by: 1. return mail requesting an encrypted message with the attached key (as I wrote in my first posting on this suggestion), 2. key server, by using an URL 3. by searching google 4. by using DNS records 5. by reading the email's signature line when my mail reaches you and you want to reply to me. So, there are many, simple and automatic ways for PK distribution. PK certification is another thing, but encryption does not it. Also, humans have been using complex postal addresses for centuries, without even the benefit of computers to help with them until quite recently. Complexity is in the eyes of the beholder. > On the other hand, this additional degree of complexity will be a > horrible burden in time, energy, and money to ordinary users of mail at > every level and especially to systems administrators responsible for > training those users and de facto responsible for managing the data > problem the composite "address" object would represent. Communicating, > managing, and remembering email addresses like "joe@xxxxxxxxxxxxx" is > already "challenging" to many, if not most, users of email and is > obviously equally challenging at the corporate/professional level. Let > us recall that most current AV software is still stupid enough to > consider the From address to actually be valid for viruses and SPAM and > cannot even manage to parse the real message header in sensible ways. > Now visualize these same bozos trying to deal with messages whose header > contains a 1-2K key:-/ This will all require a level of automation and user-friendliness way above what we have today. Nonetheless, possible and necessary if we want to (1) preserve email confidentiality and (2) provide an even mandatory burden to sending email. On the flip side, I can see all your arguments above applying to the difficulty of sending spam -- in addition to the time burden. > Obviously, people will no longer be able to just say "here's my email > address". Not true. After you send an email and you'd get a bounce requesting an encrypted message, with the public-key included. In fact, you can easily use your email as a way to distribute your PK with the benefit of challenge-response -- if your email is active, the sender gets the current key for that address. You can also use it to update your PK, easily. > Business cards will need to be roughly 4x6" and covered > mostly in small type. Most users will simply rebel. Most systems > people will simply rebel. :-) not really...see above. > People CAN send encrypted, signed email now, > but how many do? 5%. The failure is actually ours, not making it easy to use. Just ask any email user...How do they feel when they understand that email is really like a postcard... open for anyone to read? How do they feel about spammers having near zero cost to send them messages while they need to use valuable time and resources to weed them out? > You are also suggesting that the encryption step, by being "expensive" > computationally, will at least slow down the spammers. This assertion, > which has been made several times now, is simply not true. > [snip, good comments] The point is that it CAN be made very expensive for sending 100,000s of emails. In addition to the PK encryption of the random symm key used to encrypt the message (in PGP, for example) you can also add the recipient's PK MACs to tie the recipient's PK to the message as well. Further, the proposal should include "puzzles" to be solved by the sender (a la hashcash) that can penalize an unknown sender as much as desired and trickle its output as much as needed. Users can also require less burdensome encryption from known parties, without "puzzles". There is nothing to prevent a spammer -- as an entity with NO previous relationship to the receiver -- to be penalized at will, while known users mail send messages with regular encryption or even no encryption at all (by using whitelists). I'm thus led to the opposite conclusion that you suggest: I think that it is clear that this proposal can have a significant impact on SPAM generation, while but it will not have any, or hardly any, negative impact on ordinary mail users.