Thanks for the input Brad.
On Friday, March 28, 2003 4:25 PM, Brad Templeton
[SMTP:brad(_at_)templetons(_dot_)com]
wrote:
On Fri, Mar 28, 2003 at 03:11:10PM -0500, Eric D. Williams wrote:
Thanks Dave. :-)
Requirement 1) The proposal MUST address the issue of RFC821 [or envelope
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.
Requirement 2) The proposal SHOULD be amenable to legislation, in place or
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.
Requirement 3) The proposal MUST provide a flexibility for integration with
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.
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.
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.
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.
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)
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.
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.
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.
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
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