Response to Dave Crocker's request to respond to the Tech-Consider questions. 

1. Adoption Effort - The proposed mechanism can be added to existing implementations of SMTP servers without any major adjustments. The only additional mechanism required is the ability for a user to add and remove accounts for his/her account. 

2. Threshold of Benefit - users who adopt the mechanism will have immediate benefits. Success for a user is determined only by the user's adoption of the procedure.  No outside inflence is required. 

3. Impact - Senders will only notice a different email address, nothing will be technically different for them. Recipients will see nothing different in the receive proccess, but when distributing addresses they will have to be concious of what address they assign. The styles of operation aren't significantly changed. 

4. Impact (external) - No effects to external parties will occur. Legitimate email users will not be blocked by this procedure. Spammers can pass through for the first time, but as soon as the user identifies the "TO" address as an address that is being attacked by SPAM the address can be flagged and all mail to it can be disposed of. There is no change of nature of email for people who don't adopt.

5. Ongoing effort - maintainance is minimal. the users will add or discontinue addresses as needed. The procedure does not effect affect regular email. 

6. Balance of Burden -  The burden is mostly on the user, but the burden is minimal, the only work required is maintaining the list, and that function could easily be intergrated into an email client to allow for easy list manipulation. 

7. Use by Full Internet - If everyone adopts it, then everything should still function normally (except a lot less SPAM). The fabric of Internet mail should see no ill effects, even if this is used on a large scale. 

8. Growth - Increasing by 1000 times should not be a problem, as long as the mail servers are upgraded as they would be if this procedure wasn't in place. The fabric of Internet mail is still safe. 

9. Efficiency - The proccess uses existing techniques (although used for different purposes) efficiently, and this procedure can use them efficiently also. The proccess will be able to operate at about the same speed as current, but some mild delays (not more than a few seconds) could be incurred while mail is being sorted. Proccessing is a little higher while mail is sorted and the alias is followed, but existing mails systems do it all the time without any consequences, storage requirements will be less because the mail is being sorted and most SPAM is hitting a dead-end box that is deleting mail instantly. 

10. Cost - No major expense will be incurred. 

11. Reliability - Non-SPAM mail should all arrive in its proper location, the user has control over what gets in and what doesn't. Non-SPAM is more likely to arrive at its destination and not be lost, due to both the end user control and the absense of distracting SPAM. 

12. Internet Impact - Only the parts that adopt it. 

13. SPAM Impact - SPAM sent to addresses determined by methods other than guessing, and dictionary attacks should be very well suppressed. Once an attacked address is identified it can be eliminated, there is still the issue of the intial mail, which prevents this procedure from being 100% SPAM-free. 

14. Circumvention - the only way to circumvent the procedure is to find another address after the first time mail is sent (because of the user's ability to kill addresses). If a catch-all is used by the user it may be circumvented with a simple random addressing (this is why this was removed from the draft, and discouraged in future drafts). No effect to non-SPAM mail will occur unless non-SPAM mailers sell their address lists to SPAMers. 

15. Personal Post/Reply - using the personal email option, which uses a whitelist, will require the sender to respond to a whitelist addition request. If the personal option is ommited, then the sender will initiate an email with the recipient as usual (using the address provided), but most likely using a unique FROM address.  Once a "trust" is establised the two can use a simple-non unique address if one is availible. 

16. Mailing Lists - mailing lists will be assigned their own address like anything else used by the user. All replies, etc should still work. As a personal reccomendation, each list should be given its own full address on the server, and not just an alias for easy management, but that should be left to the user's discretion. 

17. InterEnterprise - an address shall be issued for each user with the name of the team in it, such as user(_dot_)team1(_at_)example(_dot_)net (or team1(_at_)user(_dot_)example(_dot_)net). As team affiliation changes the address can be modified. Intrateam communication should not be affected. For internal enterprise communication an address similar to the personal (trusted source) address should be used.