RE: [ietf-dkim] SSP requirements

<Bill.Oxley@cox.com> Sat, 05 August 2006 04:11 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9DVI-0001aS-Ps for ietf-dkim-archive@lists.ietf.org; Sat, 05 Aug 2006 00:11:12 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9DVH-0006C4-Cl for ietf-dkim-archive@lists.ietf.org; Sat, 05 Aug 2006 00:11:12 -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 k754AE9g006088; Fri, 4 Aug 2006 21:10:15 -0700
Received: from cox.com (post2.cox.com [24.248.74.37]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k754A9eF006060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-dkim@mipassoc.org>; Fri, 4 Aug 2006 21:10:10 -0700
Received: from ([192.168.74.254]) by post2.cox.com with ESMTP id KP-VXB82.214670702; Sat, 05 Aug 2006 00:09:24 -0400
Received: from CATL0MS21.CORP.COX.COM ([10.64.210.21]) by catl0ms23.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.2668); Sat, 5 Aug 2006 00:09:24 -0400
Received: from CATL0MS02.corp.cox.com ([10.62.210.88]) by CATL0MS21.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Aug 2006 00:09:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [ietf-dkim] SSP requirements
Date: Sat, 05 Aug 2006 00:09:23 -0400
Message-ID: <BB621D48443A854A89D86528F915864C0215F772@CATL0MS02.corp.cox.com>
In-Reply-To: <20060805034058.861.qmail@simone.iecc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-dkim] SSP requirements
Thread-Index: Aca4QnOpN1w03A//SX2KIUIeTC8w/AAAb6OQ
From: Bill.Oxley@cox.com
To: johnl@iecc.com, ietf-dkim@mipassoc.org
X-OriginalArrivalTime: 05 Aug 2006 04:09:24.0054 (UTC) FILETIME=[EF68AF60:01C6B844]
X-Songbird: Clean, Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sb7.songbird.com id k754A9eF006060
Cc:
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: 4b800b1eab964a31702fa68f1ff0e955

How does the post office do it? It receives mail from other countries
and determines what kind of stamps official franking etc to either
deliver or return to sender unopened. Part of that is a balance of
payment schedule but I imagine it is a mutual bi-lateral agreement that
determines this. A ruthless prosecution of people who purport to send
legitimately franked mail is also part of the solution.

DKIM is an electronic stamp, SSP (to me) appears to be the franking
system.
A bi-lateral agreement that implementers can agree that if the stamps
and the franks are okay, mail will be deemed semi acceptable except for
checking for criminal (spammish) activities.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
bill.oxley@cox.com 


-----Original Message-----
From: ietf-dkim-bounces@mipassoc.org
[mailto:ietf-dkim-bounces@mipassoc.org] On Behalf Of John Levine
Sent: Friday, August 04, 2006 11:41 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] SSP requirements

>I can't gather requirements if I can't make any sense of what you're
saying.

That's a reasonable concern.

The fog around SSP is so opaque that I'm really wondering if it
wouldn't make more sense to punt and wait for people to do enough
experiments to understand what turns out to be useful.

The first open question is when a receipient would check a sender's
SSP.  It seems pretty clear that if a message is self-signed, there's
no need to check, and if it's completely unsigned you do want to
check.  But what if it's signed by a third party you trust?  (That's
the mailing list scenario.)  If a message is signed both by you and by
someone else I see no reason to treat that as anything other than a
self-signed message, but some people disagree for reasons that remain
unclear.

Assuming we can work that out, I hear reasonable unanimity on "I
send no mail", that is, if you get an unsigned message purporting
to be from me, it's a fake so throw it away.

I hear considerably less consensus on "I do send mail but throw it
away if it's not signed."  There's some sentiment for "if foo signs
it, then it's OK" although then we get into arguments about delegating
signing keys and the like.  I hear no consensus at all about anything
else.  There are lots of other true things one could say about one's
outgoing mail, but surprisingly little that's useful to recipients.

A spec with 1 2/3 bits of data doesn't impress me as worth writing.

R's,
John

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

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