Subject: RE: [Asrg] cost vs. benefit

From: "Eric D. Williams" <[email-masked]>
Date: Fri, 28 Mar 2003 15:11:10 -0500

Thanks Dave. :-)

I think the charter presents a fairly accurate framework.  What I suggest is a 
requirements document, and you are of course (to me at least) articulating the 
exact reason for development of a Requirements statement.  To that end let me 
include in this note the requirements I have cobbled together from this lists 
threads so far:

Requirement 1)  The proposal MUST address the issue of RFC821 [or envelope 
protocol] originating MTA/MUA authenticity.

Requirement 2) The proposal SHOULD be amenable to legislation, in place or 
pending as close as possible.

Requirement 3) The proposal MUST provide a flexibility for integration with 
other ANTI-SPAM (UBE/UCE) approaches [it shouldn't break anything].

Requirement 4) The proposal SHOULD provide implementation specifics that 
address the issues of privacy, security and which reflect end use choices, of 
either providers or users.

Requirement 5) The proposal SHOULD/MAY [not sure how strong this would be as a 
requirement] include a mechanism for implementation in messaging relay systems 
(MX hosts), end use 'post offices' (MTAs), and end node mail recipient systems 
(MUAs).  Proposals that include only one of these messaging system components 
MUST include mechanisms for interaction with the other components.

Requirement 6) The proposal MAY include a method for extension to or 
integration with other protocols, e.g. HTTP, that may be used to relay 
messages.

Requirement 7)  The proposal SHOULD describe a working definition of 
Unsolicited, Solicited, Bulk and other terms used to describe messaging 
commonly referred to as SPAM.

-e

-----
Eric Williams
PGP Public Key
http://new.infobro.com/KeyServ/EricDWilliams.asc
Finger Print: 1055 8AED 9783 2378 73EF  7B19 0544 A590 FF65 B789

On Friday, March 28, 2003 10:39 AM, Dave Crocker [SMTP:[email-masked]] wrote:
> Folks,
>
> wen>         b. If at least some advertisers follow opt-out we should have
> less
> wen>            mail unwanted email
>
> The above statement reflects a frequent orientation towards many
> proposals that are offered. However it misses two, very basic issues:
>
> 1. Implementing and using a proposal is not free. It costs time, money
> and effort. It can affect email infrastructure performance. It can
> affect the user experience. So any proposal must balance these very-real
> costs against the hoped-for benefits.
>
> 2. Barriers to adoption and use are key to the success of any proposal.
> They need to be considered explicitly and realistically.
>
> If this group wants to be productive, it needs to develop a framework
> for evaluating proposals that forces useful rigor onto the developers of
> a proposal.
>
> d/
> --
>  Dave Crocker <mailto:[email-masked]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
>
> _______________________________________________
> 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: Fri, 28 Mar 2003 13:24:36 -0800

> protocol] originating MTA/MUA authenticity.

Hmm.  I would venture that that is just one tool against spam, and not a
necessary one.  A working group on email authentication really is an
independent issue.     I would consider this a MAY, not a MUST.

Again, this is an implementation approach, not a goal.  Or rather, if SMTP
envelope authentication is a goal in and of itself, it's not a goal of
this RG, which is researching solutions to the spam problem.

> pending as close as possible.

Also a MAY.  Legislation is inherently local.  This is an international
engineering body.   We can provide tools to help a general legislative
framework where it might exist, but we should not do anything specific to
local laws like U.S. laws.    And be very wary of "pending" legislation.
There's always tons of "pending" legislation that doesn't have a snowball's
chance of passing, and it would be a serious error to design protocols with
any attention to it.

> other ANTI-SPAM (UBE/UCE) approaches [it shouldn't break anything].

It is required not to break any existing and adopted RFCs but I can see no
reason why it should be constrained by various anti-spam tools out there.
For example, there are now many challenge/response systems out there and I
fully expect that any effort to standardize such activity (for example a
new SMTP response) would possibly break some of them.
> either providers or users.

Russell is working on a much more detailed list for debate of such goals and
constraints which I am sure we will go over in detail.
> MUST include mechanisms for interaction with the other components.

You're getting way to deep into implementation details for a statement of goals.

The broad goal is that whatever is proposed should work within the context
of existing mail transport mechanisms (which of course include MUAs, MTAs,
outgoing relays and incoming relays)
> integration with other protocols, e.g. HTTP, that may be used to relay 

Not sure what you are mean here.   We MAY propose any system that will address
the spam problem, of course.  IS there something specific about HTTP you have
in mind.
> commonly referred to as SPAM.

An important goal for some applications, though based on experience, not one
I think we'll accomplish.

Indeed, any proposal that is of the form, "Mail which meets the [definition of
spam] shall do this, or shall not do that" needs such a definition.

Proposals that instead rely simply on new rules for bulk mail (which I think
we can successfully define) could exist without a definition of spam itself.

There are many components in the various definitions of spam out there, and
proposals can be created to deal with these sub-components, and thus become
tools for people to build tools to attack their vision of what spam is.  Amongst
those sub components are:
		Bulk(volume) vs. Person to Person
		Subscribed (Explicitly, directly solicited) vs. Unsubscribed
		Reply vs. Origination
		Existing Relationship vs. Stranger
These are all components of spam definitions which we can work with without
laying down a spam definition.   Some other components much harder to define are:
		Parameters of implicit solicitation
		Degrees of existing relationship
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Mar 2003 21:17:42 -0800

The list of requirements reminds me just how difficult it is to write
requirements.  They need to talk in terms of high-level behavior of the
system, rather than providing requirements for implementation details.
Therefore they need to be general.  However if they are too general,
they have no meaning.

My following comments are not intended to claim or demonstrate that any
of your suggested requirements are wrong. (In fact, some of the
questions will seem remarkably basis; that's intentional.) I think your
list provides a fertile ground for trying to understand what the
requirements need to achieve, and on what basis:

EDW> Requirement 1)  The proposal MUST address the issue of RFC821 [or envelope
EDW> protocol] originating MTA/MUA authenticity.

You wish to have mechanisms for authentication.  Why at the MUA/MTA
level?  What problem is this solving?  Why at the envelope or transfer
protocol level, rather than some other, such as content signature?

EDW> Requirement 2) The proposal SHOULD be amenable to legislation, in place or
EDW> pending as close as possible.

As noted, legislation has a minor problem of scope.  US laws will not
affect a spammer from another country.  To the extent that anyone thinks
we can enforce the laws of one country on another, we need to assume
that none of this will happen anytime soon and possibly not in our
lifetime.  In any event, we again need to state what problem we see this
as solving and what limitations we expect to encounter.

EDW> Requirement 3) The proposal MUST provide a flexibility for integration with
EDW> other ANTI-SPAM (UBE/UCE) approaches [it shouldn't break anything].

I have no idea what to do with the requirement, at any practical level.
There are no standards for email spam suppression, so there is no formal
basis for knowing what we might break or must not break.

EDW> Requirement 4) The proposal SHOULD provide implementation specifics that
EDW> address the issues of privacy, security and which reflect end use choices, of
EDW> either providers or users.

Again, I have no idea what any of this means.  I can't even guess how to
apply it to specific work.

EDW> Requirement 5) The proposal SHOULD/MAY [not sure how strong this would be as a
EDW> requirement] include a mechanism for implementation in messaging relay systems
EDW> (MX hosts), end use 'post offices' (MTAs), and end node mail recipient systems
EDW> (MUAs).  Proposals that include only one of these messaging system components
EDW> MUST include mechanisms for interaction with the other components.

Please clarify what you mean by "a mechanism for implementation in...".
I am guessing you are looking for a system-wide perspective in any
specific proposal, but I might be misunderstanding.

EDW> Requirement 6) The proposal MAY include a method for extension to or
EDW> integration with other protocols, e.g. HTTP, that may be used to relay
EDW> messages.

Why is this a requirement?  What is the concern?

EDW> Requirement 7)  The proposal SHOULD describe a working definition of
EDW> Unsolicited, Solicited, Bulk and other terms used to describe messaging
EDW> commonly referred to as SPAM.

amen, except that I class precise definitions as a MUST.  right now,
spam is whatever you choose to define it as, or I choose, or...

d/