In <20050523134752(_dot_)GF89934(_at_)verdi> John Leslie
<john(_at_)jlc(_dot_)net> writes:
Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
After MARID was closed Mark Lentczner and Wayne Schlitt resumed
the work on Meng Wong's "classic" (v=spf1) draft, and that's
what you see here.
The IESG intent at the closing of MARID was that the various drafts
be submitted by individuals for "Experimental" status.
That is fine and dandy, but irrelevant for SPF. SPF was never adopted
by the MARID WG and was never a MARID I-D. That the authors of the
MARID drafts chose not to submit draft-ietf-marid-protocol-* is
mostly their problem.
IMHO, "Experimental" should mean that details will be diddled during
the experiment. Nonetheless, the Abstract may be misleading:
"
" This document describes version 1 of the SPF protocol, whereby a
" domain can explicitly authorize the hosts that are allowed to use
" its domain name in a reverse-path...
The draft in fact describes other uses of the v=spf1 record than
checking the reverse-path. I believe this should be noted in the
abstract.
Hmm... Good point. I'll fix that. Thanks.
The MAIL FROM argument specifies a return path for
delivery-related notifications.
Misdirected bounces are a significant problem: I do not wish to
get in the way of any experiments to reduce the problem. But I have
the impression that SPF intends to do more than this.
Yes, I would say your impression is correct. Many people support SPF
for many different reasons. Reducing bogus bounces is one reason, but
certainly not the only reason. For me, it is far from the most
important reason.
There's also no problem with say "creative" HELOs like my MUA
claiming to be "xyzzy", because there's no FQDN "xyzzy", and
my MUA talks only with its smart hosts, not with arbitrary MXs.
Indeed, as we get into the text, it becomes clear than SPF intends
the same v=spf1 record to be used to check HELO strings.
In fact, the draft _requires_ checking the HELO string if MAIL-FROM
is null: this strikes me as a bad idea, because bounce messages are a
very different case.
Yes, the fall back to the HELO domain has been discussed many times.
Some people think it is critical, some people don't like it. However,
it has been part of the SPF specifications from the very beginning and
thus it seems to be a little late to change it now.
====
I know that earlier discussions of SPF considered the possibility
of matching subdomains to a single SPF record (other than wildcards):
I would recommend clarifying whether any such intent remains.
That portion has been removed because the function was not widely
implemented and the folks on namedroppers strongly objected.
There is an explicit recommendation that domains publish "... -all":
I recommend changing that. Instead, I strongly urge that levels of
disclaiming be defined from the very outset of RFC publication:
Like many subjects related to SPF, this has been hotly debated more
than once. There is a whole section on forwarding, along with other
problems faced by people using SPF. I do not think your suggests are
accurate. In particular, if you use SES, forwarding does not break
with -all.
My overall impression is that SPF probably strikes the wrong balance
between ease of publishing vs. ease of checking; but that's really not
an issue for an Experimental protocol. I will also admit to a prejudice
that ease of establishing reputation will become critical; and this
draft contains a number of features which will make that difficult.
Yes, I understand that your CSV proposal meets your idea of balance
better than the SPF proposal. I think reasonable people can disagree
on which balance is better, and under which circumstances.
-wayne