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.
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.
If the intent is in fact to change the intended status from
Experimental (I-D tracker) to Standards Track (as stated by
the author in the predecessor of this message; see below)
Yes, TTBOMK that's the intent (in fact I'm almost sure, I've
seen the unanimous resolution of the SPF Council).
(If in fact this will be considered for "Proposed Standard", I
would instead strongly urge that the draft be rewritten to match the
abstract: great confusion can be expected if records are published
with one intent and interpreted with another.)
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.
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.
====
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.
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:
- "... -all" should mean the sender _wants_ forwarding to break;
- "... ~all" should mean "please don't break forwarding";
- "... ?all" should indicate doubt whether the IP list is complete;
and the recommendation should be for the publisher to choose one of these.
Experience so far has proven that "... -all" is very problematic, since
forwarding is a receiver-level function, generally outside the control
of the sender or the sending MTA client. Nonetheless, it is clear that
"v=spf1 -all" should be an absolute disclaimer, and IMHO trying to
reduce the strength of the disclaimer for longer records is pointless.
The "Received-SPF" header is an interesting idea, which I shall
discuss separately.
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.
--
John Leslie <john(_at_)jlc(_dot_)net>