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

Michael Thomas <mike@mtcc.com> Fri, 04 August 2006 21:41 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97QW-0002FK-G2 for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 17:41:52 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G97Nh-00023A-ID for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 17:38:58 -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 k74Lab3a024597; Fri, 4 Aug 2006 14:36:37 -0700
Received: from fasolt.mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k74LaUkv024575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-dkim@mipassoc.org>; Fri, 4 Aug 2006 14:36:31 -0700
DKIM-Signature: v=0.4; a=rsa-sha256; q=dns/txt; l=3033; t=1154727365; x=11 55591365; c=relaxed/simple; s=dicks.drop.kirkwood; h=Content-Type:From:Subj ect:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z= From:=20Michael=20Thomas=20<mike@mtcc.com>|Subject:=20Re=3A=20[ietf-dkim]=2 0A=20more=20fundamental=20SSP=20axiom|Sender:=20|To:=20IETF=20DKIM=20WG=20< ietf-dkim@mipassoc.org>|Cc:=20|Content-Transfer-Encoding:=207bit|MIME-Versi on:=201.0|Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20format= 3Dflowe d; bh=BssKmsrQL9vbqEwZLn09Udz6Klf4jOVgTeoO91N7V2o=; b=DXakWMg95NlqJ/068nED93ExSlsYz3QFD2B+RwTCqrN60NkHcPcjWB7ZsdLVjSw+Jkjfe81u uoWSs5+EwAsa1v7t1x6RCMjqZMv28082p+Zs45EoqkHtnM7Oes9uccxN;
DKIM-Signature: a=rsa-sha1; q=dns; l=3033; t=1154727365; x=1155591365; c=r elaxed/simple; s=dicks.drop.kirkwood; h=Content-Type:From:Subject:Content-T ransfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:Michael= 20Thomas=20<mike@mtcc.com>|Subject:Re=3A=20[ietf-dkim]=20A=20more=20fundame ntal=20SSP=20axiom|Sender:|To:IETF=20DKIM=20WG=20<ietf-dkim@mipassoc.org>|C c:|Content-Transfer-Encoding:7bit|MIME-Version:1.0|Content-Type:text/plain= 3B=20charset=3DISO-8859-1=3B=20format=3Dflowe d; X=v=3Dcisco.com=3B=20h=3DTHgzsy76Cqx29/einu/PnNiEwmM=3D; b=UbumOATg9LOHnuqYL2I8GL/ohLZiFZzagZ76Q36LFP3KV9955o9QjdBnvf/L/IglCMitHiyD vyn5ZXbp98b7m8fbt6YU26ezS9o49JLFCoTl9nwcpuapT7sza8mFNKUH;
Received: from [192.168.0.102] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by fasolt.mtcc.com (8.13.6/8.13.1) with ESMTP id k74La3pU006576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Fri, 4 Aug 2006 14:36:05 -0700
Message-ID: <44D3BDBD.1060807@mtcc.com>
Date: Fri, 04 Aug 2006 14:35:57 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF DKIM WG <ietf-dkim@mipassoc.org>
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> <44D24A20.6050109@mtcc.com> <20060803153457.X33570@simone.iecc.com> <44D36203.2060803@mtcc.com> <x4ejvw1asy.fsf@footbone.schlitt.net>
In-Reply-To: <x4ejvw1asy.fsf@footbone.schlitt.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Authentication-Results: fasolt.mtcc.com; header.From=mike@mtcc.com; dkim=pass ( sig from mtcc.com/dicks.drop.kirkwood verified; ); header.From=mike@mtcc.com; dkim=pass ( sig from mtcc.com/dicks.drop.kirkwood verified; );
X-XIPE-SCORES: dispose=pass; ACD=1.00; CLAM=0.00; COMPLY=0.00; URL=0.00; SA=0.00; HONEY=0.00;
X-Songbird: Clean, Clean
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.2 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976

wayne wrote:

>In <44D36203.2060803@mtcc.com> Michael Thomas <mike@mtcc.com> writes:
>
>  
>
>>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.
>>    
>>
>
>Based on the past record with SPF, is the any reason to believe that,
>people won't treat "I sign some email" as the same as "I sign all
>email" and reject email that does not have a valid first party
>signature?  There are certainly lots of people who treat publishing
>SPF records that end in NEUTRAL more harshly than not publishing SPF
>records at all and this has caused at least one major ISP to remove
>their SPF records.
>
>(Yes, this is assuming DKIM reaches the same level of deployment that
>SPF had back in early 2003.  There isn't much danger right now.)
>
>
>  
>
>>      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.
>>    
>>
>
>This is somewhat along the lines of SPF's SOFTFAIL.  You will find
>some people who reject based solely on seeing a SOFTFAIL and you will
>find others claiming that SOFTFAIL is functionally equivalent to
>NEUTRAL.
>
>
>  
>
>>The current SSP has o=! t=y which could in a tortured way be
>>construed to have that semantic: "I sign everything, but hey I'm
>>testing so take it for what it's worth". If we have something more
>>formalized, them maybe we can accommodate these two pretty different
>>scenarios.
>>    
>>
>
>Expect people to ignore the t=y flag also.
>
>
>Really, anyone who thinks that signing email with DKIM (or DK or IIM)
>will not directly cause some of your valid, non-spam, email to be
>rejected is fooling themselves.  Receivers are free to do whatever
>they want with their servers, including extremely bone-head things.
>
>
>Personally, I think there is some value in distinguishing between "I
>sign everything and never send to mailing lists and other know
>mungers", "I sign everything, but also send to known mungers", and "I
>know I don't sign everything".
>
>  
>
Absolutely -- there are all kinds of stupid thing that receivers do and we
can't do anything about them other than try to educate them that that is
wrong. If we just come up with a policy which is "I sign everything" with
no nuance of the kind of people who can and might make that statement,
we're probably worse off than we are now because senders and receivers
will not agree on what it means. Even if we end up _not_ having a way
to publish non-transactional-goes-through-mungers mailers, we can be
guaranteed that there will be lots of confusion by people who really do
sign everything and set that policy only to be punished -- erratically --
by receivers.

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