Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Bruce Lilly <blilly@erols.com> Tue, 24 May 2005 14:09 UTC
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OE9NbJ093193; Tue, 24 May 2005 07:09:23 -0700 (PDT) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OE9N9Y093192; Tue, 24 May 2005 07:09:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OE9MvH093184 for <ietf-smtp@imc.org>; Tue, 24 May 2005 07:09:22 -0700 (PDT) (envelope-from blilly@erols.com)
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id 5DBD929941; Tue, 24 May 2005 10:09:21 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j4OE9Khe014967(8.13.1/8.13.1/mail.blilly.com sendmail.mc.mail 1.23 2005/03/23 20:35:49) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) ; Tue, 24 May 2005 10:09:20 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j4OE9JPI014966(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Tue, 24 May 2005 10:09:19 -0400
From: Bruce Lilly <blilly@erols.com>
Reply-To: ietf-smtp@imc.org
Organization: Bruce Lilly
To: ietf-smtp@imc.org
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Tue, 24 May 2005 10:09:12 -0400
User-Agent: KMail/1.8
Cc: Frank Ellermann <nobody@xyzzy.claranet.de>
References: <x4r7g17iye.fsf@footbone.schlitt.net> <200505231200.47793.blilly@erols.com> <42922372.258E@xyzzy.claranet.de>
In-Reply-To: <42922372.258E@xyzzy.claranet.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200505241009.13491.blilly@erols.com>
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
On Mon May 23 2005 14:39, Frank Ellermann wrote: > <http://www.OpenSPF.org/cgi-bin/openspf_pledge.cgi> 154 people. Out of approx. 10 billion. Unimpressive. > > the IETF and IAB generally don't like specifying > > multiple incompatible ways to do the same thing > > The "surviving" LMAP proposals (CSV, MTAMARK, SPF) > do very different things, SPF covers some older ideas. They all suffer from similar problems involving the issues described in previous messages: 1. conflating sending and receiving 2. failure to understand fundamental properties of SMTP, e.g. MAIL FROM remains unchanged during transport 3. attempts to assign a relationship between domain names and IP addresses for sending email; there is no such relationship etc. > If "the IETF" has a problem with stating the common > practice in SPF, then "the IETF" would not have closed > MARID only three days after a potential successor was > proposed, don't you think ? Post hoc, ergo propter hoc fallacy. > > Refers to POSIX, an external standard. Raises questions > > about implementations. > > It is in an example, ..."the same value as returned by the"... Would that be the one that fails to account for leap seconds? > Probably off by one day and it needs fixing to get UTC, but > let's say that it's not impossible to solve this problem on > any host with date and time. It has been asserted that some hosts lack the capability to determine time (e.g. see the RFC 2476 successor draft). Note, however, that I'm not the one making the assertion. > > Not OK for an Experimental or Informational RFC > > Now if the I-D would intend to be one of these, then it would > of course use the corresponding status. But the form doesn't > have any "Status: TBD". This stuff could be updated in the > 48 hours if necessary. When one asks for review of a draft intended for RFC publication, it is at least a common courtesy to clearly and unambiguously indicate the intended status. Because, as noted earlier in this discussion, the issues that a reviewer considers vary according to the intended status. In this case, the draft itself provides no clue, the I-D tracker says one thing, the description of the intent (document as-is == Informational; see also draft-iesg-info-exp-00.txt announced yesterday) indicates another, and some text at the very end of the request for review says yet a third thing. The status asserted in the field registration cannot wait for final tweaking by a vested interest (viz. the author(s)) -- it needs to be consistent with the document status as determined by the IESG (based at least in part on review comments). > > something which is obsolete or harmful. > > Which isn't the case after we have found that the conspiracy to > exclude non-POSIX hosts from SMTP failed miserably. You missed the main points -- SPF is doubly harmful to the mail system, as noted in an earlier message. > Okay, let them have fun. My BCP 78 erratum is available at the > RfC editor (or that's what I hope). If you mean the current BCP 78 (RFC 3978), there are no errata published as of this morning, and the errata page says the last update was in October 2004. > > You're: > > a) confusing *typical* cases > > Like you I simply quoted STD 10. I cited specific cases related to reality, not quotes from a two decades old, multiply amended and ultimately obsoleted document. > > b) ignoring the fact that, as explained in some detail, the > > MAIL FROM argument is passed unchanged from one MTA relay > > to another during transport > > Not in STD 10. Are you now starting with RfC 1123 5.3.6 (a), > or are you still talking about STD 10 ? The Hosts Requirements Standard (STD 3) long ago amended RFC 821. You have to take that into account to understand SMTP, and it has been taken into account in the specification (RFC 2821) which obsoletes 821. It is an observable and verifiable fact that MAIL FROM is not altered in transit as you suggest. It you were right, one would see Return-Path fields at "final" delivery with old-fashioned source routes. A quick check of more than a thousand messages reveals zero source routes. I could check a larger corpus, but that's unnecessary -- if you really think that source routes are in current use, you are deluded. > Wasn't it you who said that proposed standards should be moved > to either "draft" or "historic" after at most two years ? Not that I can recall; RFC 2026 states that the IESG is supposed to review documents at Proposed or Draft at 24 months and at 12 month intervals thereafter. It doesn't say that such documents must necessarily be moved, though that's the only way for the IESG to get the continued periodic reviews removed from their workload. > That's not 20 years old, that's RfC 2821, if you like it more. There are several problems in 2821; as already noted, a mailbox receives mail, so the term "source mailbox" is devoid of meaning. RFCs aren't always flawless. > > Receipt (but not *sending*) of mail is tied to a domain name > > by DNS MX RRs. > > Check out the parts about "domain", "HELO", and "MAIl FROM" in > RfC 2821 again, they MUST be resolvable (MX. A, CNAME), and we > already discussed MAIL FROM:<> (see above). Of course a non-null return path needs to be resolvable -- for the purpose of *receiving* delivery notifications. > > In particular, no fixed set of IP addresses is associated > > with the sending of such mail; > > Yes, that's the idea of RMX/SPF, it allows to define this set. That's at the heart of the problem -- it attempts to define a set which makes no sense; worse than that, it is harmful. > If that's not what you want for erols.com just don't define it. I don't have that option. You might want to try some whois queries before continuing this discussion. You might also wish to review my earlier comment about "an organization with 50,000 personnel", then extrapolate that to an ISP with "more than 1 million customer connections" (http://www.rcn.com/company/index.php). > >> Domain owners > > Bzzt. Fatal flaws. see above. > > If you don't like RfC 2821 chapter 3.6 that's your choice, but > no fatal flaw. The only fatal flaw is RfC 1123 5.3.6 (a), and > SPF allows to fix it for those who wish to fix it. You'll have to be more clear; I see no problem with STD 3 section 5.3.6 (a) (and I observe that STD 3 has not been obsoleted). Nor do I see any relationship between alias expansion and SPF. Let's look at a specific example of one problem with SPF; the attempt to associate a set of IP addresses with the domain in a MAIL FROM return path. Consider the following message header excerpt: Return-Path: <nobody@xyzzy.claranet.de> Received: from mr09.mrf.mail.rcn.net (EHLO mr09.mrf.mail.rcn.net) (207.172.4.28) by ms07.mrf.mail.rcn.net (MOS 3.5.6-GR FastPath queued) with ESMTP id GKT45663; Thu, 19 May 2005 14:37:59 -0400 (EDT) Received: from mx23.mrf.mail.rcn.net (mx23.mrf.mail.rcn.net [207.172.4.102]) by mr09.mrf.mail.rcn.net (MOS 3.5.7-GR) with ESMTP id CCC77732; Thu, 19 May 2005 14:29:45 -0400 (EDT) Received: from unknown (HELO mx23.mrf.mail.rcn.net) (10.255.5.102) by mx23.mrf.mail.rcn.net with ESMTP; 19 May 2005 14:29:44 -0400 Received: from gundel.de.clara.net (212.82.225.86) by mx23.mrf.mail.rcn.net with ESMTP; 19 May 2005 14:29:41 -0400 Received: from [62.80.58.103] (helo=xyzzy) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1DYpzH-0005K5-W5 for blilly@erols.com; Thu, 19 May 2005 20:43:16 +0200 Message-ID: <428CDA90.3522@xyzzy.claranet.de> Note that the return path is <nobody@xyzzy.claranet.de>. Using SPF specification rules, the corresponding text record is: xyzzy.claranet.de text = "v=spf1 redirect=claranet.de" which appears to point to: claranet.de text = "v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all" At various points in transport, the client IP addresses have included 207.172.4.28, 207.172.4.102, (RFC 1918 unroutable) 10.255.5.102, and 62.80.58.103. At any of those times, if one were silly enough to take notice of SPF, the message could have been rejected, as none of those IP addresses are in the specified ranges. Is that really what you want? ------- "I beseech you in the bowels of Christ, think it possible you may be mistaken" -- Oliver Cromwell
- Re: "Header Reordering", yet again Robert A. Rosenberg
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: "Header Reordering", yet again Hector Santos
- Re: "Header Reordering", yet again Hector Santos
- Is it really FUD? [Re: "Header Reordering", yet a… Hector Santos
- Re: "Header Reordering", yet again Hector Santos
- Re: "Header Reordering", yet again Bruce Lilly
- Re: "Header Reordering", yet again Bruce Lilly
- Re: "Header Reordering", yet again Hector Santos
- Re: "Header Reordering", yet again Hector Santos
- Re: "Header Reordering", yet again Robert A. Rosenberg
- Re: "Header Reordering", yet again Frank Ellermann
- Re: "Header Reordering", yet again David MacQuigg
- Re: "Header Reordering", yet again william(at)elan.net
- Re: "Header Reordering", yet again Bruce Lilly
- Re: "Header Reordering", yet again David MacQuigg
- Re: "Header Reordering", yet again Valdis.Kletnieks
- Re: "Header Reordering", yet again David MacQuigg
- Re: "Header Reordering", yet again David MacQuigg
- Re: "Header Reordering", yet again Valdis.Kletnieks
- Re: "Header Reordering", yet again Valdis.Kletnieks
- Re: "Header Reordering", yet again Frank Ellermann
- Re: "Header Reordering", yet again Arnt Gulbrandsen
- Re: "Header Reordering", yet again Paul Smith
- Re: "Header Reordering", yet again Valdis.Kletnieks
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: "Header Reordering", yet again Hector Santos
- Re: "Header Reordering", yet again Paul Smith
- Re: MTAMARK Frank Ellermann
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Valdis.Kletnieks
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Robert A. Rosenberg
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Robert A. Rosenberg
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Bruce Lilly
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Markus Stumpf
- Re: Chain of Trusted Forwarders David MacQuigg
- Re: Chain of Trusted Forwarders David MacQuigg
- Re: Chain of Trusted Forwarders Robert A. Rosenberg
- Re: Chain of Trusted Forwarders John Leslie
- Re: Chain of Trusted Forwarders Valdis.Kletnieks
- Re: Chain of Trusted Forwarders Valdis.Kletnieks
- Re: Chain of Trusted Forwarders Valdis.Kletnieks
- Re: "Header Reordering", yet again Frank Ellermann
- Re: "Header Reordering", yet again Frank Ellermann
- Re: Chain of Trusted Forwarders David MacQuigg
- Re: Chain of Trusted Forwarders David MacQuigg
- Re: "Header Reordering", yet again Bruce Lilly
- Re: Chain of Trusted Forwarders Valdis.Kletnieks
- Re: "CSV" [not comma-separated values] Dave Crocker
- Re: "Header Reordering", yet again John Leslie
- Chain of Trusted Forwarders David MacQuigg
- Re: "Header Reordering", yet again Valdis.Kletnieks
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: "Header Reordering", yet again David MacQuigg
- Re: "Header Reordering", yet again Bruce Lilly
- Re: "Header Reordering", yet again Bruce Lilly
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: "Header Reordering", yet again David MacQuigg
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: SPF I-D for review: draft-schlitt-spf-classic… Dave Crocker
- Re: SPF I-D for review: draft-schlitt-spf-classic… Dave Crocker
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Certified Server Validation (was: "CSV" [not comm… Frank Ellermann
- Re: "Header Reordering", yet again David MacQuigg
- Re: "Header Reordering", yet again Bruce Lilly
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: "Header Reordering", yet again David MacQuigg
- Re: "Header Reordering", yet again Bruce Lilly
- Re: "Header Reordering", yet again Valdis.Kletnieks
- Re: "Header Reordering", yet again Paul Smith
- Re: "Header Reordering", yet again Lyndon Nerenberg
- Re: "CSV" [not comma-separated values] Valdis.Kletnieks
- Re: "Header Reordering", yet again Paul Smith
- Re: "CSV" [not comma-separated values] wayne
- Re: "CSV" [not comma-separated values] Bruce Lilly
- Re: "CSV" [not comma-separated values] ned+ietf-smtp
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: "Header Reordering", yet again Arnt Gulbrandsen
- Re: "CSV" [not comma-separated values] Valdis.Kletnieks
- Re: "Header Reordering", yet again Bruce Lilly
- Re: "Header Reordering", yet again ned+ietf-smtp
- Re: "Header Reordering", yet again David MacQuigg
- Re: "CSV" [not comma-separated values] ned+ietf-smtp
- Re: "CSV" [not comma-separated values] Tony Finch
- Re: "CSV" [not comma-separated values] Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: "Envelope", yet again Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: "CSV" [not comma-separated values] Tony Finch
- Re: SPF I-D for review: draft-schlitt-spf-classic… Robert A. Rosenberg
- Re: "Envelope", yet again John C Klensin
- Re: SPF I-D for review: draft-schlitt-spf-classic… Hector Santos
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- "CSV" [not comma-separated values] Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: SPF I-D for review: draft-schlitt-spf-classic… Robert A. Rosenberg
- Re: SPF I-D for review: draft-schlitt-spf-classic… Robert A. Rosenberg
- LMAP systems wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: MTAMARK etc. Frank Ellermann
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Tony Finch
- Re: SPF I-D for review: draft-schlitt-spf-classic… Paul Smith
- Re: SPF I-D for review: draft-schlitt-spf-classic… Arnt Gulbrandsen
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Tony Finch
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: MTAMARK etc. Bruce Lilly
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Tony Finch
- Re: proposed Received-SPF trace header wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… Robert A. Rosenberg
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Bruce Lilly
- Re: MTAMARK (was: SPF I-D for review: draft-schli… Markus Stumpf
- Re: SPF I-D for review: draft-schlitt-spf-classic… Valdis.Kletnieks
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: misdirected bounces Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… Valdis.Kletnieks
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: misdirected bounces (was: SPF I-D for review:… ned+ietf-smtp
- Re: misdirected bounces (was: SPF I-D for review:… Bruce Lilly
- Re: "Envelope", yet again Bruce Lilly
- Re: "Envelope", yet again Bruce Lilly
- Re: misdirected bounces (was: SPF I-D for review:… John Leslie
- Re: SPF I-D for review: draft-schlitt-spf-classic… John Leslie
- Re: "Envelope", yet again John Leslie
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: misdirected bounces (was: SPF I-D for review:… Markus Stumpf
- Re: "Envelope", yet again Tony Finch
- Re: SPF I-D for review: draft-schlitt-spf-classic… Markus Stumpf
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Re: SPF I-D for review: draft-schlitt-spf-classic… Valdis.Kletnieks
- Re: "Envelope", yet again John Leslie
- Re: SPF I-D for review: draft-schlitt-spf-classic… Hector Santos
- "Envelope", yet again Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… Markus Stumpf
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: proposed Received-SPF trace header Valdis.Kletnieks
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- proposed Received-SPF trace header John Leslie
- Re: SPF I-D for review: draft-schlitt-spf-classic… John Leslie
- Re: SPF I-D for review: draft-schlitt-spf-classic… Frank Ellermann
- Intended status (was: SPF I-D for review: draft-s… Frank Ellermann
- Re: SPF I-D for review: draft-schlitt-spf-classic… ned+ietf-smtp
- Re: SPF I-D for review: draft-schlitt-spf-classic… wayne
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- Re: SPF I-D for review: draft-schlitt-spf-classic… ned+ietf-smtp
- Re: SPF I-D for review: draft-schlitt-spf-classic… Bruce Lilly
- SPF I-D for review: draft-schlitt-spf-classic-01.… wayne