Subject: RE: [Asrg] The "problem" from an engineering standpoint

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Mar 2003 17:19:30 -0800

I think that is ok for the first order problem, although writing this on a
rim pager, I would like to be able to decide which messages are worth payin
to download.

The second order problem caused by would be solutions is also a major
concern. It really is a prolem if email does not get through because of
filters blacklists etc. It is a problem if a blacklist starts pinging
servers repeatedly every few seconds. It is also a problem if a blacklist
attempts to blackmail me into changing isps with blacklisting based on other
customers behavior.

 -----Original Message-----
From: 	Brad Templeton
Sent:	Wed Mar 26 14:45:41 2003
To:	[email-masked]
Subject:	[Asrg] The "problem" from an engineering standpoint

While I know the spam definition question, though in the long term
unavoidable,
is a quagmire, let me redirect to something that might not be so
intractable.

That is, "what is the problem we're here to fix from an engineering
perspective?"

Some in the anti-spam community have written like they think the problem
is they got a mail they didn't like or didn't ask for, and this is what
must be solved.

Let me express why I think we're here and see if people agree.

    1) Unwanted E-mail volume is sufficient to put a major burden on servers
	and pipes.
	Goal: Reduce the volume so it is a tiny fraction of desired traffic
	and thus no longer worthy of engineering notice.

    2) Unwanted E-mail volume is sufficent to reduce the signal/noise ratio
        in user E-mail boxes, making them of lower utility to their users.
	For some users (mostly outside USA), noticeable costs are also
	incurred.

	Goal: Reduce that volume to minor nuisance level, so that users are
	not averse to using E-mail because of it.  A S/N of 100 to 1 would
        certainly do this, for example.

    3) Users are afraid to reveal their E-mail address in public, mostly
        because of problem #2.

	Goal: Eliminate that fear.  May be done by eliminating problem 2,
but
	there are also other ways to go after this problem.

    4) Service providers suffer undue cost handling complaints about mail
        which originated from their networks, or didn't originate there but
        appeared to originate there.

	Goal: Reduce complaint volume to manageable levels.

So while I have done nothing to rigidly define spam, I hope I have stated
why we are here, why people think there is a need to fight it, for
engineering reasons.  Is this a better place to start?
	
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Templeton <[email-masked]>
Date: Wed, 26 Mar 2003 17:30:35 -0800

> rim pager, I would like to be able to decide which messages are worth payin

Indeed, though the network design will only be moderately influenced by the
needs of small volume users who choose to use particularly expensive channels.
We want to help them, but the ability is more limited.
> attempts to blackmail me into changing isps with blacklisting based on other
Absolutely.  There are a number of general goals -- Russell is trying to
enumerate them -- which govern how we can solve the problem.

The first step though is to describe the problem from an engineering standpoint.
What's going wrong, and what is the standard to reach to declare it as
fixied.

I have an extra thing to add to the problem.  I enumerated the trouble of
ISPs handling complaints (valid and invalid) but we should also include
the problem of end users having to deal with bogus complaints.  (We are
not so worried about spammers dealing with legit complaints)

We would like to fix the DoS attack that spam can be, when somebody spams
in your name and you take the flack for it.

Any other items to add to the _problem_ set?  We can also specify the other
goals and constraints that govern now we solve the problem, such as avoiding
invalid blacklisting and so on.

But first we must identify the problem and a test to decide we have solved
it, then outline the other constraints and goals, and come up with the
best solution that solves the problem as well as it can considering the
constraints and other goals.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg