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

<Bill.Oxley@cox.com> Wed, 02 August 2006 18:57 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LuE-0004zT-R3 for ietf-dkim-archive@lists.ietf.org; Wed, 02 Aug 2006 14:57:22 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8LuD-0005go-ES for ietf-dkim-archive@lists.ietf.org; Wed, 02 Aug 2006 14:57: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 k72Iu1eX020162; Wed, 2 Aug 2006 11:56:01 -0700
Received: from cox.com (post6.cox.com [24.248.74.39]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k72Itl5o020105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-dkim@mipassoc.org>; Wed, 2 Aug 2006 11:55:48 -0700
Received: from ([192.168.74.254]) by post6.cox.com with ESMTP id KP-VXK84.145472718; Wed, 02 Aug 2006 14:55:07 -0400
Received: from CATL0MS20.CORP.COX.COM ([10.62.210.20]) by catl0ms22.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.2668); Wed, 2 Aug 2006 14:55:07 -0400
Received: from CATL0MS02.corp.cox.com ([10.62.210.88]) by CATL0MS20.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 14:55:07 -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] A more fundamental SSP axiom
Date: Wed, 02 Aug 2006 14:55:07 -0400
Message-ID: <BB621D48443A854A89D86528F915864C0215F760@CATL0MS02.corp.cox.com>
In-Reply-To: <44D0F1A4.6080103@dcrocker.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-dkim] A more fundamental SSP axiom
Thread-Index: Aca2ZGxj2QfkNXn+TyqcdJWSSdsW3wAAHCPQ
From: Bill.Oxley@cox.com
To: dcrocker@bbiw.net, arvel.hathcock@altn.com
X-OriginalArrivalTime: 02 Aug 2006 18:55:07.0387 (UTC) FILETIME=[2C1084B0:01C6B665]
X-Songbird: Clean, Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sb7.songbird.com id k72Itl5o020105
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: 41c17b4b16d1eedaa8395c26e9a251c4

Dave,
As a receiver I would like to know who sent the message, who signed the
message and any further information that might allow me to assign a spam
score accurately for further edge processing.
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 Dave Crocker
Sent: Wednesday, August 02, 2006 2:41 PM
To: arvel.hathcock@altn.com
Cc: 'ietf-dkim@mipassoc.org'
Subject: Re: [ietf-dkim] A more fundamental SSP axiom



Arvel Hathcock wrote:
>>  SSP exists so that receivers can make better decisions about
>>  handling their incoming mail.
> 
> There is a lot of truth in that statement.  I would say it like this
though:  SSP exists so that senders can provide input in the hopes that
receivers will make "better" decisions about handling their incoming
mail.


Arvel,

Your statement is, of course, entirely correct.  The problem is that it
probably
does not help the working group effort as much as a phrasing that
focuses on the
Receiver-side.  The reason is that a focus on the receiver will help us
focus on
adoption and use.

As soon as we have a basis for believing that Receive side folk with
actually
USE information provided by senders, then the senders are much more
likely to
provide it.  After all, providing it improves deliverability.

If we only focus on sender-side desires, then we will specify a jillion
clever
mechanisms that will not get used, rather than the few that will.

d/


-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
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