Re: [ietf-dkim] SSP requirements

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 08 August 2006 15:25 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATS3-0000Dn-64 for ietf-dkim-archive@lists.ietf.org; Tue, 08 Aug 2006 11:25:03 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GATS1-00080s-Ot for ietf-dkim-archive@lists.ietf.org; Tue, 08 Aug 2006 11:25:03 -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 k78FO0PE023355; Tue, 8 Aug 2006 08:24:01 -0700
Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k78FNqiv023332 for <ietf-dkim@mipassoc.org>; Tue, 8 Aug 2006 08:23:53 -0700
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id DB4096807E; Tue, 8 Aug 2006 16:23:27 +0100 (IST)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A01151D8050; Tue, 08 Aug 2006 16:23:27 +0100
Received: from [127.0.0.1] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id D57FE6807E; Tue, 8 Aug 2006 16:23:27 +0100 (IST)
Message-ID: <44D8AC90.705@cs.tcd.ie>
Date: Tue, 08 Aug 2006 16:24:00 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [ietf-dkim] SSP requirements
References: <20060805163953.Q47527@simone.iecc.com> <015701c6b8e3$9f7d8c10$0201a8c0@hdev1> <20060806013001.80095.qmail@snake.corp.yahoo.com> <093601c6bac8$74ba9bd0$0201a8c0@hdev1> <1155050266.21912.77.camel@bash.adsl-64-142-13-68>
In-Reply-To: <1155050266.21912.77.camel@bash.adsl-64-142-13-68>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A11151D8050
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1280)
X-Songbird: Clean, Clean
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.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

Yet another post that seems (hard to tell) to contain no
new technical points that may help us in working on SSP.

Please desist,
Stephen.

Douglas Otis wrote:
> On Tue, 2006-08-08 at 04:55 -0400, Hector Santos wrote:
>> ----- Original Message -----
>> From: "Mark Delany" <MarkD+dkim@yahoo-inc.com>
>> To: <ietf-dkim@mipassoc.org>
>>
>>> I will say that that I think that John's DAC venture is exactly what
>>> we had hoped would be an outcome of this process. May there be many
>>> more DAC competitors emerging as DKIM is deployed.
>> Mark,
>>
>> But will there be a standard?   Market segment XYZ uses this? Market segment
>> ABC uses that?
>>
>> Will DKIM-BASE become a "Batteries Required" protocol?
> 
> Bad actors are able to sign with DKIM and establish any favorable
> policy.  Good actors may be less inclined to assert the same policy when
> it might cause a percentage of their email to be rejected or discarded.
> Bad actors already expect many of their messages to be rejected, and
> don't care what happens when common services are used.  A bad actor
> might try spoofing as a common service, but likely with less success. 
> 
> An alignment with the From, signing domain, and a policy record will not
> curtail spoofed return paths without also causing the loss of valid
> emails from good actors.  A DKIM client policy may help, but not the
> DKIM From policy.  Even here, there can be no absolute policy asserted
> without causing loss of email for a typical good actor.  Don't expect
> the bad actor to care.
> 
> Devising a set of obstacles through which email is to navigate will not
> eliminate a need to track source histories.  Only this history curtails
> email from bad actors.  When doing so, this history must track an
> unlimited number of domain names.  White-listing may bypass some
> messages from the tracking process, however a growing percentage will be
> from a highly diverse array of domain names.
> 
> Either the goal is to accept email from just the mega-domains (which
> will continue to have their abuse issues), or something is planned that
> is not apparent. The obstacle course favors the bad over the good actor.
> So don't throw out your batteries, they are still needed to retain your
> history information.
> 
> -Doug 
> 
> 
> 
> 
> _______________________________________________
> 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