Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

Dotzero <dotzero@gmail.com> Mon, 29 August 2005 11:41 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9i10-0001BZ-3m; Mon, 29 Aug 2005 07:41:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ip7-0007zY-41 for ietf@megatron.ietf.org; Fri, 26 Aug 2005 14:21:05 -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 OAA05079 for <ietf@ietf.org>; Fri, 26 Aug 2005 14:21:03 -0400 (EDT)
Received: from wproxy.gmail.com ([64.233.184.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8ipr-0007hJ-1L for ietf@ietf.org; Fri, 26 Aug 2005 14:21:53 -0400
Received: by wproxy.gmail.com with SMTP id i20so199931wra for <ietf@ietf.org>; Fri, 26 Aug 2005 11:20:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jk76+gV3HGgu7TFDQBvfOPYSnIAGb4hT+4BDq1Lj+Z33u3C9h2ZlMX0r0iNcpZURMPsKP71Xe2o/VHHiaeiDSIM68d12HWGfXCgxuD6hT6ab7tI2F4W+GZ6q5bBCuI5KJKFhZFYOAi1sdsn5xMYIphsu2VyNQpT3pxk1ryUafQQ=
Received: by 10.54.30.27 with SMTP id d27mr3540757wrd; Fri, 26 Aug 2005 11:20:38 -0700 (PDT)
Received: by 10.54.122.7 with HTTP; Fri, 26 Aug 2005 11:20:38 -0700 (PDT)
Message-ID: <7ae58c22050826112058b14708@mail.gmail.com>
Date: Fri, 26 Aug 2005 14:20:38 -0400
From: Dotzero <dotzero@gmail.com>
To: spf-discuss@v2.listbox.com
In-Reply-To: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 29 Aug 2005 07:41:11 -0400
Cc: ietf@ietf.org, MARID <ietf-mxcomp@imc.org>
Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with 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

On 8/26/05, Hallam-Baker, Phillip <pbaker@verisign.com> wrote:
> > Let me phrase it this way: the IESG should not sanction conflicting
> > experiments by publishing conflicting specifications,
> 
> I agree.
> 
> But I do not believe that SPF and Sender-ID conflict in any way
> whatsoever and this was accepted by the WG right up to the point where
> people started to complain about IPR licenses.
> 

Not quite correct. The reason that people did not complain was that
supporters of SID were pushing for use of SPF2 records at the time. It
was only after the announcement that SID would use (abuse) SPF1
records that it became an issue.

> I do not think that the IESG should block a proposal citing a conflict
> when the real animus here is entirely due to the IPR issue.
> 

So all of the discussion on the spf-discuss list has nothing to do
with technical issues and has only been a cover for unhappiness with
IPR issues? I find that a stretch.

> 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.
> 

Let us remind ourselves what SPF stands for SENDER Policy Framework.
If the publisher of a record has no reasonable expectation of how that
record will be used and every expectation that it may be abused then
what incentive do they have to publish the record?

SPF does not describe outgoing edge mail servers.... it describes the
policies associated with the domain. The issue at hand is not whether
an individual recipient chooses to interpret the data a particular
way. Interpretation by the recipient is should I reject on softfail or
not or should I assign a point value in conjunction with other things.
Writing a standard which subverts the intent of individuals publishing
to a different and existing standard is simply unethical and wrong.

What happened was essentially a political move because people chose
not to publish SPF2 records for PRA. So, the response was to force
people to opt-out (publish an essentially meaningless SPF2 record)
because the SID camp was losing in the real world marketplace.

> Nobody has ever demonstrated a conflict as far as I am concerned, all
> attempts to allege a conflict begin, "the sender intends" which is
> utterly irrelevant. The sender does not have the right to decide what
> email client I use, they do not have the right to determine what spam
> filter I use either.
> 

An interesting argument. Of what value is publishing a record (of any
sort) if the publisher of said record has a reasonable expectation
that it will be used in arbitrary ways to the publishers detriment?
One argument that was put forth after the announcement that SID would
apply PRA to SPF1 records was that it was a conspiracy to get
publishers to yank their SPF1 records.

People and organizations chose to publish a record according to a
standard because they have a reasonable expectation on how that record
will be used. While there may be edge cases of abuse, the expectation
is that most people will respect the standard. That's why it's called
a standard.


> Sender-ID simply describes one means of interpreting an SPF record. It
> may or may not work, it may or may not be optimal, that is why it is an
> experiment.
>

I can see someone using this "logic" in any number of circumstances....

"Your honor, I have this alternative means of interpreting what a red
stoplight indicates.....go go go as fast as you can".

> An SPF record may be constructed in such a fashion that Sender-ID
> verification is not possible. That is not a conflict, it is simply an
> artifact that results from the baroque nature of the SPF spec.
> 

You are implying that individuals published SPF1 records with the
intent of subverting SID verification. This is akin to blaming the
victim for the actions of the mugger. I would argue that most of those
who published SPF1 records did so with no knowledge or anticipation
that PRA would be applied to those records.

> I do not believe that one group should be able to block a proposal they
> do not like by alleging a non-existent conflict.
> 

I don't hear anyone trying to block the SID proposal in its entirety.
I only see the blocking of an abusive portion of the proposal.

Why weren't the supporters of the SID proposal willing to go out and
promote use of SPF2/PRA format/records? I haven't seen any of the core
SPF activists oppose the use of SPF2 records by SID for PRA.

We again come back to the politics of the issue. SID was losing in the
marketplace (numbers of published records). A significant aspect of
these types of experiments is whether people buy in to the approach.
Applying PRA to SPF1 records was a way of sidestepping this issue
regardless of whether the (publisher)marketplace bought into SID.

Mike

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