RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02

"Hallam-Baker, Phillip" <pbaker@verisign.com> Fri, 26 August 2005 19:44 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k7U-0006kY-1F; Fri, 26 Aug 2005 15:44:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k7S-0006kT-Bn for ietf@megatron.ietf.org; Fri, 26 Aug 2005 15:44:06 -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 PAA10833 for <ietf@ietf.org>; Fri, 26 Aug 2005 15:44:04 -0400 (EDT)
Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8k8E-0001xt-1y for ietf@ietf.org; Fri, 26 Aug 2005 15:44:55 -0400
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.1/8.13.1) with ESMTP id j7QJi3hS021894; Fri, 26 Aug 2005 12:44:03 -0700
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 12:44:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Aug 2005 12:44:03 -0700
Message-ID: <198A730C2044DE4A96749D13E167AD375A2ABF@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Topic: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02
Thread-Index: AcWqdRRb+Z980O10TFub/u3hnMtvawAASEaA
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: wayne <wayne@schlitt.net>, ietf@ietf.org
X-OriginalArrivalTime: 26 Aug 2005 19:44:03.0625 (UTC) FILETIME=[83562190:01C5AA76]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: quoted-printable
Cc: ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com
Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith 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

> Behalf Of wayne
> > 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).

The identities are completely irrelevant.

The only relevant boundary is between what the sender controls and what
they do not. All that any sender, forwarder or any other mail injector
can ever be expected to do is to define the boundaries of the systems
they control.

Once that boundary is defined the definition is fair game for any party
to use to interpret it to meet their operational needs.

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