Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02

wayne <wayne@schlitt.net> Fri, 26 August 2005 19:33 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jwl-00025l-Lr; Fri, 26 Aug 2005 15:33:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jwj-00025a-9v for ietf@megatron.ietf.org; Fri, 26 Aug 2005 15:33:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10050 for <ietf@ietf.org>; Fri, 26 Aug 2005 15:32:59 -0400 (EDT)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8jxU-0001YY-TJ for ietf@ietf.org; Fri, 26 Aug 2005 15:33:50 -0400
Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8jv4-0002L5-BK for ietf@ietf.org; Fri, 26 Aug 2005 21:31:18 +0200
Received: from footbone.schlitt.net ([67.52.51.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Fri, 26 Aug 2005 21:31:18 +0200
Received: from wayne by footbone.schlitt.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Fri, 26 Aug 2005 21:31:18 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: wayne <wayne@schlitt.net>
Date: Fri, 26 Aug 2005 14:24:46 -0500
Lines: 29
Message-ID: <x4k6i8mrgh.fsf@footbone.schlitt.net>
References: <198A730C2044DE4A96749D13E167AD375A2ABD@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.schlitt.net
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux)
Cancel-Lock: sha1:HFwoWhXG75MgMg3n5rDDxM/OAUA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com
Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In <198A730C2044DE4A96749D13E167AD375A2ABD@MOU1WNEXMB04.vcorp.ad.vrsn.com> "Hallam-Baker, Phillip" <pbaker@verisign.com> writes:

>> > All SPF does is provide a mechanism whereby sending parties can 
>> > describe their outgoing edge mail servers. The recipient has the 
>> > absolute right to interpret that data in any way they see 
>> fit. That is 
>> > the entire point of a spam filtering scheme.
>> 
>> You have long advocated this position, but unfortunately the 
>> definition of "outgoing edge mail servers" is not a nice, 
>> clean, crisp concept.  It sounds good, but unfortunately, it 
>> doesn't work.
>
> OK, "All SPF does is ATTEMPT TO provide a mechanism whereby "
>
> Happy now?

Sorry, but no..

> At some point there is a boundary between infrastructure the sender has
> control of and where he does not. That boundary is very clearly defined
> in my universe but even if it was ambiguous it would still exist.

The problem is that for different identities, this "boundary" is
different.  In particular, the boundaries between the SPF identities
(2821.MAILFROM and 2821.HELO) are different than SenderID (PRA).


-wayne


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf