Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
Frank Ellermann <nobody@xyzzy.claranet.de> Fri, 26 August 2005 22:52 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8n3O-0007xt-Km; Fri, 26 Aug 2005 18:52:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8n3M-0007xo-EF for ietf@megatron.ietf.org; Fri, 26 Aug 2005 18:52:04 -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 SAA29398 for <ietf@ietf.org>; Fri, 26 Aug 2005 18:52:01 -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 1E8n4A-0002aD-9G for ietf@ietf.org; Fri, 26 Aug 2005 18:52:55 -0400
Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8n29-0004O2-DB for ietf@ietf.org; Sat, 27 Aug 2005 00:50:49 +0200
Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Sat, 27 Aug 2005 00:50:49 +0200
Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Sat, 27 Aug 2005 00:50:49 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Sat, 27 Aug 2005 00:40:39 +0200
Organization: <URL:http://purl.net/xyzzy>
Lines: 127
Message-ID: <430F9A67.5A7C@xyzzy.claranet.de>
References: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 62.80.58.221
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Content-Transfer-Encoding: 7bit
Cc: ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com
Subject: 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
Hallam-Baker, Phillip wrote: > 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. Hogwash, I've proposed a way to "fix" PRA to avoid at least the worst incompatibility (a "default Sender" derived from the Return-Path in the spirit of RfC 3834). After that was ignored (maybe it was a bad idea) I proposed a clean "opt-in" modifier for those, where both "boundaries" for PRA and MAiL FROM are in fact identical. After all that is possible, even likely (somebody says 80%). But it is not guaranteed (80% is not good enough, BLs operate near 99.5%). The WG settled on "spf2.0/pra,mfrom" in the last week of its existence, I supported this. Certainly not my fault that the WG was closed exactly at the time when a clean solution was in sight, http://purl.net/xyzzy/home/test/MARID.appeal.txt JFTR. the last quote in this mail was an article from you. MARID was closed as soon as it was clear that abusing v=spf1 for PRA without explicit consent of the sender policy publisher is a non-starter, because it would be _tschnical_ FUBAR. > 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. Sure, you do what you like, use PRA, or how about Message-IDs ? Or better try a random generator., no DNS headaches if all you want are random rejections. Most mails are spam, so rejecting mails always hits more spam than legit mail, no matter how you decide this. But v=spf1 FAIL is no 80% or 99.5% idea, it is 100% if you do it right accepting all consequences. "Interpret v=spf1 with PRA" is not implicitly the intent of most publishers. If they explicitly want this they are free to publish spf2.0/pra. We're talking about RfCs defining _sender policies_ - what you as receiver do with it is beside the point, as long as domain owners can express their intention. Several hundred thousand domain owners did this, they know or should know that it means what the relevant v=spf1 drafts said. And the SPF RfC reflects this as good as possible (calling that an "experiment" is a part of the many MARID legends all featuring the "let's steal v=spf1 for PRA" theme). PRA doesn't necessarily reflect what these publishers intended. > That is the entire point of a spam filtering scheme. Neither v=spf1 (spf2.0/mfrom) nor PRA (spf2.0/pra) are a good "spam filtering scheme". PRA is a (dubious) anti-phishing idea, and the MAIL FROM part of v=spf1 fights bogus bounces to innocent (spoofed) bystanders. You can use both as input for "spam filtering", e.g. use PASS as "asssume innocent until proven guilty" like AOL, or use a FAIL as "once a liar, always a liar" indicator for the sending IP or HELO identity. But the primary purpose of v=spf1 is MOT "yet-another-FUSSP". It's about avoiding bounces to spoofed Return-Paths, and maybe offer a base for FQDN-reputation systems with HELO-PASS (same idea as CSV-CSA). So the design goals of v=spf1 and PRA are already different, no surprise that many resulting policies are also different. > 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. That's not true, this has been proven numerous times. PRA and MAIL FROM identity can be different for various valid reasons. 2476bis 6.1 and 2476bis 8.1 are different chapters. v=spf1 is in the spirit of 2476 6.1, RfC 3834, STD 10, and draft-hutzler. It has nothing to do with 2822-identities, 2476bis 8.1, or PRA. Essentially PRA wants "SHOULD add Sender" where 2476 only says "MAY add Sender" in 8.1. We could discuss this, and in fact "we" (TINW) did, see also: <http://article.gmane.org/gmane.mail.spam.spf.discuss/8162> That's in the same thread mentioned before (started in mxcomp): http://news.gmane.org/group/gmane.mail.spam.spf.discuss/thread=8111 > Sender-ID simply describes one means of interpreting an SPF > record. It may or may not work, it may or may not be optimal If you want "sub-optimal" bogus interpretations then that's your personal right as receiver, but the IETF (mis)represented by the IESG should not sanction this abuse as RfC. You can't publish an RfC where you say "if no MX works just try A", because that would be broken and cause harm. RfCs are not supposed to cause foreseeable harm intentionally - as the very minimum they'd need corresponding security considerations. > that is why it is an experiment. The experimental status of v=spf1 is fictitious and beside the point. The author proposed "PS" with a proper IETF last call. > I do not believe that one group should be able to block a > proposal they do not like by alleging a non-existent conflict Nobody proposed to "block" PRA. It should only stay away from sender policies designed for the incompatible v=spf1. There's nothing wrong with PRA-experiments using spf2-0/pra policies. While I guess that PRA will fail miserably I've no problem if others wish to paricipante in this PRA-experiment. But (not only) I don't want this. No experiments with non-voluntary participants. We're talking about legit mails lost in limbo, and spectacular pseudo-PRA-PASS phishing opportunities. Bye _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Appeal: Publication of draft-lyon-senderid-core-0… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… Harald Tveit Alvestrand
- Re: Appeal: Publication of draft-lyon-senderid-co… Bill Sommerfeld
- Re: Appeal: Publication of draft-lyon-senderid-co… Ned Freed
- Re: Appeal: Publication of draft-lyon-senderid-co… Bill Sommerfeld
- Re: Appeal: Publication of draft-lyon-senderid-co… Dave Crocker
- Re: Appeal: Publication of draft-lyon-senderid-co… Spencer Dawkins
- Re: Appeal: Publication of draft-lyon-senderid-co… Stephane Bortzmeyer
- Re: Appeal: Publication of draft-lyon-senderid-co… Theodore Ts'o
- Re: Appeal: Publication of draft-lyon-senderid-co… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… Andrew Newton
- Re: Appeal: Publication of draft-lyon-senderid-co… Stephane Bortzmeyer
- Re: Appeal: Publication of draft-lyon-senderid-co… Andrew Newton
- Re: Appeal: Publication of draft-lyon-senderid-co… Andrew Newton
- RE: [spf-discuss] Re: Appeal: Publication of draf… Hallam-Baker, Phillip
- Re: [spf-discuss] Re: Appeal: Publication of draf… Sam Hartman
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- RE: Appeal: Publication of draft-lyon-senderid-co… Thomas Gal
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Bruce Lilly
- Is it necessary to go through Standards Track to … C. M. Heard
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Scott W Brim
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… Douglas Otis
- Re: [spf-discuss] Re: Appeal: Publication of draf… Dotzero
- RE: [spf-discuss] Re: Appeal: Publication of draf… Jeff Macdonald
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… Brian E Carpenter
- Re: Appeal: Publication of draft-lyon-senderid-co… Brian E Carpenter
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Pekka Savola
- Re: Appeal: Publication of draft-lyon-senderid-co… william(at)elan.net
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: [spf-discuss] Re: Appeal: Publication of draf… Dick St.Peters
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Julian Mehnle
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… Dick St.Peters
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: [spf-discuss] Re: Appeal: Publication of draf… william(at)elan.net
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… Sam Hartman
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: [spf-discuss] Re: Appeal: Publication of draf… william(at)elan.net
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Bob Braden
- Re declare SPF and Sender-ID to be Informational John Levine
- Re: Re declare SPF and Sender-ID to be Informatio… Dave Crocker
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Re declare SPF and Sender-ID to be Informatio… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Re declare SPF and Sender-ID to be Informatio… John Levine
- Re: Re declare SPF and Sender-ID to be Informatio… Brian E Carpenter
- Re: declare SPF and Sender-ID to be Informational Frank Ellermann
- Individual submissions and Informational RFCs wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Sam Hartman
- Re: Individual submissions and Informational RFCs John C Klensin
- Re: Individual submissions and Informational RFCs Harald Tveit Alvestrand
- Re: Individual submissions and Informational RFCs wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Sam Hartman
- Last call IETF experiments (was: Appeal ....) Frank Ellermann
- Re: Last call IETF experiments Frank Ellermann
- Re: Last call IETF experiments (was: Appeal ....) John C Klensin
- Re: Last call IETF experiments Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… Frank Ellermann
- Re: Appeal: Publication of draft-lyon-senderid-co… wayne
- Re: Appeal: Publication of draft-lyon-senderid-co… Keith Moore
- Re: Appeal: Publication of draft-lyon-senderid-co… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… william(at)elan.net
- Re: Appeal: Publication of draft-lyon-senderid-co… Douglas Otis
- Re: Appeal: Publication of draft-lyon-senderid-co… william(at)elan.net
- SES or BATV (was: Publication of draft-lyon-sende… Frank Ellermann
- SES vs BATV Douglas Otis
- Re: Last call IETF experiments Sam Hartman
- Re: Publication of draft-lyon-senderid-core-01 in… Douglas Otis
- Re: Last call IETF experiments Frank Ellermann
- Re: Publication of draft-lyon-senderid-core-01 in… Frank Ellermann