This message I think presents a fundamental problem that I have not seen
addressed (or at least referred to to-date) in the discussion, perhaps a
We have this on our "Work Items" list and nobody before did it.
I think you just volunteered - congrats and thank you!
reading of the archives is in order or a document archive contains such.
There were couple emails early on that I remember that contained
some kind of list of requirements. I'll try to find it out and send to you
and the list to help it out.
Requirement 1) The proposal MUST address the issue of RFC821 [or envelope
protocol] originating MTA/MUA authenticity.
There is actually some difference between authenticity between MTAs and
authenticiy of origin (i.e. so that email headers are not forged). That
is why I put it as #1 & #2. I have to think a little bet to see if I can
find how to fraze requirement for my #2 below.
2. We provide means for mail servers to authenticate in such a way that
spammer can not easily change just their domain or their ip and begin
sending email again (they'd soon be detected and their mail server
blacklisted).
See Requirement 1).
3. Law outlaws sending unsolicited commercial email
Requirement 2) The proposal SHOULD be amenable to legislation, in place or
pending as close as possible.
Good. I don't like wording "pending as close as possible". Just "amenable
to legislation" is enough.
Requirement 3) The proposal MUST provide a flexibility for integration with
other ANTI-SPAM (UBE/UCE) approaches [it shouldn't break anything].
Ok with above
But there should be SEPARATE requirement that
"Proposal SHOULD NOT break existing email communication infrastructure"
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.
Make it "providers and end-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.
I'm ok with the above, I did not quite understand why it needed.
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.
Because it says "MAY" this can not be part of the REQUIREMENTS. And I do
not see why fraze like that is needed.
----
William Leibzon
Elan Communications Inc.
william(_at_)elan(_dot_)net
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg