In <200508222306(_dot_)31107(_dot_)julian(_at_)mehnle(_dot_)net> Julian Mehnle
<julian(_at_)mehnle(_dot_)net> writes:
IESG Chair Brian Carpenter,
as per the Internet Standards Process, section 6.5, and on behalf of the
You should capitalize "as" at the start of the sentence.
This means that the I-D recommends that "v=spf1" records be used for
checking the PRA identity defined in draft-lyon-senderid-pra-01[4].
However, this is in direct conflict with draft-schlitt-spf-classic-02[5],
section 2.4 "Checking Authorization", which says:
At least the "MAIL FROM" identity MUST be checked, but it is
RECOMMENDED that the "HELO" identity also be checked beforehand.
Without explicit approval of the domain owner, checking other
identities against SPF version 1 records is NOT RECOMMENDED because
there are cases that are known to give incorrect results.
This is not a direct quote from the I-D because it removes the
paragraph break and does not show the snips. I recommend:
[...] At least the "MAIL FROM" identity MUST be checked, but it
is RECOMMENDED that the "HELO" identity also be checked beforehand.
Without explicit approval of the domain owner, checking other
identities against SPF version 1 records is NOT RECOMMENDED because
there are cases that are known to give incorrect results. [...]
It will make it easier for people to find the referenced text in the I-D.
Even though the SPF specification has undergone quite some changes since
late 2003, the focus has always been on maintaining backwards compatibili-
ty and protecting the meaning of existing sender policies.
Actually, if you consider the draft-lentczner-spf-00 I-D to be an "SPF
specification", it was *not* backwards compatible in many ways.
really minor nit: I hate seeing words broken across lines like
"compatibili- ty"
* MAIL FROM signature schemes such as BATV, SES, SRS, or VERP employ
unique tokens in the MAIL FROM identity, but inherently do not change
the PRA identities. These schemes make deliberate use of the protocol
layer separation in internet mail, i.e. of the fact that the header
identities are conceptually independent from the envelope identities.
This is only a problem when the local part is referenced in the SPF
record.
* If the MAIL FROM is empty ("MAIL FROM:<>"), the MAIL FROM identity, as
defined by the SPF specification, falls back to HELO identity[5,
section 2.2], while then the PRA identity is usually unpredictable.
I'm not sure that this is a problem. I'm also having a hard time
parsing by "[...], while then the PRA [...]".
You didn't mention the Olson Objection, which I think is pretty
important.
In your appeal, you didn't mention or address any of the issues that
the IESG formally responded to us on the re-use of SPFv1 records. I
think this is a mistake and is inviting a response of "we already
address this issue in <this> reply."
http://moongroup.com/pipermail/spf-council/2005-June/000336.html
http://moongroup.com/pipermail/spf-council/2005-June/000337.html
-wayne