Re: [ietf-dkim] A more fundamental SSP axiom

Dave Crocker <dhc@dcrocker.net> Thu, 03 August 2006 03:04 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8TVY-0000p3-3h for ietf-dkim-archive@lists.ietf.org; Wed, 02 Aug 2006 23:04:24 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8TVW-0000TF-Nv for ietf-dkim-archive@lists.ietf.org; Wed, 02 Aug 2006 23:04:24 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7333dAx025410; Wed, 2 Aug 2006 20:03:39 -0700
Received: from [192.168.0.3] (adsl-68-122-118-34.dsl.pltn13.pacbell.net [68.122.118.34]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7333R52025384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 20:03:27 -0700
Message-ID: <44D1675E.6020405@dcrocker.net>
Date: Wed, 02 Aug 2006 20:02:54 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: John L <johnl@iecc.com>
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
References: <20060802002353.U59653@simone.iecc.com> <44D0E259.7040400@mtcc.com> <20060802165510.X1168@simone.iecc.com> <44D160BD.7080209@mtcc.com> <20060802223619.E86316@simone.iecc.com>
In-Reply-To: <20060802223619.E86316@simone.iecc.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Songbird: Clean, Clean
Cc: DKIM List <ietf-dkim@mipassoc.org>
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1


John L wrote:
> The third is "<foo> signs all my mail", if it turns out that there
> actually exist foo's that reliable enough to delegate's one's signing,
> and that it's easier to do that than to sign in the MUA or to provide
> signing keys so that foo can put on the sender's signature.

Outsourcing for mail sending is already common, so it seems likely that
delegating signing would be, too.

But my question is why it is better to have a "delegation of my domain" scheme
rather than simply having the outsourced sending do its own signature and then
use its domain name for evaluating its own reputation.  If it is a Good Actor,
then it shouldn't need to rely on the domain name of the content author.  If it
is a Bad Actor, then relying on the domain name of the content author would
merely wind up hurting the content author.


> So my suggestion would be to use a format similar to the one we use for
> the signatures, put the first two items in the spec, and use a syntax
> that permits people to experiment with new items and propose the useful
> ones for later standardization.

Something this minimalist does indeed seem like the best approach:  1)
standardize a publication mechanism for an extensible list of practices; and 2)
include a tiny number of extremely interesting practices to publish, to seed the
effort.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html