William,
I guess I did volunteer, so be it ;-). I would appreciate the forwards,
thanks. More below...
On Friday, March 28, 2003 10:34 AM, william(_at_)elan(_dot_)net
[SMTP:william(_at_)elan(_dot_)net]
wrote:
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.
Again TIA.
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.
That is why I included MUA, but I don't think message headers can be completely
authenticated without signifigant changes to the infrastructure or an
additional protocol implementation. If however, we can stipulate on
'authentication' of the originating MTA then we do come close on addressing
later issues as in two below, e.g. origination of domains NOT valid for the
originating MTAs IP or domain. For isntance we must recognize that the envelope
MAIL FROM has nothing to do with the 822-header From: line, that is a simple
fact. Not to mention the RCPT TO, I will work on it as a requirement statement
and post a proposition.
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.
I will work up some different wording or just drop the pending/in place.
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
Ok.
But there should be SEPARATE requirement that
"Proposal SHOULD NOT break existing email communication infrastructure"
Done.
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"
Ok. How about MUST instead of SHOULD?
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.
I think it is needed for the following reasons:
1) We do not want to limit the proposals to a total solution for the
problem,
so I can change it to an 'either this, that, those or all' requirement
statement.
2) If a proposal is a good one but only for a 'single component' of the
messaging system (MS) then it should provide for interfaces to other
interoperable (at least on paper and from the same requirement framework)
solutions.
3) A solution may be for core components (MTAs/MXs) AND also provide a
solution set for the final end-user component, BUT not give implementation
specifics. This is what is needed I think as a statement to cover those
contigencies.
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.
I agree. I will make a wish list to attach as an appendix or additional
section to the requirements proper.
----
William Leibzon
Elan Communications Inc.
william(_at_)elan(_dot_)net
Regards,
-e
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg