Subject: [Asrg] 8a. Evaluation Model - Technical Considerations Document

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 15 Sep 2003 14:19:12 -0400

The technical considerations document has been available for some time at:

http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt

This document outlines some of the most important underlying assumptions 
for proposals and evaluation of proposals.  We would like to jump start 
a discussion on it, to move it towards the next draft. Please review the 
document and post your comments, questions, concerns to the list.

Yakov

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

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 16 Sep 2003 10:49:31 +0100

> Please review the 

I'm sure I've made this point before:
the assertion that
"...there is no opportunity for software
     control of spam in UA.o ,  because the software is
     under the control of the originator. "
is too strong.

In the (not inconsiderable) case of a Webmail system  there is
a clear opportunity for spam control. The software is NOT under the control
of the originator. Providers of (free) webmail systems should have their
attention drawn to their responsibilities in this area.

This assertion should be qualified. Perhaps "Except in cases where the UA
software is not under control of the originator (for instance in the case
of "Webmail" systems) ... In which case, a responsibility for spam control
(on egress) rests with the provider."

--

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 16 Sep 2003 07:27:19 -0400

1) I believe the following paragraph in 3.3.5 Filter Rules:

    The idea of replacing SMTP is appealing because it
     permits thinking in terms of creating an infrastructure
     that has accountability and restrictions built in.
     Unfortunately an installed base the size of the
     Internet is not likely to make such a change anytime
     soon.  It seems far more likely that successful spam
     control mechanisms will be introduced as increments to
     the existing Internet mail service.

Seems to me to be out of place.

The statement has nothing to do with filters.  Its more of a upfront general
consideration statement that suggests that proposals that modify the
specifications must be backward compatible.   Proposals which do not allow
for backward compatibility should not be considered.

2) I think this "consideration guideline" should include a suggestion for a
"SMTP Modification Level" that all proposals should indicate such as:

    SERVER COMPATIBILITY

         This proposal complies with ESMTP
         This proposal does not comply with SMTP, ESMTP

    CLIENT COMPATIBILITY

         Requires compliant client
         Does not require compliant client

Or something equivalent (a table?). Many proposals are just server level
changes, some proposals require changes at both the server and client, etc.
This will save vendors a lot of time when exploring which proposals are
worth of consideration.

Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
----- Original Message ----- 
From: "Yakov Shafranovich" <[email-masked]>
To: "ASRG list" <[email-masked]>
Sent: Monday, September 15, 2003 2:19 PM
Subject: [Asrg] 8a. Evaluation Model - Technical Considerations Document

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 16 Sep 2003 17:43:35 -0400

Jon Kyme wrote:

>>The technical considerations document has been available for some time
> 
> at:
> 
>>

Just an additional point here - the webmail providers should account for 
automated scripts and WebDAV tools (like HotMail) that exploit their 
systems. Perhaps even not providing such tools should be recommended 
(BCP area probably).

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 16 Sep 2003 17:55:00 -0400

> for backward compatibility should not be considered.

This also seems to overlap with the requirements document 
(http://www.irtf.org/asrg/draft-irtf-asrg-requirements-xx-01.txt):

-----------snip------------
2.1  Use of existing RFCs

  ASRG proposals SHALL reference and use previously published
  RFCs where possible.

2.1.1     Rationale:

  The IETF has already completed a great deal of research and
  work into the areas of authentication, identification,
  authorization, messaging and messaging communications and other
  related protocols.  In order to facilitate the work of this
  group and its search for a solution it is wise to consider
  defined and accepted standards.
----------snip---------------

> This will save vendors a lot of time when exploring which proposals are

This is a very good idea for the proposal guidelines. Would you be 
interested in writing them up?

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 18 Sep 2003 23:29:52 -0400

>> document and post your comments, questions, concerns to the list.

I wanted to add some points and thoughts, and hope that all of you will 
contribute as well.

1. What is the intent of this document? It is titled "Technical 
Considerations" however tt seems that the document includes aside from 
general considerations, also a discussion on available points where 
control can be placed, standards opportunities and an evaluation model 
(towards the end). Perhaps the title of the note should be changed, or 
the document should be split up into several smaller ones (for 
standards, for evaluation, etc.).

2. In section 1 of the document, there is a considerable discussion as 
to what the definition of spam is. However, the charter states that:
<snip>
	The definition of spam messages is not clear and is
	not consistent across different individuals or
	organizations. Therefore, we generalize the problem into
	"consent-based communication".
<snip>

The intent of the charter seems to stay away from defining spam. 
Additionally, section 1 is title "spam and consent" but does not go into 
a discussion about consent. Perhaps this section can be synced with the 
charter or with the consent framework 
(http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html). 
Additionally, perhaps importance of an overall framework or model for 
anti-spam tools such is the consent framework needs to be mentioned.

3. In section 2.1 during the discussion of control points, the 
discussion stops at originator's MTA (MTA.o). First of all, a bit more 
discussion can be spent on the MTA.o especially if it is controller by 
the spammers, and also discussion is needed on points of control at 
MTA.i, MTA.r, and UA.r which are on the side of the ISP or the receiver. 
Even though it is preferable to have control closer to the source of the 
spam, nevertheless many anti-spam tools operate on the receiver's side.

4. In section 2.2.1 several types of evalutions are given: originator, 
content, destination and traffic. What about consent, should we be 
evaluating whether the sender has consent to send email to the receiver 
in line with the charter?

5. Section 2.2.1 also states "The other avenue is post-hoc removal of 
the right to make further use of the MTA service." What about post-hoc 
removal of network access?

6. In section 2.2.3, 2.2.4 and 2.2.5 examples are given with a filter. 
Are these sections refering only to detection with filters, or any 
anti-spam tool? If later, then it should be mentioned.

7. Additionally the entire section 2.2 seems a bit strange. It starts 
off with four foci of evaluation yet proceeds to go into explaining one 
of them and defining additional terminology. More clarification and 
organization in this section is needed.

8. Section 3, approached to controlling spam and the taxonomy of 
anti-spam systems 
(http://www.irtf.org/asrg/draft-asrg-taxonomy-anti-spam-systems.txt) 
need to be synced. The research agenda also needs to be synced with this.

9. Section 3.1, administrative and legal approaches - should a note be 
made that the document addresses mainly technical approaches?

10. Section 3 needs to be reorganized. It includes four approaches - 
legal/admin, infrastructure, filtering and negotiation. However, some 
approaches are placed in the wrong section - for example replacing SMTP 
is within infrastructure not filtering. DNS-based approaches and 
network-wide spam detection approaches are not mentioned in the 
infrastructure either, while a lot of discussion is spent on filtering. 
  Collaborative filtering is not mentioned, and many other proposals and 
approaches are missing. Additionally, the filtering section needs to be 
re-organized better and re-written to be more clear.

11. The entire evaluation section (section 4) and the requirements 
document 
(http://www.irtf.org/asrg/draft-irtf-asrg-requirements-xx-01.txt) need 
to be coordinated and synced.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 22 Sep 2003 12:50:02 -0400

Just a reminder to everyone - the technical considerations document is 
one of the foundational documents for the group, and it is important for 
us to get it done. Please participate in the discussions or if you're 
shy contact us off-list :)

Yakov