Folks, TH> If you insist on restricting the service to a small set of 'approved' TH> applications, people will simply encapsulate what they really want to do in TH> the approved service and you will lose visibility. A small elaboration: You will make life intolerable for the average user -- ie, the folks not likely to have the skills are working around artificial barriers -- but the non-average user -- ie, including the bad guys -- will encapsulate. DG> The RFC for mail was very well designed. If people simply stuck to the DG> orginal RFC (~800 something) and managed more of their own small systems DG> then this spam thing just wouldn't be the problem that it has become... DG> would it? Well, yes, but no. (I'm finding that a popular response today, because email and spam are so messy.) Email does what it was intended to do pretty well. As with multiaddressing (multihoming and mobility) there is a basic question about the architectural choice for making major changes. I keep wanting the enhancements to stay out of the core. For both areas of work. So, the original Internet mail service does nothing to prevent spoofing or spamming. I think most folks thought that content signing (eg, pgp or s/mime) would be a sufficient solution for authentication and I'd guess we just plain missed the likelihood of spamming. However I still tend to believe that having seen the problem earlier should not necessarily have made the core mail facilities different. In all likelihood, some for of "message" authentication is needed, possibly along the lines of DomainKeys or Teos. My sense is that the technology for this is quite tractable and requires no changes to the email infrastructure. (On the other hand, we need to pay very close attention to the failure to cross the chasm, for pgp and s/mime.) I think that the "registration" oriented authentication mechanisms (spf, rmx, lmap, etc.) can be useful only when the authenticator is the hosting network provider, rather than a message author. SMB> In almost all circumstances, authentication is useful for one of two SMB> things: authorization or retribution. But who says you need SMB> "authorization" to send email? Authorized by whom? On what criteria? , This certainly goes to a core set of issues. The fact that something is authenticated does not mean it is not spam. On the other hand, authentication is a good thing unto itself. On the other hand, making it a pre-requisite for _all_ email activity is very much a _bad_ thing. Authenticating mail will help deal with two problems: forgery and accountability. Forgery of the From field is now a major problem. It has always been a major threat. So, finding a tractable way of prevent or detecting forgery is a worthy goal unto itself. It does not "solve" spam. Rather I think of joe-jobbing and phishing as doing a really spectacular job of market segment development. It has made clear to target customers why they need a solution. Accountability just means that there is a good basis for tracking down problematic sources. That, too, is a good thing. d/) -- Dave Crocker <dcrocker-at-brandenburg-dot-com> Brandenburg InternetWorking <www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>