Subject: Requirements - was - RE: [Asrg] Proposal for Opt-Out

From: "Eric D. Williams" <[email-masked]>
Date: Fri, 28 Mar 2003 22:04:00 -0500

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, [email-masked] [SMTP:[email-masked]] 
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.
> [email-masked]

Regards,

-e
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg