From owner-ietf-mxcomp@mail.imc.org Thu Mar 02 06:17:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FElnu-0003hB-12 for marid-archive@lists.ietf.org; Thu, 02 Mar 2006 06:17:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FElnt-0001HV-Di for marid-archive@lists.ietf.org; Thu, 02 Mar 2006 06:17:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22AiQFk085621; Thu, 2 Mar 2006 03:44:26 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k22AiQIk085620; Thu, 2 Mar 2006 03:44:26 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zeke.ecotroph.net (zeke.hxr.us [69.31.8.124]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22AiN1e085603 for ; Thu, 2 Mar 2006 03:44:25 -0700 (MST) (envelope-from leslie@thinkingcat.com) Received: from [10.71.1.40] ([::ffff:203.221.61.236]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 02 Mar 2006 05:43:28 -0500 id 01588189.4406CC51.00002100 Message-ID: <4406CC71.1010306@thinkingcat.com> Date: Thu, 02 Mar 2006 05:44:01 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Mehnle CC: Internet Architecture Board , MARID , SPF Council , Internet Engineering Task Force , SPF Discussion , "Iesg (E-mail)" Subject: IAB Response to the Appeal from Julian Mehnle References: <200602082212.40645.julian@mehnle.net> In-Reply-To: <200602082212.40645.julian@mehnle.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 On February 8, 2006, The IAB received an appeal from Julian Mehnle appealing the IESG decision to publish draft-lyon-senderid-core as an Experimental RFC. According to the procedures in Section 6.5.2 of RFC 2026, the IAB has reviewed the situation and issues the following response. 1. Summary of IAB Response The appeal is denied and the IESG's decision is upheld. 2. Background After the termination of the MARID WG, the IESG approved both draft-schlitt-spf-classic-02 and draft-lyon-senderid-core as Experimental RFCs. Both RFCs were to bear the following note: "The following documents (draft-schlitt-spf-classic, draft-katz-submitter, draft-lyon-senderid-core, draft-lyon-senderid-pra) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group. The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them. The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future." Mr. Mehnle appealed the approval of draft-lyon-senderid-core on the grounds that the proposed protocols were incompatible and that the IESG should rewrite draft-lyon-senderid-core to assume the SPF classic interpretation unless a new-style record was present. The IESG rejected his appeal on the grounds that it involved a technical change to the document but added the following strengthened note: "Note that the Sender ID experiment may use DNS records which may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt. Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. Participants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC XXXX (draft-lyon-senderid-core) and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict." Mr. Mehnle appealed to the IAB, reiterating his original issue and raising the following process issue: Finally, the IESG's approval of conflicting experiments could be seen as a failure in following the standards process[9], which in section 4.2.1, "Experimental", requires "verification that there has been adequate coordination with the standards process", which would by analogy not only mean coordination with standards track RFCs but also with other experimental RFCs. 3. Discussion The process issue that Mr. Mehnle raises is rooted in RFC 2026, Section 4.2.1: The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution. On the basis of this text, the IAB concludes that the IESG's approval of draft-lyon-senderid-core does not constitute an endorsement of this technology but simply a publication for the "general information of the Internet technical community". With respect to the issue of adequate coordination, Section 4.2.3 reads (in part): If (a) the IESG recommends that the document be brought within the IETF and progressed within the IETF context, but the author declines to do so, or (b) the IESG considers that the document proposes something that conflicts with, or is actually inimical to, an established IETF effort, the document may still be published as an Experimental or Informational RFC. In these cases, however, the IESG may insert appropriate "disclaimer" text into the RFC either in or immediately following the "Status of this Memo" section in order to make the circumstances of its publication clear to readers. The IAB concludes that this paragraph explicitly permits the publication of work that conflicts with existing IETF standards work, provided that it bears an appropriate disclaimer. In this case, the IESG provided a substantial disclaimer. Without determining whether or not this experimental document actually conflicts, we conclude that the disclaimer added by the IESG would in any event be sufficient to allow the publication of this document as Experimental. 4. IAB Conclusion On the basis of the available record and the IESG's response, the IAB concludes that the IESG gave due consideration to the technical issues raised by Mr. Mehnle and reached a decision according to the process specified by RFC 2026. We therefore conclude that the appeal should be denied and the original IESG decision upheld. Note: IAB voting member Bernard Aboba recused himself from the discussion and decision of this appeal. Leslie Daigle, for the IAB. From owner-ietf-mxcomp@mail.imc.org Thu Mar 02 12:56:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEs2Q-0001h7-E7 for marid-archive@lists.ietf.org; Thu, 02 Mar 2006 12:56:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEs2P-0000PZ-2X for marid-archive@lists.ietf.org; Thu, 02 Mar 2006 12:56:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22HT2TD002225; Thu, 2 Mar 2006 10:29:02 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k22HT2RI002224; Thu, 2 Mar 2006 10:29:02 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from shu.cs.utk.edu (shu.cs.utk.edu [160.36.56.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22HT1YX002218 for ; Thu, 2 Mar 2006 10:29:01 -0700 (MST) (envelope-from moore@cs.utk.edu) Received: from localhost (shu [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 1E49D13B3A; Thu, 2 Mar 2006 12:28:55 -0500 (EST) Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31061-06; Thu, 2 Mar 2006 12:28:53 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by shu.cs.utk.edu (Postfix) with ESMTP id 7FE9313B2F; Thu, 2 Mar 2006 12:28:52 -0500 (EST) Date: Thu, 2 Mar 2006 12:29:02 -0500 From: Keith Moore To: "Constantine A. Murenin" Cc: spf-discuss@v2.listbox.com, ietf@ietf.org, ietf-mxcomp@imc.org, iab@iab.org, iesg@ietf.org, julian@mehnle.net, spf-council@v2.listbox.com Subject: Re: [spf-discuss] IAB Response to the Appeal from Julian Mehnle Message-Id: <20060302122902.428cd48d.moore@cs.utk.edu> In-Reply-To: References: <200602082212.40645.julian@mehnle.net> <4406CC71.1010306@thinkingcat.com> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.11; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a when editing documents that purport to describe existing practices and protocols, there is often a conflict between documenting existing practice and describing desirable practice (or undesirable practice). this conflict results in confusion of goals, and one possible result is that the document describes neither existing practice nor desirable practice. in resolving the conflict it is sometimes useful to separate the two efforts: - describe existing practice, warts and all - describe what is believed to be good or bad about the existing practice this doesn't have to be done in separate documents but the efforts should be separate so that each effort can have a clear focus. once there is an understanding about what is good and/or bad about existing practice, notes or footnotes can be added to the description of existing practice to inform the reader of these annotations. if there's not consensus about what is good or bad about existing practice, it may be useful to document the lack of consensus. Keith p.s. I am personally of the opinion that SPF in all but a few corner cases is harmful to the interoperability of Internet mail, so I'm very keen to have those limitations documented. From owner-ietf-mxcomp@mail.imc.org Thu Mar 02 14:07:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEt8h-0001cS-1b for marid-archive@lists.ietf.org; Thu, 02 Mar 2006 14:07:03 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEt8f-000323-Je for marid-archive@lists.ietf.org; Thu, 02 Mar 2006 14:07:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22ILc50004215; Thu, 2 Mar 2006 11:21:38 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k22ILcw4004214; Thu, 2 Mar 2006 11:21:38 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [195.30.85.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22ILbKx004207 for ; Thu, 2 Mar 2006 11:21:38 -0700 (MST) (envelope-from julian@mehnle.net) Received: from cl-40.muc-02.de.sixxs.net (cl-40.muc-02.de.sixxs.net [2001:a60:f000:27::2]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,56bits,EXP1024-RC4-SHA) by io.link-m.de with esmtp; Thu, 02 Mar 2006 18:21:35 +0000 id 00004178.440737AF.00002972 From: Julian Mehnle To: spf-discuss@v2.listbox.com, ietf@ietf.org, ietf-mxcomp@imc.org Subject: Re: IAB Response to the Appeal from Julian Mehnle Date: Thu, 2 Mar 2006 18:21:31 +0000 User-Agent: KMail/1.8.3 References: <200602082212.40645.julian@mehnle.net> <20060302122902.428cd48d.moore@cs.utk.edu> In-Reply-To: <20060302122902.428cd48d.moore@cs.utk.edu> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603021821.32411.julian@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To any who reply to this thread: please, please trim the list of recipients to remove any of the following addresses, unless you explicitly want to address them: * iab@iab.org * iesg@ietf.org * spf-council@v2.listbox.com Keith Moore wrote: > when editing documents that purport to describe existing practices and > protocols, there is often a conflict between documenting existing > practice and describing desirable practice (or undesirable practice). > this conflict results in confusion of goals, and one possible result is > that the document describes neither existing practice nor desirable > practice. > > in resolving the conflict it is sometimes useful to separate the two > efforts: > > - describe existing practice, warts and all > - describe what is believed to be good or bad about the existing > practice I agree. But please note that there was no "existing practice" of re-using "v=spf1" records for the checking of the PRA identity or any other non- envelope identities when Microsoft first submitted the Sender ID drafts to the IESG after the demise of the MARID WG. See my IESG appeal (included in the IAB appeal[1]) for details on the history of Sender ID's re-use of "v=spf1". Please do not spread urban legends. Julian. References: 1. http://www.iab.org/appeals/2006-02-08-mehnle-appeal.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBzeswL7PKlBZWjsRAqBmAJ9AdDrgJmu57uoKLxESZDVnLK1yVwCgrQM0 Rm1xWFooLP/oOhQ45xXBTMY= =1M5G -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Sat Mar 04 17:48:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFfYG-00059P-Gq for marid-archive@lists.ietf.org; Sat, 04 Mar 2006 17:48:40 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFfYF-0000KC-Un for marid-archive@lists.ietf.org; Sat, 04 Mar 2006 17:48:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24MIo1L010991; Sat, 4 Mar 2006 15:18:50 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k24MIofA010990; Sat, 4 Mar 2006 15:18:50 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24MInD3010983 for ; Sat, 4 Mar 2006 15:18:49 -0700 (MST) (envelope-from mureninc@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so966713nzd for ; Sat, 04 Mar 2006 14:18:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OMfrPRzNXBnSl/dnwy1WCmvgs5JNCVLVwrLTYOWiVkDm5xEZlH7hUO5kDDaJYrmL9UvWGUkXP13qdyoZLR1pl+dHk7XYIdSC5sKDwu/gAw2OgHiO5X4g96EUx3U/9yrRAerJ3vBdKOMCmuL2uEqLjl9p0P1KVV9J7Trw8O6GaOA= Received: by 10.65.206.8 with SMTP id i8mr2033025qbq; Sat, 04 Mar 2006 14:18:48 -0800 (PST) Received: by 10.65.73.3 with HTTP; Sat, 4 Mar 2006 14:18:48 -0800 (PST) Message-ID: Date: Sat, 4 Mar 2006 22:18:48 +0000 From: "Constantine A. Murenin" To: MARID Subject: Fwd: [spf-discuss] IAB Response to the Appeal from Julian Mehnle : ietf-mxcomp In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200603021245.k22Cj1Br090262@balder-227.proper.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k24MInD3010985 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 I was just made aware that the 2-day old message I sent didn't get to the mailing list, and I am now asked to (manually) resent it. I hereby resent the request that I have received, which includes the copy of my original message, and the explanation of why it was delayed for as long as 2 days and 9 hours. Thanks, Constantine. ---------- Forwarded message ---------- Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by mx.gmail.com with ESMTP id 15si2744981nzn.2006.03.04.13.53.49; Sat, 04 Mar 2006 13:53:50 -0800 (PST) Received-SPF: neutral (gmail.com: 192.245.12.227 is neither permitted nor denied by best guess record for domain of phoffman@imc.org) Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24LrlKD010248 for ; Sat, 4 Mar 2006 14:53:48 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200603021245.k22Cj1Br090262@balder-227.proper.com> References: <200603021245.k22Cj1Br090262@balder-227.proper.com> Date: Sat, 4 Mar 2006 13:53:41 -0800 To: mureninc@gmail.com From: Paul Hoffman / IMC Subject: Re: [spf-discuss] IAB Response to the Appeal from Julian Mehnle : ietf-mxcomp Content-Type: text/plain; charset="us-ascii" ; format="flowed" > >From owner-ietf-mxcomp Thu Mar 2 05:45:00 2006 >Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) > by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22Cix0Z090243 > for ; Thu, 2 Mar 2006 05:45:00 -0700 (MST) > (envelope-from mureninc@gmail.com) >Received: by zproxy.gmail.com with SMTP id n29so414566nzf > for ; Thu, 02 Mar 2006 04:44:59 -0800 (PST) >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=sLgMY8rRp/pv+GqWilXAdGWnJe7KnH9ZGZuOLCkSRk5T10exf3p96djYO5gIDXygoXVCiiR2yI6zY460DCCnDvM8zQQ8tYNnsMMt85Jl1sUI92LA7ZJ0bZFrk5oLfpVs834/4SRqvxHOQPjNnFGau/MNA5z64rsT0kchy83XH2Y= >Received: by 10.64.179.7 with SMTP id b7mr631040qbf; > Thu, 02 Mar 2006 04:44:59 -0800 (PST) >Received: by 10.65.73.3 with HTTP; Thu, 2 Mar 2006 04:44:59 -0800 (PST) >Message-ID: >Date: Thu, 2 Mar 2006 12:44:59 +0000 >From: "Constantine A. Murenin" >To: spf-discuss@v2.listbox.com >Subject: Re: [spf-discuss] IAB Response to the Appeal from Julian >MehnleCc: "Julian Mehnle" , > "Internet Architecture Board" , > MARID , > "SPF Council" , > "Internet Engineering Task Force" , > "Iesg (E-mail)" >In-Reply-To: <4406CC71.1010306@thinkingcat.com> >MIME-Version: 1.0 >Content-Type: text/plain; charset=ISO-8859-1 >Content-Disposition: inline >References: <200602082212.40645.julian@mehnle.net> > <4406CC71.1010306@thinkingcat.com> >Content-Transfer-Encoding: 8bit >X-MIME-Autoconverted: from quoted-printable to 8bit by >balder-227.proper.com id k22Cj00Z090245 > >On 02/03/06, Leslie Daigle wrote: >> On February 8, 2006, The IAB received an appeal from Julian Mehnle >> appealing the IESG decision to publish draft-lyon-senderid-core as an >> Experimental RFC. According to the procedures in Section 6.5.2 of RFC >> 2026, the IAB has reviewed the situation and issues the following >> response. >> >> 1. Summary of IAB Response >> >> The appeal is denied and the IESG's decision is upheld. >> >> >> 2. Background >> >> After the termination of the MARID WG, the IESG approved both >> draft-schlitt-spf-classic-02 and draft-lyon-senderid-core as >> Experimental RFCs. Both RFCs were to bear the following note: >> >> "The following documents (draft-schlitt-spf-classic, >> draft-katz-submitter, draft-lyon-senderid-core, >> draft-lyon-senderid-pra) are published simultaneously as >> Experimental RFCs, although there is no general technical consensus >> and efforts to reconcile the two approaches have failed. As such >> these documents have not received full IETF review and are >> published "AS-IS" to document the different approaches as they were >> considered in the MARID working group. > >The problem is that they ARE NOT published AS-IS to document the >different approaches as they were considered (and _documented_) in the >MARID working group. This IESG statement clearly violates the reality, >just look at what was presented in the appeal: > ><submissions from the SPF and Sender ID authors and >draft-lyon-senderid-core-00 was submitted (which for the first time >included the re-interpretation of "v=spf1" records for the PRA >identity). Accepting such a submission despite the prior consensus of >the MARID WG[5] (which was closed afterwards) that "v=spf1" should not >be used for checking of PRA clearly violates the ultimate goal of >producing reliable standards.>> > ><the then-current Sender ID specification >draft-ietf-marid-protocol-03[18] did not include the re-use of >"v=spf1" records for PRA checking. This was only introduced in the >individual submission draft-lyon-senderid-core-00 [19] in October >2004. Also did Microsoft's record generation wizards generate only >"v=spf2.0/pra" records until the end of October[20,21], when they >began generating only "v=spf1" records.>> > >I have not heard anyone question this issue with Sender ID that was >once again raised in the IAB appeal. Do you thus find it ethical and >professional to publish these RFCs with the note that does not reflect >the documented reality of the MARID WG? > >If any note is to be included in the RFCs, it should be the one from >the appeal. > >Cheers, >Constantine. The message above was not sent to the mailing list because, as an anti-spam measure, the list software prevents people whose exact address is not on any mailing list we run from posting to lists. I have now permanently added the above address to the "OK to post" list. Please send your message to the list again. ---------- End of forwarded message ----------