Re: [ietf-dkim] A more fundamental SSP axiom
wayne <wayne@schlitt.net> Wed, 02 August 2006 13:30 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8GnX-0001bM-GU for ietf-dkim-archive@lists.ietf.org; Wed, 02 Aug 2006 09:30:07 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8GnV-0006Au-3Z for ietf-dkim-archive@lists.ietf.org; Wed, 02 Aug 2006 09:30:07 -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 k72DTTnt029523; Wed, 2 Aug 2006 06:29:30 -0700
Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k72DT4s9029455 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Wed, 2 Aug 2006 06:29:10 -0700
Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1G8Glp-0004dk-Ft for ietf-dkim@mipassoc.org; Wed, 02 Aug 2006 08:28:38 -0500
From: wayne <wayne@schlitt.net>
To: IETF DKIM WG <ietf-dkim@mipassoc.org>
References: <20060802002353.U59653@simone.iecc.com> <44D03872.5090601@dcrocker.net>
Mail-Copies-To: nobody
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 02 Aug 2006 08:28:20 -0500
In-Reply-To: <44D03872.5090601@dcrocker.net> (Dave Crocker's message of "Tue, 01 Aug 2006 22:30:26 -0700")
Message-ID: <x4psfj2rnv.fsf@footbone.schlitt.net>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux)
MIME-Version: 1.0
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Rcpt-To: ietf-dkim@mipassoc.org
X-SA-Exim-Mail-From: wayne@schlitt.net
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net
X-Spam-Level:
X-Spam-Status: No, score=-6.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=unavailable version=3.0.4
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on backbone.schlitt.net)
X-Songbird: Clean, Clean
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: IETF DKIM WG <ietf-dkim@mipassoc.org>
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
In <44D03872.5090601@dcrocker.net> Dave Crocker <dhc@dcrocker.net> writes: > John L wrote: >> SSP exists so that receivers can make better decisions about >> handling their incoming mail. >> Corollary: >> Information not useful to receivers doesn't belong in SSP. I agree, but it is also important to remember that anything that has no value to the sender will likely not be put into the SSP either. > For this initial round of SSP, the wording of the Corollary probably needs to be: > > Information that is not widely viewed by receivers as essential doesn't > belong in SSP. I think this is very short sighted. It is rare that a protocol gets more than one or two revisions. I don't think it is certain that DKIM will actually even surpasses DK usage and receives wide adoption, but I think it is very unlikely that we will get a chance to update DKIM and have that update receive wide adoption. There certainly should be a cost/benefit analysis done. If a feature is costly to add and has little obvious benefit to both senders and receivers, then, yeah, drop it. However, if a feature is cheap or trivial to add, then just because there aren't people willing to use it *immediately* is no reason to rule it out. And, yes, the overall complexity of the SSP system needs to be added into the cost, I'm not saying that all features that, in isolation, are "cheap" should be added, just that we shouldn't design SSP for only today and not for 5-10 years down the road. -wayne _______________________________________________ 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