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:dhc(_at_)dcrocker(_dot_)net] 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
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.)
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg