Bruce Lilly wrote:
the draft attempts to document a version which has apparently
been superseded.
No, that's not the case. There was an attempt to superede it
by sp2.0/mfrom published Sep 15 in draft-ietf-marid-mailfrom-00
...but let's say that three days of discussion in MARID before
it was closed were inadequate to address all issues with these
drafts.
E.g. there was never a corresponding spf2.0/helo document to
cover another feature of v=spf1. The error handling and the
processing limits in draft-ietf-marid-protocol-03 were still
incomplete, to put it mildly.
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.
Losing a proper "protocol" draft the Sender-ID (spf2.0) folks
simply adopted the latest v=spf1 drafts for this purpose, the
syntax (excl. the version string), the error handling, and the
processing limits are identical.
The semantics is of course not identical, spf2.0/pra and v=spf1
are in fact incompatible. But ignoring some details like HELO
you could say that sp2.0/mfrom is roughly the same as v=spf1.
Similar enough for compatibility.
There's only one syntactical improvement in spf2.0 that can't
be retrofitted into v=spf1, the "positional modifier" idea. So
far spf2.0 doesn't use it, that's highly theoretical (see also
chapter 3.3 in draft-lyon-senderid-core-01).
"The SPF project DOES NOT expect the IESG to review this
version.
...my personal Bruce-review-emulator also stumbled over this
point, I guess it's getting better. ;-) Telling busy people
what they might wish to ignore is somewhat besides the point.
I have copied the IESG mailing list so that the IESG can be
kept informed of the discussion
So you destroyed the intended effect. No problem, it's time
to nail the version issue, v=spf1 is not superseded by spf2.0.
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).
It took not only me some time to figure out why there's not
necessarily a "last call" for "experimental" RfCs submitted by
individuals. Anyway, this draft is long past any "experiment",
IMHO since before MARID.
Use of the word "standard" is going to cause problems
ok.: | standard dotted-quad format.
ok.: | time() function in most standards-compliant libraries.
ok.: mail header registration form | Status: standard
ok.: ipr=full3978 IETF boilerplate | this standard.
No other string "standard" in the I-D.
The MAIL FROM argument specifies a return path for
delivery-related notifications.
Already discussed on the 822 list, I quote the relevant part:
|> "reverse-path which can be used to report errors" (STD 10)
|
| Yes, it "specifies who the mail is from", "a return route (which
| may be used to return a message to the sender when an error
| occurs with a relayed message)", "contains the source mailbox",
| "a reverse source routing list of hosts and source mailbox",
| "a source route from the current location of the message to the
| originator of the message)". Finally "send it to the originator
| of the undeliverable mail (as indicated by the reverse-path)".
|
| Want more ? I skipped some less CLEAR "should", but when I said
| *_criminal negligence_* about any "bounces-to" I was NOT joking.
You pick your STD 10 cherries, I pick mine, shall we count ?
Indeed, a null path is required in some cases to prevent
damaging mail loops.
Addressed in the draft. There's also no problem with domain
literals in HELO or MAIL FROM, they don't have a sender policy.
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.
Skipping some cases where domain owners may prefer to publish
no SPF sender policy, because that's of course their decision.
As noted in some detail above, the described mechanism is
incompatible with SMTP as standardized, widely deployed, and
used for mission-critical purposes by an extremely large and
diverse community of users on the Internet
That's not the case. Domain owners wishing to use their domain
in a MAIL FROM with any IP are not forced to say "v=spf1 +all",
but of course they could if they want it. And they could also
use say "v=spf1 -exists:{ir}.comcast.blackholes.us ?all" for a
negative statement about only some IPs.
Replace DNSBLs of your choice to fight backscatter caused by
forgeries as it pleaes you. Or just ignore it if it doesn't
hit you.
Any mechanism which shares those characteristics
(favorable to spammers, harmful to legitimate users) is
doubly harmful to the email system.
Spammers are indeed the only non-volunteers in this mechanism,
it's just working as designed. They can't forge protected
addresses anymore without losing parts of their "audience".
A PASS from unknown strangers isn't "favourable", it only means
that it was not say my address abused by somebody else. If you
want more meaning for a PASS you need white or black lists -
based on addresses / FQDNs, that wasn't possible without SPF.
a scheme with so many defects
So far you found a potential flaw in the IPR boilerplate. I've
also sent an erratum about 3978 to the Rfc editor 4 weeks ago,
Bye, Frank