John,
A few reactions:
Meta issue: You use the phrase "assert a policy" which appears to
actually mean "support authentication". If that is not what you
actually meant, then please explain.
JGM> In my experience, spammers are quick to adapt to changes in the
JGM> ecosystem--much more so than many legitimate users. It is unlikely that
JGM> protecting any of these identities will result in more than a temporary
JGM> reduction in the volume of spam, it will merely change the attack
JGM> vectors that spammers use.
As stated, this asserts that there are no strategic, long-term effects
that we can expect to achieve. As much as I encourage us all to pay
attention to the community's dismal track record in controlling spam,
an assessment of history (through statistics) that is then
mechanically applied to predict an equally bleak future strikes me as
a tad cynical and a whole lot less pragmatic than one might initially
think.
No, I do not think we will ever, entirely eliminate spam. But that is
different from saying that we cannot have any fundamental effects on
it.
The problem, as I see it, is to attack core characteristics of spam.
This, of course, requires getting some agreement on what those
characteristics are and then thinking of mechanisms that go to the
heart of them.
Much of the abuses that we currently suffer derive from spoofing.
Reducing the ability to spoof addresses does not eliminate spam,
directly. As noted, it means that spammers will "simply" create
throw-away addresses, even more than they do now. However
authenticated names are accountable names. With authentication we can
build serious accountability schemes that really do go to the heart of
the abuses.
JGM> Alias expansion across domains will be broken. There exists at least
JGM> one proposal for a new type of expansion to replace alias expansion for
JGM> cross-domain use.
When a design causes a fundamental problem in a legitimate system
mechanism, and the response is to require changing that legitimate
mechanism, there are two problems. The first is the philosophical
difficulty created by cascading sequences of fixes to the fixes. The
second is the considerable fragility to adoption and use
probabilities, that are created by having an adoption dependency
sequence.
All of this should both us all quite a bit.
JGM> Desired forging
OK, folks.
We need to put a stop to this now.
All of us.
These references to "desired forgery" that many folks are making are
just plain wrong.
They are not forgeries.
They are authorized uses of names and addresses.
Everyone, please limit the use of the word forgery to actions that
have some relationship to the technical and dictionary definitions of
the word.
This kind of linguistic referential error is just plain sloppy, and it
makes serious technical discussion challenging at best.
Worse, this kind of inappropriate use of the term conditions folks to
think that it is acceptable to break the usage scenario, when it is
very far from acceptable.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>