Hi, I've updated draft-spf-6-3-options, as always available as:
<http://purl.net/xyzzy/home/test/draft-spf-6-3-options-07.txt>
<http://purl.net/xyzzy/home/test/draft-spf-6-3-options-07.xml>
The removal of op=trusted was discussed here, and the addition
of op=pra (again) is also a consequence of recent discussions
triggered by recent "events".
Except from minor editorial changes the new sections are listed
below, bye, Frank
3. op: options
[...]
An initial set of properties is defined below: "nohelo", "helo",
"pra", and "auth".
[...]
3.3 The optional "pra" property
The "pra" property indicates that the sender policy MAY be also
evaluated for the "PRA" identity also known as "Purported Responsible
Address" and defined in [I-D.lyon-senderid-pra].
Please note that many cases exist, where the "PRA" identity differs
from the "MAIL FROM" identity, and that classic SPF sender policies
are generally not designed to work with the "PRA" identity.
Enforced submission rights for MSAs in [I-D.gellens-submit-bis] do
not guarantee a match of any address in the 2822-From header field
with the "MAIL FROM" identity, and they also do not guarantee the
presence of a matching 2822-Sender header field. For more details
about these problems see [RFC2822] and compare sections 6.1 and 8.1
in [I-D.gellens-submit-bis].
[...]
4. Acknowledgements
Many persons on the SPF-Discuss mailing list contributed to the ideas
published in this memo. Special thanks for this and completely
different reasons to April Lorenzen, Bruce Lilly, Chris Hayes, Hector
Santos, John Levine, Keith Moore, Meng Weng Wong, Scott Kitterman,
Stuart D. Gathman, Wayne Schlitt, and Wllliam Leibzon.
The online version of _xml2rfc_ at <http://xml.resource.org> as well
as Bill Fenner's _xml2rfc validator_ and _ABNF checker_ were a great
help in the creation of (not only) this memo.
[...]
5. Security Considerations
[...]
The SPF specification [I-D.schlitt-spf-classic] explains why checking
other identities except from the "HELO" and "MAIL FROM" identities
against SPF version 1 records is NOT RECOMMENDED without explicit
approval of the domain owner.
While the "pra" property offers a way for this explicit approval in
the case of a "PRA" identity, it does not solve any of the underlying
technical problems with this approach. Receivers should treat all
PRA-results with utmost care.
[...]
6. IANA Considerations
The creation of a IANA registry for additional SPF modifiers not
limited to "op=" and/or for additional properties might be desirable
in the future, but at this time it's unnecessary.
[...]
7.2 Informative References
[...]
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[I-D.lyon-senderid-pra]
Lyon, J., "Purported Responsible Address in E-Mail
Messages", draft-lyon-senderid-pra-01 (work in progress),
May 2005.
[...]
Appendix A. Document History
[...]
Version 03 (2004-12) dropped the properties "rfc822" and "pra", at
this time there was no much interest to emulate the effect of a
"spf2.0/mfrom,pra" policy with a "v=spf1 op=pra" construct. With SPF
and PRA approved as experimental RFCs this concept attracted some
attention on the SPF mailing lists, and so it was added again in
version 07 of this memo.
[...]
Version 07 (2005-06) dropped the "trusted" property. The consensus
on the SPF-Discuss mailing list is apparently that white-listing of
trusted forwarders should be solved without the help of these
forwarders. A temporary solution like
<http://www.trusted-forwarder.org/>. could be replaced by per-user
schemes like VarA discussed in
<http://wiki.outboundindex.net/VaraIdeaConception>.
In version 07 this document history was moved to an appendix, it
should be removed before publishing it in another document series
(e.g. as RFC). Non-empty IANA considerations and acknowledgements
were added.