Subject: RE: [Asrg] Technical Considerations for Spam Control Mechanisms

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 27 Apr 2003 20:06:57 -0700

I just took a look, on the whole it is pretty good.

I think you are right in your assement that the chief problem with filtering
is the problem of evasion. I think Paul Kocher has a good description of
this - last mover advantage.

I think the section on blacklists needs to address the problem of
administrative effort. Basically blacklists are on the wrong end of the work
factor vs the spam senders. The task gets harder for the blacklist
maintainers faster than evasion gets for the spam senders.

You do not deal with authentication based approaches at all, yet you do
address 'sender pays' which appears undeployable by your own criteria.

You do not tie your discussion of core vs edge to the architectural
discussion so it is difficult to know what you are meaning. I don't think
anyone is suggesting IP level filtering for spam so what is the core you are
referring to?

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Sunday, April 27, 2003 10:46 PM
> To: asrg
> Subject: [Asrg] Technical Considerations for Spam Control Mechanisms
> 
> 
> Folks,
> 
> I've just send an internet-draft titled:
> 
>      Technical Considerations for Spam Control Mechanisms
> 
>      Summary:
> 
>      Internet mail has operated as an open and unfettered 
> channel between
>      originator and recipient. This invites some abuses, 
> called spam, such 
>      as burdening recipients with unwanted commercial email. Spam has 
>      become an extremely serious problem, is getting much 
> worse, and is 
>      proving difficult (or impossible) to eliminate. The most 
> practical 
>      goal is to bring spam under reasonable control; it will 
> require an 
>      on-going, adaptive effort, with stochastic rather than complete 
>      results. This note discusses available points of control in the 
>      Internet mail architecture, considerations in using any of those 
>      points, and opportunities for creating Internet standards to aid 
>      in spam control efforts.  It offers guidance about likely 
>      trade-offs (benefits and limitations.)
> 
> A copy is now available at:
> <http://brandenburg.com/specifications/draft-crocker-spam-tech
consider-00.txt>

This is very much a first draft.  Comments and suggestions are eagerly
sought.

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: "Eric D. Williams" <[email-masked]>
Date: Wed, 30 Apr 2003 12:45:08 -0400

In your latest draft it is indicated that mechanisms for control at ISP.i, 
MTA.r and/or UA.r are viable for FITLERING [section 4].

Section 4 Notes:

4, para 1
You do not include MTA.o as a locus of control, but you do indicate that MTA.o 
may be operated by the sender OR under separate control [section 2].  In this 
latter circumstance that would appear to be a locus for control using FILTERING 
as well.

4, para 9
Under the two complementary policies Acceptance should also include relaying if 
Rejection allows this criterion.

4.4 Negotiation, para 2

"Senders often refuse..." this may be too strong given no empirical acceptance 
of this fact.  Suggestion: "Senders may often refuse..."

6.1 Adoption, para 4

"Remember that the Internet..." Suggestion: "It should be noted that the 
Internet..."

 para 5
[It may be instructive to define 'core' and 'edge' as related to the section 2 
model]

 para 6
"... once a use"  change to "...once a user"

 para 7
"...system is irritating for the person being challenged, and it imposes..." 
 Suggestion: "...system impedes communications for the person being challenged, 
imposing..."

On Tuesday, April 29, 2003 9:27 AM, Dave Crocker [SMTP:[email-masked]] wrote:
> Folks
>
> DC> I've just send an internet-draft titled:
> DC>      Technical Considerations for Spam Control Mechanisms
> DC> A copy is now available at:
> DC> <http://brandenburg.com/specifications/draft-crocker-spam-techconsider-
> 00.txt>
>
>
> Thanks to those who sent me feedback so quickly.  I have posted a new
> version at the above URL.  (There is also an html version with the
> obvious name.)  The version number is -00 for this draft because the
> first version did not get issued as an internet-draft.
>
> Changes include quite a bit of what I hope is cleanup to the language
> and clarification to some of the content.
>
> The discussion of whitelist/blacklist has been made to match common
> usage.
>
> There are many other small changes such as changing MTA.i to be ISP.i.
>
> Comments are still eagerly sought.
>
> As a reminder, here is the abstract:
>
>      SUMMARY
>
>      channel between originator and recipient. This invites
>      some abuses, called spam, such as burdening recipients
>      with unwanted commercial email. Spam has become an
>      extremely serious problem, is getting much worse, and
>      is proving difficult (or impossible) to eliminate. The
>      most practical goal is to bring spam under reasonable
>      control; it will require an on-going, adaptive effort,
>      with stochastic rather than complete results. This note
>      discusses available points of control in the Internet
>      mail architecture, considerations in using any of those
>      points, and opportunities for creating Internet
>      standards to aid in spam control efforts.  It offers
>      guidance about likely trade-offs (benefits and
>      limitations.)
>
>
> d/
> --