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:dhc(_at_)dcrocker(_dot_)net] 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: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