On Tue, 16 Mar 2004, Ed Gerck wrote: > Dean Anderson wrote: > > > > On Tue, 16 Mar 2004, Ed Gerck wrote: > > > For example, saying that you're "god@xxxxxxxxxx" should not be so > > > easy to do when you're sending email, even though it should still > > > be easy to set "god@xxxxxxxxxx" as your address in your MUA. > > > > The From: address is just dressing. It makes no difference what its actual > > value is, nor that it can or can't receive email. As was pointed out, > > many things only send email, and don't receive it. Those things will have > > informative (or not) from addresses that are invalid for reception. > > Things that send email but don't receive them can nonetheless > have a valid email entry for 'no mail accepted', with no mailbox. What difference is there between 'not accepted, not a valid mailbox', and 'not accepted, never heard of it before'? Either can still be faked, so making a distinction does not remove such an abuse. Such a distinction just makes the broken Verizon mailbox test be a somewhat more "valid" test, but it doesn't change the other negative and non-scalable aspects of such testing. More importantly, knowing this information doesn't help you stop abuse. It is clearly just a reaction to the invalid assumptions made by the Verizon test, and an attempt to make the assumptions less invalid. However, there is no gain by doing so because abusers would simply react by using "valid" addresses that are either "valid, has mailbox", or "valid, no mailbox". rather than simply randomly made-up addresses. After abusers adapt, there is no benefit to the alteration, yet ISPs will have a huge cost in making the changes. The practice of using false and deceptive email addresses has been made illegal by the CAN-SPAM Act, and genuine spammers have largely (or completely) stopped doing this. That leaves the abusers whose aim is purely annoyance who fake from: addresses. But such abusers aren't going to stop faking from: addresses. They will just start faking 'valid' from: addresses that are either 'valid and receive email', or 'valid and don't receive email'. They simply adapt. We have been making gratuitous, dead end, unsuccessful protocol modifications for 10 years now. Unless you can show that this will actually lead to something beneficial, it is just another in a series of gratuitous and expensive changes with no benefits. > In terms of trust as I defined before here [1], an email address > for those things (or any other things) should have a *minimum* > of three values: > > + trusted according to policy(+) > 0 trust value not assigned > - distrusted according to policy(-) > > Of course, the positive and negative range can be expanded > in values as well. How to assign these values? How the trust > model works? Let me copy from an earlier discussion elsewhere. > > This is the wrong question to ask. The real answer is, "what trust > model would you like?" ' Those who suggest that the decision is not whether a trust model, but 'what kind of trust model would you like' are again jumping ahead of themselves. There is no evidence that we need to use a trust model nor that a trust model will solve the problem. Just the opposite. We've had a lot of experience with trust over the last 10 years--and we have frequently found the advocates of trust to be untrustworthy themselves. We have seen repeatedly, again and again, that anti-spammer leaders aren't trustworthy, and use their trusted positions inappropriately for personal revenge. These aren't simply mistakes, but are bald lies that are easily disproved. The leaders know, however, that some people will be misled for some time, anyway. Given that record, how can we possibly __trust__ such a proposition? We can't use a trust model. Further, as previously pointed out, for a trust model to be effective, one needs a method of effective identification which we don't have, and which is a major problem to any trust model, even if the trust operators were trustworthy. A trust model won't work. > The problem is, thus, not how do you determine trust, especially with all > the different definitions of spam possible, but how do you want to do it. I disagree. The problem is how to stop abuse. We have learned quite a bit about that. Mostly, we have learned how not to do it. Some suggest we shouldn't worry about how to stop the problem, but should simply concern ourselves with how to effect gratuitous changes. Of course, they don't describe their changes as gratuitous, but it seems some do think the question of whether the changes are gratuitous shouldn't be considered since doing so impedes their implementation. Obviously, no one wants to implement gratuitous changes. We have certainly learned not to do some things: --- Trust models aren't a solution because the operators are dishonest and untrustworthy, as history and experience with many dishonest blacklists has demonstrated. --- Trust models can't be fixed simply by having more honest operators, since even a perfectly honest trust authority can't establish the identity of users so that trust could be removed from abusers or added to non-abusers. --- Protocol changes aren't a solution, as experience with POP before SMTP, SMTP AUTH, and theoretical results have shown. We have also seen that the problem of Commercial Bulk Email (CBE) has gone away with the CAN-SPAM Act. We no longer have a CBE problem, but an email abuse problem, which is related to the virus and cracking abuse problem. Such abuse is the most pernicious, and is conducted by people for illegal purposes. We expect or hope that the size of this group is relatively small. The solution therefore lies in the realm of legal procedures and law enforcement which proscribes against certain types of behavior, and possibly the automation of whack-a-mole tools that detect and react to abuse, and the enforcement of the rules of law on the abusers. However, this is outside the mission of the IETF. Knowing the solution is outside of its scope, the IETF should issue a statement that deplores the abuse of IETF protocols, but acknowledges that theory and practice demonstrates that the IETF cannot make protocols that will be free from abuse. The existing protocols and present CALEA** support enables tracking the abusers, and legal procedures can then be used to limit such activities. Further, the problem of abuse is not limited to email abuse, but to cracking, viruses, DDOS abuse, and other kinds of abuse that has been proscribed as illegal. It seems very clear that dependence on the Internet will only increase over time, and that over time the activities of persons using the Internet will become subject of greater legal controls. Therefore, the ASRG should be disbanded, since it cannot produce a protocol that cannot be abused, nor can the existing protocols be altered so that abuse is not possible. The IETF should instead focus its energy and resources on how procotols could be altered to support anticipated changes to CALEA, and to support anticipated changes in legal controls. This purpose is only peripherally related to spam and spam-like abuse. **CALEA stands for "Communications Assistance for Law Enforcement Act", and specifies requirements for communications carriers to assist law enforcement. Mainly, it is concerned with specifying capability requirements for supporting interceptions and call-identifying information and compliance with these requirements.