Re: [apps-discuss] Updating the status of SPF

Dave CROCKER <dhc@dcrocker.net> Fri, 12 August 2011 18:01 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A9521F8747 for <apps-discuss@ietfa.amsl.com>; Fri, 12 Aug 2011 11:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.601
X-Spam-Level:
X-Spam-Status: No, score=-5.601 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynCZ-6QUG-eP for <apps-discuss@ietfa.amsl.com>; Fri, 12 Aug 2011 11:01:15 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 167A221F8745 for <apps-discuss@ietf.org>; Fri, 12 Aug 2011 11:01:15 -0700 (PDT)
Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7CI1ldh023338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Aug 2011 11:01:52 -0700
Message-ID: <4E456A8A.3050802@dcrocker.net>
Date: Fri, 12 Aug 2011 11:01:46 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <20110809225415.89118.qmail@joyce.lan> <CAC4RtVBr2D+7UkFMyaL6inwvA0cPOg-Td39xSfLoG5wtVVyGFA@mail.gmail.com> <CAHhFybohD77f5t8cOZk7RcgYsgaW8z919EpRCd2ek9bAsrrXYg@mail.gmail.com> <201108111351.34118.scott@kitterman.com>
In-Reply-To: <201108111351.34118.scott@kitterman.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 12 Aug 2011 11:01:52 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Updating the status of SPF
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Aug 2011 18:01:15 -0000

Scott,

I have some questions about the current draft of the charter.  For the moment, 
I'm merely trying to get a better understanding of what is intended:


>       Determining the trustworthiness of content on the Internet remains a

What is meant by "trustworthiness of content"?

Two examples are that it might mean that it really was created by the purported 
author.  Or it might mean that its contents are "valid" (which might invite some 
discussion about "validity", of course.) There are other possibilities.



> 	(RFC4871).  However, legitimate and illegitimate users alike can

What is an "illegitimate user"?


> 	take advantage of these schemes.  What is also required is a
> 	meaningful assessment of the trustworthiness of the identifier's
> 	owner.  This in turn permits making a meaningful choice about what
> 	to do with the associated content.

Is the work of the group intended to cover "what to do with the associated content"?


> 	The advent of the requirement described above creates a need to have
> 	reputation data providers make available to consumers data about

Does "consumers" mean end-users, operators of receiving services, or some other 
group?

If it means end-users, how are they expected to employ this information within 
the current context of the tools end-users have?


> 	An existing, standardized reputation query mechanism is
> 	Vouch-by-Reference (RFC5518), which provides a simple Boolean
> 	response concerning the acceptability of different types of mail.
> 	Other application spaces -- such as Web interactions -- could
> 	benefit from common reputation query mechanisms, especially those
> 	for which replies need to be more elaborate.

Given the existence of VBR, why is an additional reputation query mechanism 
needed?  What will be different in the the mechanism and why is the difference 
important?

Perhaps the new mechanism will be identical to VBR, but merely will have the 
meaning of the response be more general than just email?


> 	This working group will produce a set of documents defining and
> 	illustrating the requirement and defining mechanisms to satisfy it.
> 	Two mechanisms are proposed:
>
> 	* simple -- a reputation is expressed in a simple manner such as
> 		an integer
>
> 	* extended -- a response can contain more complex information
> 		useful to an assessor

Who is going to use each of these mechanisms and why?  Are they participating in 
the discussions so far?  Have they expressed interest in implementing the output 
of the working group?


>
> 	The mechanisms will be designed to be application-independent, and
> 	portable between reputation providers.

For this topic, what does 'application-independent' mean?

What does portable between providers mean?


> 	The group will also produce specifications for reporting reputation
> 	data from end-points (usually end users, such as someone clicking
> 	a "report spam" button in response to unwanted email, or a
> 	"thumbs-up" button in an online rating system) to reputation
> 	data aggregators for use in computing updated reputations.

Reporting to whom?

What will be the basis for choosing among the different possible and existing 
models for reporting spam?

The language appears to equate reporting by end-users with some other forms of 
reporting.  Is there really a basis for conflating these?


> 	Reputation systems such as Realtime Block Lists (RBLs, RFC5782)
> 	can be problematic when not operated properly.  For example, an
> 	RBL that lists a specific source without justification can do harm

By 'source' I assume the meaning is of an listed problem domain, rather than the 
source of the report that the domain is a problem?


> 	to a legitimate business, provoking damages and possible litigation.
> 	This important topic will need to be discussed in the informational
> 	portions of the work produced here, in terms of advice both to

What is meant by "informational portions of the work"?  What output does that 
refer to?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net