Sender Policy Framework: SPF Options
draft-ellermann-spf-options-02

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 May 18, 2008.

Abstract

In discussions about the Sender Policy Framework (SPF) users often wanted 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
2.  Motivation
3.  op: options
    3.1.  The optional "pra" property
    3.2.  The optional "auth" property
4.  Acknowledgements
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Document History
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The key words "MAY, "MUST", "MUST NOT", and "NOT RECOMMENDED" in this memo are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.). One line of syntax uses the ABNF defined in [I‑D.crocker‑rfc4234bis] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2007.).

Readers should be familiar with [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.), [RFC4409] (Gellens, R. and J. Klensin, “Message Submission for Mail,” April 2006.), and the SPF terminology in [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.). See [RFC4949] (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.) 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.

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.

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.

At most one op modifier is allowed in an SPF sender policy. It is 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 is no syntax error to specify the same property more than once. The term <name> for the names of individual properties is defined in [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.).

An initial set of properties is defined below: pra, and auth.

In theory a modifier could be defined to have an effect on the evaluation of "included" policies. This is not the case for the predefined (in [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.)) modifiers exp and redirect, and op follows this role model.

In theory a modifier could be defined to have an effect on the evaluation of "continuation records" when following a redirect modifier. This is not the case for the predefined exp modifier, and op follows this role model.

3.1.  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] (Lyon, J., “Purported Responsible Address in E-Mail Messages,” April 2006.).

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] (Gellens, R. and J. Klensin, “Message Submission for Mail,” April 2006.) 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] (Resnick, P., “Internet Message Format,” April 2001.) and compare sections 6.1 and 8.1 in [RFC4409] (Gellens, R. and J. Klensin, “Message Submission for Mail,” April 2006.).

3.2.  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] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.), section 10.4). This is often the case for MSAs as defined in [RFC4409] (Gellens, R. and J. Klensin, “Message Submission for Mail,” April 2006.), 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] (Gellens, R. and J. Klensin, “Message Submission for Mail,” April 2006.). 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.

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. The same goes for various great IETF tools written by Henrik Levkowetz.

5.  Security Considerations

Please consult the security considerations in [RFC4409] (Gellens, R. and J. Klensin, “Message Submission for Mail,” April 2006.) and [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.). A sender policy is only a claim by the domain owner, this can be a spammer or an attacker.

The SPF specification [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.) 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.  References

7.1. Normative References

7.2. Informative References

Appendix A.  Document History

This appendix should not be published in an RFC.

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 [RFC4949] (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.) for the improved auth section. More acronyms are expanded on first usage.

Version 02 is a maintenance update removing the [draft-spf-6-3-options] (2004-2006) history. RFC 2828 was replaced by [RFC4949] (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.), and RFC 4234 was replaced by [I‑D.crocker‑rfc4234bis] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2007.). The popular demand for helo and nohelo options over the years was near zero, they are now removed.

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2007).

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, THE IETF TRUST 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.

Acknowledgment

This document was produced using xml2rfc v1.35 (of http://xml.resource.org/) from a source in RFC-2629 XML format.