Network Working Group A. Newton, Editor
Internet-Draft Message Anti-Abuse Working Group
Expires: October 20, 2005 April 21, 2005
Considerations for the use of the Sender Policy Framework
draft-newton-maawg-spf-considerations-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 October 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes issues and considerations when deploying the
Sender Policy Framework for the purposes of authenticating sending
domains with Internet email.
Newton, Editor Expires October 20, 2005 [Page 1]
Internet-Draft SPF Considerations April 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SPF Background . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 SPF Variants . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Original SPF . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 SPF Classic . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Sender ID . . . . . . . . . . . . . . . . . . . . . . 5
2.2 SPF Email Identities . . . . . . . . . . . . . . . . . . . 5
3. Identity Usage . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 User Agents . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Publisher's Intent . . . . . . . . . . . . . . . . . . . . 9
4. Multihoming of Mail Servers . . . . . . . . . . . . . . . . . 10
5. Usage of Headers for Check Status . . . . . . . . . . . . . . 11
6. DNS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1 Mechansim Lookups . . . . . . . . . . . . . . . . . . . . 12
6.2 Zone Cut Issues . . . . . . . . . . . . . . . . . . . . . 12
6.3 Publication Procedures . . . . . . . . . . . . . . . . . . 13
6.3.1 Initial Publication . . . . . . . . . . . . . . . . . 13
6.3.2 Continued Publication . . . . . . . . . . . . . . . . 14
6.3.3 Use of the 'include' Mechanism . . . . . . . . . . . . 14
7. SPF Results . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1 Administrative Utility . . . . . . . . . . . . . . . . . . 15
7.2 Use of Other Authentication Schemes . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Newton, Editor Expires October 20, 2005 [Page 2]
Internet-Draft SPF Considerations April 2005
1. Introduction
The Sender Policy Framework (SPF) describes a DNS TXT resource record
to be used for authenticating the sending domain in the transmission
of Internet email (from one domain to another). SPF sits atop the
current email standards and is intended to disallow certain abusive
use cases of email. To accomplish this task, SPF places new
restrictions upon the email transmission from one domain to another.
This document describes issues and considerations regarding the use
of SPF that network and mail administrators may have no need to
consider otherwise.
These considerations are collected from the membership of the Message
Anti-Abuse Working Group. This document is intended to be for
informational purposes only.
Newton, Editor Expires October 20, 2005 [Page 3]
Internet-Draft SPF Considerations April 2005
2. SPF Background
The Sender Policy Framework is an email sender authentication scheme
that defines a syntax of a DNS TXT resource record. Through various
devices, this DNS TXT resource record lists allowed, disallowed,
neutral, and unknown source IP addresses. SPF relies upon the
difficulty of spoofing IP addresses with SMTP connections as the
basis for its authentication mechanism; senders are matched to the
source IP address of an SMTP connection via various identities.
Authorization to use the IP address by a sender is given in the DNS
TXT resource record.
2.1 SPF Variants
SPF describes itself as a framework, and as such there are many
variants of SPF. When deploying SPF, it is crucial to understand
which variants of SPF are being advertised as a sender of email and
the intentions of the sending SPF domain as a receiver of email.
Otherwise, it is likely that non-forged email may not be delivered
while forged email may be delivered. The following is a partial list
of SPF variants.
2.1.1 Original SPF
The specification in [1] (and its immediate predessor) was the first
specification considered to contain the basis of SPF. This
specification uses the email address presented by a sending server in
the SMTP MAIL FROM command or the fully qualified domain name
presented by a sending server in the SMTP HELO or EHLO command if no
email address is given in the MAIL FROM command. It should be noted
that this specification is no longer being advanced through
standardization processes by its authors. However, it is important
because many implementations cite it as the specification to which
they comply.
2.1.2 SPF Classic
There exists some ambiguity regarding the term "Classic SPF" or "SPF
Classic" as it was originally used to distinquish original SPF
(Section 2.1.1) from a variant of SPF known as Sender ID (Section
2.1.3). However, the more recent use of the term "SPF Classic"
refers to [5]. This specification differs from original SPF (Section
2.1.1) in the following ways:
o DNS lookups that fail to find TXT records will use an algorithm to
find DNS zone cuts and requery the DNS further up the tree.
o Checking of the fully qualified domain name given in an SMTP HELO
or EHLO command is optional even if an address is given in the
SMTP MAIL FROM command.
Newton, Editor Expires October 20, 2005 [Page 4]
Internet-Draft SPF Considerations April 2005
2.1.3 Sender ID
This variant of SPF is defined by [2] , [3] and [4]. It differs from
the above specifications in the following ways:
o The email identity used is determined by the publisher of the SPF
record.
o It defines a new email identity that is selected from the headers
of the email message using an algorithm called the Purported
Responsible Address (PRA).
o The syntax of the record can either be the SPF syntax specified by
original SPF (Section 2.1.1) (identified by the "v=spf1" version
identifier) or a slightly different SPF syntax (identified by the
"spf2.0" identifier).
o The email address selected by the PRA algorithm can be transmitted
by the sender to the receiver in the SMTP MAIL FROM command using
an ESMTP extension called SUBMITTER.
It should be noted that some proponents of SPF Classic (Section
2.1.2) do not consider Sender ID (Section 2.1.3) to be a legitimate
variant of SPF. This may cause confusion when determining the
compliance of software.
2.2 SPF Email Identities
All SPF variants use a domain name to lookup an SPF DNS TXT resource
record. These domain names are taken from different parts of the
SMTP transaction as email is transmitted from one mail server to
another.
The following is an example of an SMTP transaction. The first two
columns are provided for illustrative reasons and are not part of the
SMTP transaction. The first column is a line number, and the second
column contains an "S:" or "C:" to show who said what in the SMTP
conversation. Lines with an "S:" (for server) indicate the mail
server receiving the email, and lines with a "C:" (for client)
indicate the mail server sending the email.
Newton, Editor Expires October 20, 2005 [Page 5]
Internet-Draft SPF Considerations April 2005
1 S: 220 milo.example.org SuperDuper Mail Server v1.5
2 C: HELO felix.example.net
3 S: 250 milo.example.org Ok.
4 C: MAIL FROM: <bob@example.com>
5 S: 250 Ok.
6 C: RCPT TO: <alice@example.org>
7 S: 250 Ok.
8 C: DATA
9 S: 354 Ok.
10 C: Subject: This is an example email
11 C: From: Bob <bob@example.net>
12 C: To: Alice <alice@example.com>
13 C:
14 C: This is the body of the email message.
15 C: It is two lines long.
16 C: .
17 S: 250 Ok. 42548455.00000B74
Figure 1: An Example SMTP Transaction
The domain name given on line 2 (felix.example.net) of the SMTP
transaction is the HELO identity, and it is suppose to be the fully
qualified domain name of the mail server sending the email. Original
SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) specify that an
SPF DNS TXT resource record by that name is to be consulted to
determine if the source IP address of the SMTP connection is
authorized to act on behalf of the HELO identity.
The domain name of the email address in Line 4 (example.com) is the
MAIL FROM identity used by original SPF (Section 2.1.1) and SPF
Classic (Section 2.1.2) An SPF DNS TXT resource record by that name
is to be consulted to determine if the source IP address of the SMTP
connection is authorized to act on behalf of the MAIL FROM identity.
Lines 10 through 12 are the headers of the email message. The PRA
algorithm selects an identity from these headers. In this example,
the PRA specifies the email address in Line 11 and the use of the
domain name in that email address (example.net) as the Purported
Responsible Domain (PRD). An SPF DNS TXT resource record by that
name is to be consulted to determine if the source IP address of the
SMTP connection is authorized to act on behalf of the PRA identity.
See [3].
Newton, Editor Expires October 20, 2005 [Page 6]
Internet-Draft SPF Considerations April 2005
3. Identity Usage
Proper deployment of SPF requires an understanding of the proper
usages of identities used in the tranmission of email from one mail
server to another. Improper deployment of SPF may result in
inappropriately high confidence of protection against certain classes
of mail forgery or may result in the loss of certain types of message
transfers or both.
3.1 User Agents
Given the example in Figure 1, the following is typical of what will
be seen by an end-user with a mail client.
Subject: This is an example email
From: Bob <bob@example.net>
To: Alice <alice@example.com>
Date: Wed, 06 Apr 2005 20:52:11 -0400
This is the body of the email message.
It is two lines long.
Figure 2: User Agent Example
The identity used with the SMTP MAIL FROM command is bob@example.com
but the end-user sees the message as being from bob@example.net (note
the difference between example.com and example.net). Therefore,
SPF's use of the identity in the SMTP MAIL FROM command will not stop
users from seeing a forged identity.
Since the PRA is the only identity verified that is part of the email
message, verification of the PRA is the only part of SPF that
attempts to insure that end-users see authorized email addresses.
However, the PRA algorithm does not always select an identity that is
shown to end users by mail clients. Therefore, SPF is not guaranteed
to prevent end users from seeing forged identities.
Additionally, the PRA identity only focuses on the address
specification part of a header in an email message. It does not
validate against the display name part of a header in an email
message. Using the example above:
From: Bob <bob@example.net>
The display name portion in this header is "Bob" and the address
specification portion in this header is "<bob@example.net>. Many
email clients show only the display name portion of the header.
Therefore, it is possible to have a positive validation against the
PRA without having a positive validation against the information
given to the user. For example:
Newton, Editor Expires October 20, 2005 [Page 7]
Internet-Draft SPF Considerations April 2005
From: Bob Smurd <badguy@example.net>
would be seen as:
From: Bob Smurd
yet yield a positive result.
3.2 Forwarding
Forwarding of email from one mail server to another may prevent
proper delivery of messages using the MAIL FROM and PRA identities.
Consider the following email forwarding scenario.
+----------------------+
| |
| felix.example.net |
| |
+----------------------+
|
(1) | MAIL FROM: <george@example.net>
|
V
+----------------------+ +----------------------+
| | (2) | |
| milo.example.org |------------------------->| calvin.example.com |
| | MAIL FROM: | |
+----------------------+ <george@example.net> +----------------------+
Figure 3: Mail Path Example
In this scenario, MAIL FROM checking from felix.example.net to
milo.example.org would produce valid results. However, a MAIL FROM
check from milo.example.org to calvin.example.com would produce
invalid results as george@example.net would cause the SPF record for
example.net to be consulted even though the SMTP connection is
originating from example.org.
While the intent of PRA algorithm is to properly detect the last
forwarder of an email, it relies upon behaviors not found in all mail
servers and programs. Therefore, it is quite possible that PRA
checking would also have the same results as MAIL FROM checking.
For mail services with a small and fixed number of known forwarding
relationships, this problem may be overcome using the include
mechanism. In this case, "include:example.org" placed in the SPF
record of example.net would produce proper results. However, there
are some drawbacks to using the "include" mechanism (see Section
6.3.3).
However, it is not always possible to know forwarding relationships
Newton, Editor Expires October 20, 2005 [Page 8]
Internet-Draft SPF Considerations April 2005
or to produce SPF include mechanisms for all known forwarding
relationships. To overcome this problem, it is advisable to do the
following:
o For MAIL FROM checking, rewriting the MAIL FROM identity to point
to the domain of the sending server will cause the proper SPF
records to be consulted. In the example above, if the server
milo.example.org used a MAIL FROM identity of george@example.org
instead of george@example.net, then the records pertaining to
milo.example.org would be consulted. It is important to note that
all upstream notifications are to be directed to the MAIL FROM
identity, therefore MAIL FROM rewriting will require
milo.example.org to properly handle any bounces of the message it
is sending.
o To use PRA checking, a forwarder should insert the proper PRA
compatible header or headers into the message. See [3].
Note that the HELO identity will not cause false positives with
forwarding. As noted above, the MAIL FROM identity is used as the
address to which bounces should be sent in case of errors, and many
forwarding processes legitimately do not rewrite MAIL FROM for this
reason. However, such a reason does not exist for the HELO identity
and there are no legitimate reasons for a mail server to use the
identity of another.
3.3 Publisher's Intent
As noted in Section 3.2, to prevent the consultation of inappropriate
SPF records, senders may adopt strategies of rewriting MAIL FROM or
inserting PRA compliant headers or both. The strategy picked should
be reflected in the SPF record, and therefore receivers of email
should follow the intent of the published SPF record regarding which
identity is to be checked.
With the given SPF variants (Section 2.1), there are three types of
SPF records that give scope to the identifier to be checked.
1. v=spf1
2. spf2.0/mfrom
3. spf2.0/pra
For the purposes of backwards compatibility, Sender ID (Section
2.1.3) interprets the first record to be equivalent to "spf2.0/
mfrom,pra", which is to say that both MAIL FROM and PRA checks are to
occur. To avoid confusion, senders should explicitly publish spf2.0/
mfrom records. If a sender has not taken prepatory steps to
accomodate PRA checking, a non-committal SPF record of "spf2.0/mfrom
?all" will signal that all PRA checking against this domain will have
unknown results.
Newton, Editor Expires October 20, 2005 [Page 9]
Internet-Draft SPF Considerations April 2005
4. Multihoming of Mail Servers
Because SPF uses IP addresses as the key to authentication, special
care must be given with mail servers that have more than one IP
address, especially if they are not all listed in the SPF record.
Here is one such common scenario: a separate publicly addressable
network interface is given to a server for the sole purpose of remote
management. In these cases, changes to the routing fabric of the
Internet may cause mail service to switch away from the intended
network interface to one not intended to service SMTP traffic.
To avoid this problem, mail servers should be explicitly bound to the
network interfaces published in the SPF records.
Newton, Editor Expires October 20, 2005 [Page 10]
Internet-Draft SPF Considerations April 2005
5. Usage of Headers for Check Status
Original SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) defines
the Received-SPF trace header to be added to email messages that have
undergone SPF checking. Because these are trace headers, multiple
sets of Received-SPF headers may appear in a single email, each set
being added by a previous mail hop. Without proper care, simple
filtering (such as with an unscoped regular expression) may have
unexpected results. And like Recieved headers, Received-SPF headers
are an easy target for forgery. Mail filters and clients should not
use their contents to determine the disposition of email messages.
Because SPF is not the only type of email authentication in use, mail
servers should use the Authentication-Results header (See [6]). This
header has the advantage of working with multiple authentication
schemes and is intended to allow a mail server to communicate the
status of an authentication check to mail filters and mail clients.
Newton, Editor Expires October 20, 2005 [Page 11]
Internet-Draft SPF Considerations April 2005
6. DNS Usage
6.1 Mechansim Lookups
Network administrators need to be conscious of the fact that SPF
records can create more load on their DNS servers than just that of
querying the SPF records.
SPF Classic (Section 2.1.2), which has the most strict upper bounds
on DNS lookups, allows for 10 SPF mechanisms that may trigger
subsequent DNS lookups. In turn each mechanism may require more than
one DNS lookup to fulfill the requirements of the mechanism. The
theoretical maximum to conduct an SPF check is 111 DNS lookups. For
instance, the appearance of one "mx" mechanism in an SPF record could
result in 10 DNS lookups in the process of following the targets of
the queried DNS MX records.
To avoid lengthy processing times and excess load on DNS, the use of
the "ip4" and "ip6" mechanisms is recommended. Use of the "include",
"a", "mx", "ptr", "exists" mechanisms, the "redirect" modifier, and
the %{p} macro should carefully consider the total number of DNS
lookups incorporated into an SPF record.
Additionally, SPF Classic (Section 2.1.2) places an upper bound of 20
seconds on the duration needed to process the SPF check. SPF checks
that take longer than 20 seconds or require more than 101 DNS lookups
will result in message delivery rejection. Use of an SPF profiler is
recommended to determine the number of DNS lookups and the potential
check duration.
These restrictions also need to be taken into consideration when
performing SPF checks. While 111 DNS lookups with a 20 second
timeout is tolerable for infrequent email reception, receivers and
senders may need to reach bilateral transaction agreements that
bypass SPF in cases where SPF records cannot be formulated with more
tolerable values.
6.2 Zone Cut Issues
SPF Classic (Section 2.1.2) introduces an algorithm to find the DNS
zone cut of administrative domains. For example, if an SPF check is
conducted against a non-existent domain name of prattle.example.net,
the SPF record at example.net will be found. This algorithm is an
attempt to overcome undesirable behaviour in DNS wildcards (which are
not recommended for use by SPF Classic).
This algorithm has implications with regards to the confidence
attached to HELO checking. Should a misconfiguration occur, a HELO
Newton, Editor Expires October 20, 2005 [Page 12]
Internet-Draft SPF Considerations April 2005
check may inadvertently consult the wrong SPF record. Because SPF
records related to HELO can be stricter than SPF records relating to
MAIL FROM and PRA, this would result in the loss of security.
Synthesized DNS records, whether provided by the standard DNS
wildcard device or other means, are an administrative issue. Other
methods can be employed to get the proper DNS behaviour by the
publisher of an SPF record.
Therefore, disabling the DNS zone cut algorithm in an SPF processor
is recommended.
6.3 Publication Procedures
6.3.1 Initial Publication
Because there are many unknowns in the paths email messages may take
through the Internet, many publishers of SPF records make
non-committal assertions regarding their message delivery (usually by
ending an SPF record with "~all"). To a receiver, a non-committal
assertion may not have any affect on judging the disposition of
email, and issues with regard to SPF processing may not be noticed
until a more aggressive SPF record is published.
SPF publishers should follow these steps on initial publication of an
SPF record:
1. Initially publish the SPF record with a neutral assertion (i.e.
end it in "?all").
2. Once there is a high degree of confidence that the SPF record
accurately reflects message delivery, lower the TTL on the SPF
record to a value that allows the record to be quickly propagated
within the DNS should it need to be changed rapidly.
3. Change the SPF record so that it makes the more aggressive
assertion of softfail (i.e. end it in "~all").
4. If no adverse problems are found after a sufficient period of
time, change the SPF record so that it makes the most aggressive
assertion (i.e. end it in "-all").
5. Once there is a high degree of confidence that the SPF record is
not causing adverse mail delivery problems, increase the TTL on
the SPF record to a more reasonable value.
It should be noted that decreasing the TTL on the SPF record will
result in higher DNS query load.
Due to unknowable forwarding relationships with the Internet email
infrastructure, it may not be possible for all domains to publish SPF
records with an agressive assertion. Use of these publication
procedures may even lead to the conclusion that email should not be
Newton, Editor Expires October 20, 2005 [Page 13]
Internet-Draft SPF Considerations April 2005
subjected to SPF checks (see Section 7.2).
6.3.2 Continued Publication
Once an SPF record has been established, a publisher should put in
place proper procedures for the maintenance and continued publication
of the SPF record.
Over time, it is highly likely that some changes will need to be made
to the contents of the SPF record. Because the SPF syntax is
seemingly simple, administrators may be tempted to modify the record
without full knowledge of the SPF syntax. Failure to correctly
modify an SPF record may result in message delivery rejections. To
avoid this problem, any SPF record should be run against an SPF
syntax checker before the new record is published.
Additionally, it might be useful to store SPF records in a version
control system. This allows quick reversion back to a previous
record should a problem be discovered. It will also help in the
analysis of mail problems by allowing past records to be studied.
6.3.3 Use of the 'include' Mechanism
As stated in Section 2.1, many implementations of SPF adhere to
original SPF (Section 2.1.1) even though that current branch of SPF
is described by SPF Classic (Section 2.1.2). Unfortunately, both use
the same "v=spf1" record identifier, so there exists no easy method
to differentiante the two programmatically.
Both versions differ substantially in their error case for the
"include" mechanism. Under original SPF (Section 2.1.1), if an
"include" mechanism references a non-existent SPF record, SPF
processing against all email for the domain making the reference
would cease (essentially resulting in a state equivalent to having no
SPF record for the domain making the reference).
Under SPF Classic (Section 2.1.2), if an "include" mechansim
references a non-existent SPF record, SPF processing against all
email for the domain making the reference would result in a PermError
state and consequent permanent SMTP rejection of the email.
For SPF publishers defering to the SPF records of other domains (a
common scenario for commercial enterprises that out-source their
transaction email operations), the existance of the target SPF record
should be verified before the use of an associated "include"
mechanism. Additionally, SPF publishers should seek assurance of
continued SPF publication from the SPF publishers to which they make
a reference.
Newton, Editor Expires October 20, 2005 [Page 14]
Internet-Draft SPF Considerations April 2005
7. SPF Results
7.1 Administrative Utility
SPF recognizes five states with which a publisher can declare their
intentional use of SPF: none, pass, fail, neutral, and softfail
(PermError and TempError as defined by SPF Classic (Section 2.1.2)
are error states and not intential usage states). The differences
between none, neutral, and softfail may not be programattically
meaningful ([5] specifies neutral to be programmatically equivalent
to none).
However, these differences can have meaning to administrators
attempting to resolve problems manually. The result of neutral
differs from the result of none in that it does indicate that the SPF
publisher is aware of SPF checking. The result of none indicates
that the SPF publisher is not aware of SPF checking.
7.2 Use of Other Authentication Schemes
There do exist scenarios where mail administrators do not wish to
subject their email practices to SPF checks but do wish to offer an
affirmative acknowledgment of the practice of using SPF. Such a
scenario would be email sending domains that wish to rely on other
authentication schemes, such as cryptographic-based signature
schemes.
This is easily accomplished with the exclusive use of the "all"
mechanism using the pass result. Such as:
v=spf1 +all
or
spf2.0/mfrom,pra +all
Newton, Editor Expires October 20, 2005 [Page 15]
Internet-Draft SPF Considerations April 2005
8. Security Considerations
SPF depends on the integrity of various parts of Internet
infrastructure and has other security considerations that should be
understand before the deployment of SPF. Sender ID (Section 2.1.3)
clearly enumerates these isses which have implications for all
variants of SPF.
Briefly, these issues are:
1. SPF is only as secure as DNS. Should the integrity of DNS be
compromised, then SPF becomes much less effective.
2. SPF relies on the difficult nature of IP address spoofing within
TCP (the transport used by SMTP).
3. SPF does not always prevent users from seeing forged sender
information even when SPF checks return positive results (see
Section 3.1).
4. SPF relies upon the linkage between an SPF publisher and their
assocation to IP address space. Attacks against the routing
fabric of the Internet can break this linkage rendering SPF
ineffective.
5. SPF may be used to perpetrate "bounce attacks". While original
SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) are less
likely to be used for such an attack, they are not immune to it
given their described usage of SoftFail.
9 Informative References
[1] Lentczner, M., "Sender Policy Framework (SPF) A Convention to
Describe Hosts Authorized to Send SMTP Traffic",
draft-mengwong-spf-01 (work in progress), May 2004.
[2] Lyon, J., "Sender ID: Authenticating E-Mail",
draft-lyon-senderid-core-00 (work in progress), November 2004.
[3] Lyon, J., "Purported Responsible Address in E-Mail Messages",
draft-lyon-senderid-pra-00 (work in progress), November 2004.
[4] Allman, E., "SMTP Service Extension for Indicating the
Responsible Submitter of an E-mail Message",
draft-katz-submitter-00 (work in progress), November 2004.
[5] Wong, M., "Sender Policy Framework: Authorizing Use of Domains
in E-MAIL", draft-schlitt-spf-classic-00 (work in progress),
January 2005.
[6] Kucherawy, M., "Message Header for Indicating Sender
Authentication Status", draft-kucherawy-sender-auth-header-01
(work in progress), March 2005.
Newton, Editor Expires October 20, 2005 [Page 16]
Internet-Draft SPF Considerations April 2005
Author's Address
Andrew L. Newton
Message Anti-Abuse Working Group
EMail: anewton@verisignlabs.com; andy@hxr.us
URI: http://www.maawg.org/
Newton, Editor Expires October 20, 2005 [Page 17]
Internet-Draft SPF Considerations April 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Newton, Editor Expires October 20, 2005 [Page 18]