Network Working Group F. Ellermann
Internet-Draft xyzzy
Intended status: Experimental October 22, 2006
Expires: April 25, 2007
Sender Policy Framework: SPF Options
draft-ellermann-spf-options-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Ellermann Expires April 25, 2007 [Page 1]
Internet-Draft SPF options October 2006
Abstract
In discussions about the Sender Policy Framework (SPF) users often
want to add optional properties to their sender policies. The
modifier "match_subdomains=yes" made it into early SPF drafts. This
memo proposes a general syntax for a modifier "op=" for this purpose.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. op: options . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The optional "nohelo" property . . . . . . . . . . . . . . 5
3.2. The optional "helo" property . . . . . . . . . . . . . . . 5
3.3. The optional "pra" property . . . . . . . . . . . . . . . 6
3.4. The optional "auth" property . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Document History . . . . . . . . . . . . . . . . . . 11
A.1. spf-6-3-options . . . . . . . . . . . . . . . . . . . . . 11
A.2. spf-options . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Ellermann Expires April 25, 2007 [Page 2]
Internet-Draft SPF options October 2006
1. Introduction
The key words "MAY, "MUST", "MUST NOT", and "NOT RECOMMENDED" in this
memo are to be interpreted as described in [RFC2119]. One line of
syntax uses the ABNF defined in [RFC4234].
Readers should be familiar with [RFC2821], [RFC4409], and the SPF
terminology in [RFC4408]. See [RFC2828] for an Internet Security
Glossary.
Comments and questions should be sent to the SPF-Discuss mailing list
<http://dir.gmane.org/gmane.mail.spam.spf.discuss>.
Ellermann Expires April 25, 2007 [Page 3]
Internet-Draft SPF options October 2006
2. Motivation
The SPF community often discussed optional "yes", "no", or similar
modifiers. SPF allows the introduction of new modifiers without a
new SPF version under two conditions:
1. All SPF implementations can safely ignore the new modifier.
2. Implementations supporting the new modifier interpret all
policies without this modifier like all other conforming
implementations.
The "op" modifier is a shorthand for optional properties and "opt-in"
procedures. The length of SPF policies is limited. Instead of
separate modifiers as in...
IN SPF "v=spf1 o1=yes p2=no q3=1"
...the "op" modifier allows the shorter notation...
IN SPF "v=spf1 op=o1.nop2.q3"
...for hypothetical properties "o1", "nop2", and "q3". Please note
that a policy without one of these properties does not implicitly
have any "opposite" property. Existing sender policies and
implementations may not know these properties. They are also free to
ignore known properties intentionally.
It is possible to define a hypothetical property "p2" as the opposite
of "nop2", and to specify it explicitly in a sender policy. The
definitions could state that "p2" and "nop2" must not be used
together.
Ellermann Expires April 25, 2007 [Page 4]
Internet-Draft SPF options October 2006
3. op: options
The "op" modifier introduces a dot-separated list of optional
properties. New properties can be defined in additional documents in
the same way as new SPF modifiers.
Classic SPF modifiers are always global, they affect the complete
sender policy. At most one "op" modifier is allowed in a SPF sender
policy. It's a good idea to specify an "op" modifier before the
first directive. An ABNF specification for options:
options = "op=" name *( "." name )
Property names can be given in any order, it's no syntax error to
specify the same property more than once. The term <name> for the
names of individual properties is defined in [RFC4408].
An initial set of properties is defined below: "nohelo", "helo",
"pra", and "auth".
3.1. The optional "nohelo" property
The "nohelo" property indicates that the FQDN is never used as "HELO"
identity. SPF implementations MAY reject all mails in a SMTP session
with a SPF "Fail" result, if the sender policy determined by the
"HELO" identity specifies the "nohelo" property.
The "nohelo" property MUST NOT be used in a sender policy with a
"helo" property.
3.2. The optional "helo" property
The "helo" property indicates that the FQDN given in a HELO or EHLO
command always results in a "Pass". The SPF results "Neutral" and
"Softfail" MAY be interpreted as "Fail" for a "HELO" identity, if the
sender policy specified the "helo" property.
Note that it's still necessary to evaluate all mechanisms left to
right depth first up to the last mechanism, where a match would
result in a "Pass".
The "helo" property MUST NOT be used in a sender policy with a
"nohelo" property.
It is always better to use an FQDN exclusively for a "HELO" identity
with a sender policy, where all mechanisms result either in "Pass" or
"Fail". The "helo" property can be a workaround if an exclusive FQDN
for the "HELO" identity is unavailable.
Ellermann Expires April 25, 2007 [Page 5]
Internet-Draft SPF options October 2006
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 [RFC4407].
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 Message Submission Agents (MSAs) in
[RFC4409] 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 [RFC4409].
3.4. The optional "auth" property
The "auth" property indicates that the domain owner not only
authorizes the hosts that "Pass" the sender policy to send mail using
the domain in the "MAIL FROM" and "HELO" identities, but that the
domain owner also asserts those uses of the domain to be authentic,
i.e. not forged.
In particular, this means that any authorized hosts that are shared
with other domains are guaranteed to prevent cross-user forgery (see
[RFC4408], section 10.4). This is often the case for MSAs as defined
in [RFC4409], but many MSAs and smart hosts still allow to use any
"MAIL FROM" identity after a successful authentication.
For details about enforced submission rights see [RFC4409]. Example:
IN SPF "v=spf1 op=auth +a ?include:example.com -all"
Please note that the "auth" property has no technical effect. It is
arguably better to use a "Neutral" mechanism for any shared smart
host, and to use "Pass" only if the MSA enforces submission rights.
Ellermann Expires April 25, 2007 [Page 6]
Internet-Draft SPF options October 2006
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, Julian Mehnle, Keith Moore, Meng Weng Wong, Scott Kitterman,
Stuart D. Gathman, Wayne Schlitt, and William Leibzon.
Bill Fenner's _xml2rfc validator_ and _ABNF checker_ were a great
help in the creation of (not only) this memo.
Ellermann Expires April 25, 2007 [Page 7]
Internet-Draft SPF options October 2006
5. Security Considerations
Please consult the security considerations in [RFC4409] and
[RFC4408]. A sender policy is only a claim by the domain owner, this
can be a spammer or an attacker.
The SPF specification [RFC4408] 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.
Ellermann Expires April 25, 2007 [Page 8]
Internet-Draft SPF options October 2006
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.
Ellermann Expires April 25, 2007 [Page 9]
Internet-Draft SPF options October 2006
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
7.2. Informative References
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000.
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail
Messages", RFC 4407, April 2006.
Ellermann Expires April 25, 2007 [Page 10]
Internet-Draft SPF options October 2006
Appendix A. Document History
*This appendix should not be published in an RFC.*
A.1. spf-6-3-options
The versions 01, 02, and 03 of _draft-spf-6-3-options_ were written
in the style of a possible chapter 6.3 in [RFC4408]. The versions 02
and 03 explicitly stated that this will never happen.
Version 02 renamed the 01 properties, "helo" was "hector", "trusted"
was "meng", "rfc822" was "william", and "auth" was "scott". The
original ideas for these properties were posted and discussed on the
SPF-Discuss mailing list by various authors.
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 04 (2005-02) dropped the property "nosub" added in version
03. It could be used in an alternative to the zone cut algorithm
removing domain labels left to right until a sender policy without
"nosub" property is found. It was the opposite idea of the now long
dead "match_subdomains=yes". The actual SPF RFC removed the zone cut
algorithm, and so an alternative is now pointless.
Version 04 had an XML source, it was converted to a draft by
<http://xml.resource.org>. Versions 05 (2005-04) and 06 (2005-05)
were minor editorial updates, new BCP 78 boilerplate and similar
issues.
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.
In version 07 this document history was moved to an appendix. Non-
empty IANA considerations and acknowledgements were added.
Versions 08 (2005-07), 09 (2005-10), and 10 (2006-08) were again
editorial updates, RFC 2234bis is now [RFC4234], PRA is [RFC4407],
SPF is [RFC4408], and RFC 2476bis is now [RFC4409].
Ellermann Expires April 25, 2007 [Page 11]
Internet-Draft SPF options October 2006
A.2. spf-options
For _draft-ellermann-spf-options-00_ the last _draft-spf-6-3-options-
10_ was renamed and submitted as Internet draft (I-D). A note that
it should be not implemented before that time was removed -
apparently no additional SPF modifiers have been implemented so far.
The first revision of the I-D (version 01) got a reference to
[RFC2828] for the improved "auth" section. More acronyms are
expanded on first usage.
Ellermann Expires April 25, 2007 [Page 12]
Internet-Draft SPF options October 2006
Author's Address
Frank Ellermann
xyzzy
Hamburg, Germany
Email: nobody@xyzzy.claranet.de
URI: http://purl.net/xyzzy/
Ellermann Expires April 25, 2007 [Page 13]
Internet-Draft SPF options October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgments
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). This document was produced
using xml2rfc v1.32pre1 (of http://xml.resource.org/) from a source
in RFC-2629 XML format.
Ellermann Expires April 25, 2007 [Page 14]