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

Douglas Otis <dotis@mail-abuse.org> Fri, 04 August 2006 16:27 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92Vy-0006lR-1O for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 12:27:10 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92Vw-00026Z-K0 for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 12:27:10 -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 k74GQ35i012656; Fri, 4 Aug 2006 09:26:04 -0700
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k74GPlYs012594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Fri, 4 Aug 2006 09:25:47 -0700
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k74GPEiq021157 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Aug 2006 09:25:15 -0700
In-Reply-To: <20060804112731.I21459@simone.iecc.com>
References: <20060802002353.U59653@simone.iecc.com> <44D0E259.7040400@mtcc.com> <20060802165510.X1168@simone.iecc.com> <44D160BD.7080209@mtcc.com> <20060802223619.E86316@simone.iecc.com> <44D24A20.6050109@mtcc.com> <20060803153457.X33570@simone.iecc.com> <44D36203.2060803@mtcc.com> <20060804112731.I21459@simone.iecc.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <85CAD618-C383-4869-9F2A-468EFF3EFB77@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
Date: Fri, 04 Aug 2006 09:25:13 -0700
To: John L <johnl@iecc.com>
X-Mailer: Apple Mail (2.752.2)
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
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: 082a9cbf4d599f360ac7f815372a6a15

On Aug 4, 2006, at 8:34 AM, John L wrote:

>> Part of the problem here is the past record of SPF with over- 
>> zealous 550 if there's any hint of bogosity. We, for example,  
>> would be forced to take down a "we sign everything" policy if that  
>> were to happen with DKIM -- even though we'll be signing  
>> everything pretty soon. If there were a qualifier in the "I sign  
>> everything policy" that specifically implies that sending a 550  
>> based on a missing DKIM signature alone is extremely bone-headed"  
>> then maybe we can both.
>
> I don't see the point.  That last suggestion is, to the recipient,  
> the equivalent of a useless "I sign some mail" since you're telling  
> the recipient it's OK to accept some amount of both signed and  
> unsigned mail.

John,

In your zeal for simplicity, you appear to be missing valid uses for  
a policy statement.  Mike correctly indicates a potential problem.

Think of the signing domain as representing a newspaper.  When the  
editor of this newspaper allows reporters to be liars, there would be  
primarily less trust in the newspaper.  The first party, from a trust  
aspect, is the newspaper's editor.  By the same token, it should not  
be a requirement that all reporters share the same last name as that  
of the editor.  Reporters should be allowed an easy means to appear  
in other newspapers.  To facilitate this, reporters should be  
provided a means to indicate what newspapers carry their stories.  A  
reporter may need to indicate that they freelance where other  
newspapers not listed may also carry their stories.

When a reader wonders whether the story they are reading in some  
unknown newspaper is really by the reporter they believe it to be,  
the reader could check the list of newspapers published by the  
reporter.  There can be three outcomes:

  1 - If the newspaper is on this list, then the reader has greater
      confidence in who wrote the story.

  2 - If the newspaper is not on this list, and the list is marked
      as being a complete, then the reader would know that the
      story is not likely by this reporter.

  3 - If the newspaper is not on this list, and the list is marked
      as not being complete, then the reader would then need to
      investigate the reputation of the newspaper's editor.

There is value having a list marked incomplete.  Perhaps a small  
population of readers will find the reporter's story in an unlisted  
newspaper.  In these case, the reporter would rather have the  
reputation of the newspaper's editor checked.  Without being able to  
mark the list incomplete, a report may find their story dismissed.   
This can be especially damaging when the reporter does a fair amount  
of freelancing.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html