John Glube wrote in spf-discuss:
The notes from the IESG evaluation can be found here:
<http://tinyurl.com/4z5qq>
[...]
"Checking other identities against SPF records is NOT
RECOMMENDED because there are cases that are known to
give incorrect results."
The IESG suggested this sentence read:
"Checking other identities against SPF records is not
defined in this document."
That's a bad proposal, but in fact the original sentence could
be clearer:
| "Other identities MUST NOT be checked against v=spf1 records,
| this can have misleading or unintended results."
A similar statement could then also be added to the "security
considerations":
| "Checking other identities than MAIL FROM or HELO against
| v=spf1 records can have misleading or unintended results."
* What other issues if any are outstanding before
draft-schlitt-spf-classic-00.txt can move forward for last
call and then adoption as an experimental proposal?
AFAIK most issues with an IESG "Discuss" ballot will be fixed
in draft -01: IANA considerations for the Received-SPF header
field (RfC 3864), and removal of the "zone cut" everywhere.
AFAIK there won't be any "last call", we're on an AD-sponsored
path without "last call". I'm very unsure about this point,
please correct me if I'm wrong:
1 - either an experimental RfC is the product of an IETF WG,
then it goes through the normal "last call" procedure like
RfCs on standards track.
2 - or an experimental RfC is an individual submission, then it
gets no "last call". Unless the IESG decides to change the
status to something on standards track.
So far SPF (v=spf1) is apparently case 2 => no "last call".
* Since draft schlitt-spf-classic-00.txt is an experimental
proposal
AFAIK that was the idea of the A-D (Ted) after the collapse of
MARID. Manoeuvres in the dark, MARID never really discussed
2821-schemes like RMX, SPF, or CSV. They only discussed the
2822-schemes Caller-ID, Sender-ID, and spf2.0/pra.
The only "consensus" of MARID, if there was any consensus, was
the identification of spf2.0/mfrom, it's incompatible with PRA.
Exactly this one and only "MARID consensus" (or my imagination
of a consensus) is reflected in the cited section 2.4.
Removing it or replacing it by a dummy "undefined" is therefore
no option. I hope that the SPF Council discusses this point
with the RfC Editor, who proposed this modification, and that
an SPF draft -01 is soon published.
Bye, Frank
Posted in spf-discuss and mailed to
csm AT moongroup.com (Chairman, SPF Council)
wayne AT schlitt.net (draft editor, SPF Council)
rfc-editor AT rfc-editor.org (for info)