Subject: RE: [Asrg] 4. Survey of Solutions - Consent Model

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 04 Jul 2003 14:09:17 -0400

I will be rewriting the document to in line with these suggestions.

At 01:50 PM 7/4/2003 -0400, Bob Wyman wrote:

>Yakov Shafranovich wrote:
> >I wrote up an document on the consent model
>         I think it would be good to strip from the document the general
>discussion of the spam problem and focus on the technical framework. One
>can assume that the nature of the problem is well understood -- the
>"evils" of spam are well-known problems. As it stands now, the
>discussion of motivation for the proposal simply makes the document much
>larger without really adding much.
>         Also, while I would certainly include a short (one-paragraph?)
>section on motivation and ensure that the paragraph mentions spam, I
>think the document should focus on "consent" not "spam." Ideally, spam
>would only be explicitly mentioned in a short description of motivation.
>The rest of the document should only talk about consent. The challenge
>of the document is to define how consent is expressed and managed. Such
>a framework can have value dealing with more problems than simply
>providing part of a solution to the spam problem.
>         In general, I think it is not useful to quote other documents at
>length. Given hypertext, we're able to easily and effectively reference
>other documents without burdening every document with large extracts of
>others. Ideally, the consent framework would be a concise description
>where every line had value on its own and wasn't simply a repetition of
>data found elsewhere. The simpler the document is, the easier it will be
>for people to understand it and evaluate it.
>         I think there are some labeling problems in the current
>document. For instance, a "lookup in a realtime black list" is not a
>"policy enforcement mechanism." Rather it is a means for determining
>some attribute of a message which can then be fed into the policy
>enforcement mechanism. (i.e. Message has the "sent from blacklisted
>node" attribute. Thus, the enforcement mechanism -- which is distinct
>from the mechanism that did the blacklist lookup -- decides to reject
>the message or put it in a graybox.) The same comment applies to most of
>the other things mentioned in this section. They are all means to
>discover attributes of a message -- it is only anecdotal that most
>implementations of these methods are bound to specific enforcement
>policies. The framework should clearly identify the distinctions between
>components of a system.
>
>                 bob wyman
>
>
>_______________________________________________
>Asrg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/asrg

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 13 Jul 2003 20:36:35 -0400

At 02:15 PM 7/9/2003 +0100, Andrew Akehurst wrote:

> >> ........
> >> In the ultimate scenario where everyone uses some implementation of
> >> this consent framework it would be fine to make no distinction. However
> >> for the purposes of interoperability with non-compliant systems during
> >> roll-out of the new consent framework
> >> ........
>
> > The "new" consent framework is not replacing the current structure of
> > the Net. It is an ABSTRACT model that allows us to evaluate all anti-spam
> > proposals.
>
>I understand, all that I meant was that implementations will have to consider
>interoperability issues. I take it you feel that interoperability is not
>relevant to the model itself, only to specific proposals?
>
>That would make some sense, but we are still proposing a change to current
>behaviour in that we have new reasons why messages may not be delivered to
>their intended recipient (i.e. lack of consent). Therefore some messages 
>which
>would have been delivered under the existing system will not be delivered 
>under
>implementations of the consent framework.
>
>Since you say the purpose of the framework is to evaluate anti-spam 
>proposals,
>one of the criteria should be the likely impact on existing usage and
>interaction between existing users and those who have migrated to 
>consent-based
>software. Some of that detail will depend on implementation, but some 
>abstract
>ideas are so fundamentally different from the current system that *any*
>implementation of them would affect interoperability.
>
>Of course I know there are already many reasons why e-mail may not arrive 
>under
>the current open system, such as an invalid recipient e-mail address or a 
>lack
>of disk space at the receiver's incoming mail server. So maybe this issue is
>less important (to the abstract model) than I first thought.
>
>Anyway, I'd be interested to hear your comments about the issue.

There is a separate requirements document 
(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05084.html) 
outlining specific point-by-point requirements and a "Technical 
Considerations" document 
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt) 
which outlines more overall requirements. These are meanth to be used in 
conjunction with the model document.