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(_at_)heaven(_dot_)org" should not be
so
easy to do when you're sending email, even though it should still
be easy to set "god(_at_)heaven(_dot_)org" 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.