IETF Logo Mail Archive

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

"william(at)elan.net" <william@elan.net> Fri, 09 December 2005 18:19 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekmpo-0005oS-Sh; Fri, 09 Dec 2005 13:19:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekmpm-0005nb-Mh for ietf@megatron.ietf.org; Fri, 09 Dec 2005 13:19:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10213 for <ietf@ietf.org>; Fri, 9 Dec 2005 13:18:12 -0500 (EST)
Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekmpz-0005b5-3x for ietf@ietf.org; Fri, 09 Dec 2005 13:19:21 -0500
Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jB9IItCJ018671; Fri, 9 Dec 2005 10:18:55 -0800
Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jB9IIsNt018668; Fri, 9 Dec 2005 10:18:54 -0800
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Fri, 09 Dec 2005 10:18:54 -0800
From: "william(at)elan.net" <william@elan.net>
To: spf-discuss@v2.listbox.com
In-Reply-To: <17305.50310.846622.280515@saint.heaven.net>
Message-ID: <Pine.LNX.4.62.0512090957190.6721@sokol.elan.net>
References: <200512081104.09113.julian@mehnle.net> <4398AE3D.512D@xyzzy.claranet.de> <Pine.LNX.4.64.0512090838400.13902@netcore.fi> <200512091303.37502.julian@mehnle.net> <17305.36224.584090.853821@saint.heaven.net> <x4pso6nvra.fsf@footbone.schlitt.net> <17305.50310.846622.280515@saint.heaven.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: ietf@ietf.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 Fri, 9 Dec 2005, Dick St.Peters wrote:

>> Do you know if Sendmail Inc. is committed to conforming to the RFCs
>> and will change if the RFCs change?
>
> You'll have to ask them.  However, I suspect it's safe to say that
> they will conform to any RFCs that become standards.

SPF & SID document if they become RFCs will not be "standard" - just
documented IETF "experiment".

But as you say Sendmail tries to be compliant with any RFC that is an
email standard and this is a problem if they want to implement SID.

> That said, I will be interested in seeing how they handle the
> "Resent-" header issue.  Currently, it is difficult, if not
> impossible, to make sendmail insert such a header when forwarding (as
> opposed to re-mailing).

One thing the IESG note [due to my appeal] forgot to mention is that
its impossible for implementation to both be compliant with standards
and be doing SID checking (because interpretation of Resent- header
fields in automatic manner is already violation of a standard). The same 
applies to adding Resent- header fields as per SID - if system is doing 
it, this is violation of standards, if it is not doing it, it can not 
claim to be compliant with SID.

So the conflict remains unresolved and it is not just that SID systems 
will have problems with other systems that are complying with standards 
(that is certainly true and would lead to unpredictable results as per
IESG note) but that using SID itself already implies that implementor 
would be violating the standard - I still don't understand how IETF/IESG 
can support publication of such a document for anything but the
INFORMATIONAL use.

The correct thing to do to avoid the conflict (and still use similar
algorithm) is to choose new header field name and register it with IANA.

-- 
William Leibzon
Elan Networks
william@elan.net

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

v2.23.0 | Report a Bug | By Email