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(_at_)xyzzy(_dot_)claranet(_dot_)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(_at_)erols(_dot_)com; Thu, 19 May 2005 20:43:16 +0200
Message-ID: <428CDA90(_dot_)3522(_at_)xyzzy(_dot_)claranet(_dot_)de>
Note that the return path is <nobody(_at_)xyzzy(_dot_)claranet(_dot_)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