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/
--
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