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

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

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94Jn-0002nI-F5 for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 14:22:43 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G94Jm-0001Bd-2s for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 14:22:43 -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 k74ILwOI030416; Fri, 4 Aug 2006 11:21:58 -0700
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k74ILndm030399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Fri, 4 Aug 2006 11:21:49 -0700
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k74ILIAR025970 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Aug 2006 11:21:18 -0700
In-Reply-To: <20060804140232.H49810@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> <44D36B4A.2050903@mtcc.com> <20060804114527.Y27352@simone.iecc.com> <44D37376.4020408@mtcc.com> <20060804132203.Y49810@simone.iecc.com> <EAF17954-74A3-4374-A059-B31A1414B350@mail-abuse.org> <20060804140232.H49810@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: <114EFFAD-100B-483B-B865-FD96CE2F1021@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 11:21:17 -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: 52e1467c2184c31006318542db5614d5

On Aug 4, 2006, at 11:03 AM, John L wrote:

>> "SIGN ALL MAIL" and "DO NOT USE ANY SERVICES KNOWN TO DAMAGE THEIR  
>> SIGNATURES"
>>
>> Cisco may wish to only state:
>>
>> "SIGN ALL MAIL"
>>
>> The important difference is whether the assertion is _expected_ to  
>> cover all possible sources carrying their messages.
>
> The more important difference is that recipients can do something  
> based on the first statement but not on the second.

Imagine that policy takes the form of a list that can either be  
declared as partial or complete.  In the case of a partial list,  
although that information will not aid the blocking of messages  
outright, it can still serve to clarify genuine relationships between  
the From email-address domain and the signing domain when they  
differ.  A partial list indicates that recipients should consider the  
reputation of the signing domain instead of blocking messages when  
this relationship is not established.  On the other hand, a complete  
list indicates that recipients need not consider the reputation of  
the signing domain and can blocking messages when the relationship is  
not established.  Although a complete list offers greater utility,  
for general use a complete list is not very practical assertion for  
most domains.

-Doug


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