ietf
[Top] [All Lists]

Re: spam

2003-05-27 19:42:13


On Mon, 26 May 2003, J. Noel Chiappa wrote:

...

The *only* thing that's going to stop spam is charging for email. Everything
else is a waste of time, because you're going to run into impossible
arguments trying to define what's spam, and what's legitimate bulk email
(q.v. the recent message about IETF-Announce email).

Needless to say, charging for email means changing the underlying protocols.
That's us. It's not going to be simple (we need an underlying micro-payments
system), and it's going to take a lot of attention to detail (q.v.
IETF-Announce again), but I think it's the only real cure.

What I'd say is that the only way to reduce unsolicited email to a
tolerable level is to change the economics of sending spam such that the
folks paying to send spam will focus their emissions for much higher
positive response rates.

Sending physical advertising has many costs in addition to the transport
cost so it probably costs more than the US 1st class mail rate per piece
even though the advertising rate is much lower. While I get more junk mail
than I'd prefer, 90-95% has some relationship to my interests. If .01% of
the spam I receive has a relationship to my interests, I'd be surprised
(getting rich quick isn't really an interest ;-:).

There is an active proposal, perhaps already submited, in process by Rep.
Zoe Lofgren to establish a penalties and a bounty for spam. This is an
interesting variant of the enforcement paradigm, but I agree with those
who have already suggested that our government too many larger crimes to
consider.

Instead, I believe some form of pay to send stamp based approach in
parallel with the current 'free' system has the best chance of curtaining
spam while preserving the 'free' nature of the current system. This will
require new protocols as well as some social/legal infrastructure to
accomplish (an effective payment system for example). I would expect that
a portion of each sender fee would be credited to the receiver and some
portion would support the new infrastructure.

If we are able to design the protocols I imagine, the mail recipients will
drive adoption fairly quickly once implementations are available. I would
expect that an early filter criteria would be whether the mail arrived via
the new protocols. No, don't relay to my blackberry, cell phone, etc. No,
stick in a 2nd class inbox. Etc.

Since part of this solution would have to be the identification/trust kind
of mechanism Paul Vixie mentioned, easy to implement and utilzed filters
could be based on the sender being identified.

I will shut up now because I think the point of an IETF list discussion
should be to build momentum for working the problem and not design
complete solutions.

Dave Morris




<Prev in Thread] Current Thread [Next in Thread>