Subject: RE: [Asrg] cost vs. benefit

From: "Eric D. Williams" <[email-masked]>
Date: Sat, 29 Mar 2003 19:16:01 -0500

All;

I could not agree more with Dave here.  It is difficult to cobble a list of 
requirements and NOT implementation specifics (especially for me ;) concerning 
any solution that may be proposed in this, a multi faceted, problem.  Giving 
some context for the list below before moving forward consider the list a 
paper-man (not even a strawman yet) list of requirements(?) generally intended 
to glean some of the thought processes I have derived from reading previous 
postings after joining the list.

I really appreciate the input, and perhaps for a short time we can marry a 
thread of discussion on the issue of requirements and join that with a critical 
view of the current and on-going research into approaches, while moving 
forward.

I also agree that it is much more granular in some cases or over-reaching in 
others then is required, but as I revise it I hope we can draw some consensus 
on key solution requirements, so the bandwidth of this discussion becomes more 
manageable.  And, yes, hopefully it will give of some basis point of 
origination for evaluating the proposals and whether they meet our consensus 
"model" of a solution.

Some enlightenment on my treatment of this issue.  I will use X.400 
nomenclature to describe the infrastructure components AND some common internet 
application protocol semantics to describe how many of the elements interact 
(e.g. MX, MAIL FROM, etc.) I will attempt not to confuse anyone, I am sure most 
are familiar with these terms.  To wit:

MTA = Message Transfer Agent (classic mail servers, e.g., exim, sendmail, etc.)
MTS = Message Transfer System (the entire infrastructure)
MS  = Message Store (a post office MTA, ok?)
MUA = Mail User Agent (your typical end-user mail software, e.g. Eudora, 
Outlook, Hotmail web app, etc.)

On Saturday, March 29, 2003 12:18 AM, Dave Crocker [SMTP:[email-masked]] 
wrote:
>
> 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?
>
Noted.

Why at the MUA/MTA level? --  What I picked up from the various threads and my 
own experience is that a traditional way of dealing with 'spam' is to attempt 
authentication of the originating/sending MTA or MUA (in the case of MTA/MS 
providers) and block that MTA or MUA from transferring further messages into 
the MTS.  My sense is that the case for many is to review 822 header 
information and attempt to authenticate using that, then establish 
authorization rules, others may attempt some type of reverse address mapping 
authentication on connection to validate stated identity (HELO/EHLO 
server.anywhere.net) and then process authorization based on some rules. 
 Integral to each of these methodologies is some form of authentication of the 
origination point.

What problem is this solving? - The attempt is to solve the problem of forgery 
of origination information so that, in either case, the rules established are 
effective for either MTA or MUA origination.

Why at the envelope or transfer protocol level, rather than some other such as 
content signature? - I agree that this should not be so detailed that it 
describes a method for the process, but it sets a bar on solving the issue at 
the earliest point of entry into the MTS.

Revision: Req. 1) The proposal MUST address the issue of originator or 
originating MTA/MUA authentication.

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

What problem is this solving? - This requirement attempts to address the issue 
of marrying a technical solution with public policy or community consensus on 
acceptable use.

Revision: Req. 2) The proposal SHOULD be congruent with community consensus on 
acceptable use of the MTS.

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

What problem is this solving? - The requirement attempted to address the issue 
of interoperation with other methods that conform with this list of 
requirements.

Revision: Req. 3) Tabled.

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

What problem is this solving? - This requirement is for the proposal to provide 
in its description or methodology a 'device' or 'process' that allows user 
control of parameters that govern certain operational aspects such as privacy, 
security.  The parameters could be set either by end users or providers.

Revision: Req. 4) Tabled.

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

What problem is this solving? -  1) We do not want to limit the proposals to a 
total system-wide 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 (MTS) then it should 
provide for interfaces to other interoperable solutions (at least on paper for 
a start and from the same requirement framework); 3) A solution may be for core 
components (MTAs) AND also provide a solution set for the final end-user 
component (MUA), BUT not give implementation specifics.  This is what is needed 
I think as a statement to cover those contingencies.

Revision: Req. 5) Proposals that do not cover all components of the MTS MUST 
include an interface description for use of other components.

>
> 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?
>
What problem is this solving? - None, extensibility to other protocols for MTS 
e.g. MSMQ.

Revision: Req. 6 - moved) Add a 'wish list' as an appendix to the requirements 
list, or as a considerations section.

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

What problem is this solving? - This attempts to solicit a consensus set of 
semantics to 'SPAM' (which is an archaic term).  I choose the term 'working 
definition' because I think as we converge on precise definitions we may go 
through some changes.  I choose SHOULD because I was using a soft mallet.

Revision: Req. 7) The proposal MUST describe in precise definitions terminology 
used to identify messaging commonly referred to as "SPAM".

Requirement 8) The proposal SHOULD NOT attempt to affect legitimate messaging
system uses for bulk mailing.  [This may also be covered by Req 3 but IMHO,
this is more discreeet in the approach.]

What problem is this solving? - Attempts to address the problems associated 
with legitimate uses of the MTS.  This seems redundant.

Revision: Dropped.

Result from this approach:
Revision: Req. 1) The proposal MUST address the issue of originator or 
originating MTA/MUA authentication.
Revision: Req. 2) The proposal SHOULD be congruent with community consensus on 
acceptable use of the MTS.
Revision: Req. 3) Tabled.
Revision: Req. 4) Tabled.
Revision: Req. 5) Proposals that do not cover all components of the MTS MUST 
include an interface description for use of other components.
Revision: Req. 6 - moved) Add a 'wish list' as an appendix to the requirements 
list, or as a considerations section.
Revision: Req. 7) The proposal MUST describe in precise definitions terminology 
used to identify messaging commonly referred to as "SPAM".
Revision: Req. 8) Dropped - redundant.

>
> d/
> --
>  Dave Crocker <mailto:[email-masked]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Regards,

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

---

From: Steven F Siirila <[email-masked]>
Date: Mon, 31 Mar 2003 09:47:01 -0600

> Outlook, Hotmail web app, etc.)

Don't forget:

MSA = Message Submission Agent (typically runs on port 587)

-- 

Steven F. Siirila			Office: Lind Hall, Room 130B
Internet Services			E-mail: [email-masked]
Office of Information Technology	Voice: (612) 626-0244
University of Minnesota
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg