To avoid the trend of people only airing negative opinions, let me say
that I think Brad's narrow content-neutral unsolicited high volume
definition to be spot-on. We really must avoid solutions which reduce
functionality, reliability and freedoms of email.
I'd also encourage everyone who hasn't to read Brad's principles page:
http://www.templetons.com/brad/spume/prin.html
I'd like to see the group adopt this set of principles as basic
requirements of the "first do no damage" kind, where as we evaluate
technology we hold it up to these principles.
It's easy to notionally fix spam, if one starts out with assumptions
that include damaging reliability and functionality, or could work if
fully deployed but offer no obvious route to deployment.
I think solutions need to provides value to people who upgrade,
without damaging backwards compatibility so that there is incentive to
upgrade.
As one example (not that it hasn't got other problems) on the CAMRAM
list (CAMRAM is a hashcash related proposal) someone proposed using
hashcash to white list to avoid false negatives of Bayesian filters.
This seems good from the above perspective because as a sender you
have an incentive: if you use this system mail you send will not get
falsely filtered by Bayesian filters; and it is backwards compatible
because people who don't use it to send can still send and receive
mail (modulo the false negatives of Bayesian filters).
And as well as slowing spam if it becomes widely deployed, due to the
computational cost of hashcash, it increases reliability as the false
negative problem is reduced for it's users.
That plus signatures as white-lists so that hashcash is only used on
the first email is the basis of the CAMRAM proposal: http://www.camram.org
Adam
On Tue, Mar 04, 2003 at 08:00:08PM -0800, Brad Templeton wrote:
The purpose of a definition of spam is to use legal tactics against
it, typically in contract law, but also possibly in statute.
That's because you must be clear on what it is you're going to punish,
so people should be able to know when they have violated the rule,
or been the subject of it, and so a fair and impartial body can
objectively determine it.
To that end, a legal definition of spam must include nothing but spam,
and will not include all things that you think are spam.
That's because, to get people to agree to enforce it, they do not
wish to be in the position of punishing that which they think is
legitimate mail, nor do those who are creating the system want to
be in the position of chilling legitimate communications.
(In the USA and some other nations, laws are constitutionally required
to block nor chill any legitimate communications, and to be precise,
and to be the least restrictive means possible to solve the problem.)
That least restrictive means test is also a good one to borrow.
Should the global system have a narrower definition, as it must,
this does not preclude private systems from working to stop things
not covered by that definition as best they can.
Thus if a system based on national law, new protocols, or pooling of
MX servers only stops bulk mail above volume X form parties matching
description Y, and you want to add onto it a system which blocks
based on content (Viagara) or intent (advertising) or source (blacklists)
then you are in no way stopped from doing so. Indeed you can
even make the system big as the population that wants it.
However, for a system to be implemented by the IETF or similar body,
a much narrower concensus is required, as this will be the default
for much of the E-mail system of the world.
That's a pretty heavy burden. E-mail is all based on private
property, and thus not subject in many cases to 1st amendment and
related protections from private action, but we as architects of
such systems must think of that as a bug, not a feature. We should
not be glad that we don't have to worry about that pesky first
amendment.
Do people disagree with these principles? If so, let us know.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg