IETF Logo Mail Archive

RE: [ietf-dkim] The problem with sender policy

<Bill.Oxley@cox.com> Tue, 08 August 2006 00:49 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAFmc-0003NX-4C for ietf-dkim-archive@lists.ietf.org; Mon, 07 Aug 2006 20:49:22 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAFma-0007DS-Mr for ietf-dkim-archive@lists.ietf.org; Mon, 07 Aug 2006 20:49:22 -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 k780mFIp013642; Mon, 7 Aug 2006 17:48:16 -0700
Received: from cox.com (post4.cox.com [24.248.72.37]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k780m98S013605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-dkim@mipassoc.org>; Mon, 7 Aug 2006 17:48:10 -0700
Received: from ([192.168.72.254]) by post4.cox.com with ESMTP id KP-VXH63.206811913; Mon, 07 Aug 2006 20:47:39 -0400
Received: from CATL0MS20.CORP.COX.COM ([10.62.210.20]) by catl0ms22.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.2668); Mon, 7 Aug 2006 20:47:39 -0400
Received: from CATL0MS02.corp.cox.com ([10.62.210.88]) by CATL0MS20.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 20:47:39 -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] The problem with sender policy
Date: Mon, 07 Aug 2006 20:47:38 -0400
Message-ID: <BB621D48443A854A89D86528F915864C0215F78D@CATL0MS02.corp.cox.com>
In-Reply-To: <20060807233656.GE7863@localhost.localdomain>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-dkim] The problem with sender policy
Thread-Index: Aca6g4RG/o7Itxv9QYanVwHodm5b4wAAHu3w
From: Bill.Oxley@cox.com
To: jmacdonald@e-dialog.com, johnl@iecc.com
X-OriginalArrivalTime: 08 Aug 2006 00:47:39.0418 (UTC) FILETIME=[3FB90FA0:01C6BA84]
X-Songbird: Clean, Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sb7.songbird.com id k780m98S013605
Cc: 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.2 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

Once that is done, something that allows a Sender and Receiver to
establish a relationship and trust with each other can be built. The
system I'm thinking about allows a Sender to express the desire for a
relationship and only when the Receiver _wants_ this relationship does
the trust mechanism come into play.

We already have that, CORBA, EDS, FTAM, MQ Series, no need to reinvent
the wheel. I have done FTAM over port 25 to get around firewall
issues,,,,
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 Jeff Macdonald
Sent: Monday, August 07, 2006 8:37 PM
To: John L
Cc: DKIM List
Subject: Re: [ietf-dkim] The problem with sender policy

On Sat, Aug 05, 2006 at 08:56:37PM -0400, John L wrote:

> senders are not the right people to judge their own importance.

So, I've been thinking pretty much the same thing after seeing all the
recent threads going on. I'm going to go out on a limb and say that
DKIM and related tech are the wrong approach.

There is an interesting quote from J.P. Rangaswami in the Sept. issue
of Linux Journal (pg 44):

"If you go to many Eastern countries, _identity_ is not about who I am,
because the I is very unusual. Identity is about _what I belong to_.
Identity is a statement of the community that I belong to. Identity is
a statementof things that I will associate with me, that empower me as
a result of belonging to something..."

There are many discussions about 'which Identity' to use in 'Sender
Authentication' schemes. I think it is time to create a new Identity
simply because it seems all the current identities have their own
flaws.

Once that is done, something that allows a Sender and Receiver to
establish a relationship and trust with each other can be built. The
system I'm thinking about allows a Sender to express the desire for a
relationship and only when the Receiver _wants_ this relationship does
the trust mechanism come into play.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | jmacdonald@e-dialog.com
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

_______________________________________________
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

v2.23.0 | Report a Bug | By Email