Subject: [Asrg] ASRG next steps

From: Paul Judge <[email-masked]>
Date: Tue, 4 Mar 2003 15:58:34 -0500

Hello all,

I would like to welcome everyone to the ASRG mailing list. I'm sure that
each of you are here because you have an interest in the development of a
solution to the problem of unwanted email messages (not to leave out the
spammer spies that are among us). There are a number of parties on the
mailing list that bring unique experiences and perspectives to the table.
There are also a number of people that have spent time working on either
current anti-spam systems or proposals for new approaches to the problem.
This is a unique group of individuals that represent a wide spectrum of
types of organizations. We have the ability here to effect real change on a
large scale. I look forward to working together.

I appreciate everyone that has shared their opinions and ideas so far.  In
order to provide some structure and direction to this conversation, I ask
that everyone on the mailing list become familiar with the charter of the
research group. (http://www.irtf.org/charters/asrg.html) . I worked closely
with Vern Paxson, chair of the IRTF, with input from a number of others in
the Internet community to carefully frame the scope of the research group.
You will notice that the charter indicates no bias towards any particular
approach to the problem, but seeks to foster an systematic and objective
approach to pursuing the solution. 

There are some points from the charter that everyone should be familiar
with:

View of the problem: "Consent-based communication"

Components of a solution:
1. consent expression
2. policy enforcement
3. source tracking (authentication/identification/non-repudiation)

Goals of the group:
1. understand the problem
2. propose solutions
3. evaluate solutions

Milestones/Deliverables:
1. problem statement/ requirements document
2. taxonomy of existing approaches
3. taxonomy of proposed approaches
4. evaluation of existing and proposed approaches ( to include usefulness,
monetary cost, affect on normal use of email, legal support of the solution
and vice versa)
5. transfer of technology (possibly through standards proposals to the IETF)

Other key thoughts:
1. stop the threat as close to the source as possible
2. cast the spam problem into different perspectives to leverage previous
work (i.e. denial-of-service; intrusion detection; authentication,
authorization, and accounting)

I am seeking comments on the charter.  
-does the consent-based communication viewpoint sufficiently generalizes the
problem? 
-do the three components cover the requirements?

I am seeking individuals that are interested in taking a more active role in
managing one of the first four deliverables mentioned above.

Paul

___________________________________________________
Paul Q. Judge, Ph.D.                 [email-masked]

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 4 Mar 2003 15:08:02 -0700 (MST)

> From: Paul Judge <[email-masked]>

> ...

> ...
> ...

What is "consent expression"?  If it is not a trivial boolean like 
"I do [not] like spam," how can it not be a magnet for abuse ranging
from minor privacy violations to more spam to literal visits from
death squads reducing their political enemies?

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Keith Moore <[email-masked]>
Date: Tue, 4 Mar 2003 20:32:15 -0500

> -does the consent-based communication viewpoint sufficiently generalizes the

It seems like a stretch of the way 'consent' is normally used.  One aspect of
it with which I agree is that spam is in the eye of the beholder.   We
probably do not want a system that presumes that certain kinds of content are
spam.  It's not clear to me whether we even want a system that allows
recipients to declare 'consent' for certain kinds of mail and that permits
upstream filtering of their mail that doesn't meet those criteria.   I can see
where such a system might be useful, but I doubt that it would be a good idea
to rely on it as the only mechanism for reducing spam.

> -do the three components cover the requirements?

It's too early to tell.

I suspect that 'consent expression' (if I understand what it means) is
essential to any approach that allows filtering of messages prior to delivery
of messages to the recipient.  I don't want some upstream MTA filtering mail
that is sent to me without my consent. 

'Policy enforcement' as defined in the charter seems to me to be too
restrictive.   I am not going to trust a remote MTA operated by another ISP to
'enforce policy' for me.   Here's another way to think of it: it might be
useful to have a feedback path from recipients into the message transfer
system (MTS) which helps the MTS prioritize traffic so that the MTS does not
waste resources transmitting mail (or by extension, waste resources that
recipients use in dealing with mail that is delivered) which will not be read.
Similarly, there's no need for the MTS to immediately deliver mail which the
recipient is not willing to immediately accept.

And *some* kind of 'source tracking' (but not necessarily authentication,
identification, or even non-repudiation in any strong sense) is essential to
any approach that tries to penalize or marginalize those who send spam
(regardless of the granularity with which this is done).   But it's not yet
clear whether we should recommend this as part of the solution.

I think these are fine as examples as possible components (as indicated in the
charter), but we should not expect a priori that these are the only components
or even that all of the above will be necessary.   Which is not to say that I
disagree with them, just that the charter should not anticipate the outcome of
the group.

> 5. transfer of technology (possibly through standards proposals to the IETF)

Please, please, please, let's take the word "requirements" out of #1.  It's
bad enough that working groups get caught up in trying to define requirements
of problems they do not understand.  We're not even a working group.  If
we identify a couple of requirements in the problem statement that we can all
agree on, that might be okay. But focusing on requirements will tempt us to
nail too may things down, and invite ratholing.  

I suggest that 2 and 3 be combined, with a clear indication of which
approaches are existing and which are merely proposed - partially because I
think it will be more useful to have all of the approaches side-by-side, and
partially because I think existing/proposed is a spectrum rather than a bit.

> managing one of the first four deliverables mentioned above.

I've informally started trying to do 2&3 already with the idea of producing a
draft after a couple of iterations on the list.

Keith

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 06 Mar 2003 11:19:46 -0500

> -do the three components cover the requirements?

Paul,

Do you think it would be worth while to consider generating BCPs and 
such for various aspects of existing and potential "solutions"?

For example, it would help do some level setting if we had some common 
documents on:

	- BCP/general principles for spam filtering
	- Enumerations of existing anti-spam technologies.

I have a brief document that could be a nucleus for a spam filtering 
BCP, and could whip up something quickly that documents classes of filters.