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
- Re: [ietf-dkim] A more fundamental SSP axiom Paul Hoffman
- [ietf-dkim] A more fundamental SSP axiom John L
- Re: [ietf-dkim] A more fundamental SSP axiom Dave Crocker
- Re: [ietf-dkim] A more fundamental SSP axiom wayne
- Re: [ietf-dkim] A more fundamental SSP axiom Scott Kitterman
- Re: [ietf-dkim] A more fundamental SSP axiom Dave Crocker
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- RE: [ietf-dkim] A more fundamental SSP axiom Arvel Hathcock
- Re: [ietf-dkim] A more fundamental SSP axiom Dave Crocker
- RE: [ietf-dkim] A more fundamental SSP axiom Bill.Oxley
- Re: [ietf-dkim] A more fundamental SSP axiom Dave Crocker
- RE: [ietf-dkim] A more fundamental SSP axiom Arvel Hathcock
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- RE: [ietf-dkim] A more fundamental SSP axiom Arvel Hathcock
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom Arvel Hathcock
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- RE: [ietf-dkim] A more fundamental SSP axiom Paul Hoffman
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- RE: [ietf-dkim] A more fundamental SSP axiom Bill.Oxley
- Re: [ietf-dkim] A more fundamental SSP axiom Dave Crocker
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Stephen Farrell
- Re: [ietf-dkim] A more fundamental SSP axiom Dave Crocker
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Steve Atkins
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Steve Atkins
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- Re: [ietf-dkim] A more fundamental SSP axiom John Levine
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- [ietf-dkim] SSP thought experiment John L
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] SSP thought experiment Douglas Otis
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- RE: [ietf-dkim] SSP thought experiment Bill.Oxley
- RE: [ietf-dkim] SSP thought experiment John L
- RE: [ietf-dkim] A more fundamental SSP axiom Hallam-Baker, Phillip
- RE: [ietf-dkim] A more fundamental SSP axiom John L
- RE: [ietf-dkim] A more fundamental SSP axiom Hallam-Baker, Phillip
- Re: [ietf-dkim] A more fundamental SSP axiom Dave Crocker
- Re: [ietf-dkim] A more fundamental SSP axiom Dave Crocker
- Re: [ietf-dkim] A more fundamental SSP axiom wayne
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- Re: [ietf-dkim] A more fundamental SSP axiom william(at)elan.net
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- RE: [ietf-dkim] A more fundamental SSP axiom Bill.Oxley
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom John L
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Dave Crocker
- Re: [ietf-dkim] A more fundamental SSP axiom Mark Delany
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- RE: [ietf-dkim] A more fundamental SSP axiom Arvel Hathcock
- RE: [ietf-dkim] A more fundamental SSP axiom Arvel Hathcock
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom william(at)elan.net
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- Re: [ietf-dkim] A more fundamental SSP axiom Mark Delany
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Damon
- RE: [ietf-dkim] A more fundamental SSP axiom Bill.Oxley
- Re: [ietf-dkim] A more fundamental SSP axiom Mark Delany
- Re: [ietf-dkim] A more fundamental SSP axiom Michael Thomas
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom John Levine
- RE: [ietf-dkim] SSP requirements Bill.Oxley
- [ietf-dkim] punting into near-term standardization Dave Crocker
- Re: [ietf-dkim] A more fundamental SSP axiom Mark Delany
- RE: [ietf-dkim] A more fundamental SSP axiom Bill.Oxley
- Re: [ietf-dkim] SSP requirements Mark Delany
- RE: [ietf-dkim] SSP requirements John L
- RE: [ietf-dkim] SSP requirements Bill.Oxley
- Re: [ietf-dkim] SSP requirements John Levine
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- Re: [ietf-dkim] punting into near-term standardiz… Arvel Hathcock
- Re: [ietf-dkim] A more fundamental SSP axiom Hector Santos
- Re: [ietf-dkim] SSP requirements Michael Thomas
- Re: [ietf-dkim] SSP requirements Hector Santos
- Re: [ietf-dkim] SSP requirements John L
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- Re: [ietf-dkim] A more fundamental SSP axiom Douglas Otis
- Re: [ietf-dkim] SSP requirements Hector Santos
- Re: [ietf-dkim] SSP requirements Douglas Otis
- Re: [ietf-dkim] SSP requirements william(at)elan.net
- Re: [ietf-dkim] SSP requirements Michael Thomas
- [ietf-dkim] The problem with sender policy John L
- [ietf-dkim] DKIM Client Policy Requirement Douglas Otis
- RE: [ietf-dkim] The problem with sender policy Bill.Oxley
- RE: [ietf-dkim] The problem with sender policy John L
- Re: [ietf-dkim] SSP requirements Mark Delany
- RE: [ietf-dkim] The problem with sender policy william(at)elan.net
- Re: [ietf-dkim] SSP requirements Douglas Otis
- Re: [ietf-dkim] SSP requirements Hector Santos
- Re: [ietf-dkim] SSP requirements Dave Crocker
- Re: [ietf-dkim] punting into near-term standardiz… Hector Santos
- Re: [ietf-dkim] punting into near-term standardiz… Douglas Otis
- Re: [ietf-dkim] SSP requirements Stephen Farrell
- Re: [ietf-dkim] SSP requirements Stephen Farrell
- Re: [ietf-dkim] SSP requirements Hector Santos
- Re: [ietf-dkim] SSP requirements Hector Santos
- Re: [ietf-dkim] A more fundamental SSP axiom Scott Kitterman
- Re: [ietf-dkim] The problem with sender policy Arvel Hathcock
- Re: [ietf-dkim] SSP requirements Damon
- Re: [ietf-dkim] The problem with sender policy Damon
- Re: [ietf-dkim] SSP requirements Damon
- Re: [ietf-dkim] SSP requirements Damon
- Re: [ietf-dkim] SSP requirements Hector Santos
- Re: [ietf-dkim] The problem with sender policy Jeff Macdonald
- RE: [ietf-dkim] The problem with sender policy Bill.Oxley
- Re: [ietf-dkim] The problem with sender policy Dave Crocker
- Re: [ietf-dkim] The problem with sender policy Jeff Macdonald
- Re: [ietf-dkim] SSP requirements Douglas Otis
- Re: [ietf-dkim] SSP requirements Stephen Farrell
- Re: [ietf-dkim] A more fundamental SSP axiom Graham Murray