Internet Draft Mark Lentczner draft-ietf-mengwong-marid-unified-00.txt Meng Weng Wong, pobox.com Expires: September 2004 July 7, 2004 Sender Policy Framework (SPF) A Unified Approach to Host Authorization in SMTP Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire in September 2004. Abstract This document introduces the Unified SPF series. It describes the overall structure of the SPF system and how it is used. It specifies the interaction between tests against different identities. Unified SPF represents a refactoring of the MARID-CORE document into a general theory of MTA authentication in DNS. It supports all the requirements implicit in the input documents using a single syntax and evaluation model. It offers a superset of the functionality described by SenderID and by CSV. Table of Contents TOC GOES HERE 1. Introduction The current e-mail infrastructure has the property that any host injecting mail into the mail system can identify itself as any domain name it wants. Hosts can do this at a variety of levels (in particular, the session, the envelope, and the mail headers.) While this feature is desirable in some circumstances, it is a major obstacle to reducing end-user unwanted e-mail (or "spam"). Furthermore, many domain name holders are understandably concerned about the ease with which other entities may make use of their domain names, often with intent to impersonate. SPF is a protocol that adds host authentication between domain name holders and mail receivers. SPF compliant Domain name holders publish statements about which hosts are permitted to use their names for mail purposes, SPF compliant Mail receivers use the published statements to test identities claimed by hosts during a mail transaction. An additional benefit to mail receivers is that when the use of an identity is verified, then local policy decisions about the mail can be made on the basis of the identity, rather than the host. This advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses. On the other hand, if all claimed identities fail verification, then local policy can take stronger action against such e-mail. Note: SPF is purely voluntary: If a domain name holder does not wish to implement SPF, then their mail will be treated just as it is now. If a mail receiver doesn't perform SPF checks, then they will handle mail just as before. It is our belief that the benefits of SPF are great enough, and the implementation of SPF easy enough, that most mail participants will choose to implement it. 1.1 The SPF Documents While the operation of SPF is fairly simple, the documentation has been split into several documents. This is partially historical, as there has been a tremendous amount of community input to reach this point, and partially because the nature of fitting such a system into the existing infrastructure requires careful explanation. [SPF Unified] - this document The overall framework, basic concepts and operation, and conformance requirements. Aimed at all people. [SPF Protocol] The details of the published record format, and the spf_test() function. Intended primarily for software implementors. [SPF PTR], [SPF HELO], [SPF MAIL-FROM], [SPF PRA] These four documents describe tests that may be used by mail receivers to test specific identities used during mail transfer. Defines the semantics of what is being tested, and thus how the published records are used. [SPF Best Practices] Provides guidelines for publishing, testing and local policy. Includes example published records and working, practical local policies. Non-normative, but suggested reading for domain name holders and mail receivers. [SPF Rationale] A detailed write-up on the place of SPF in the e-mail infrastructure and arguments behind the design decisions in SPF. Non-normative and not required reading. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Related Proposals Unified SPF builds upon many proposals and a large body of community discussion that have taken place in the last two years. The authors have drawn on the efforts, wisdom, and input from dozens of proposals and hundreds of individuals. 2. Sending Mail When a piece of mail in injected into the mail stream, there are several identities that are associated with it: 1- The identity of the host injecting the mail 2- The identity of the organization responsible for the mail stream 3- The identity of the sender on the "envelope" 4- The identity of the sender(s) within in the message headers Since whoever controls the injecting host has complete control over these four identities, and for the last three can choose any identity whatsoever, it is easy for people to maliciously impersonate other identities. For example, it is trivial for any rogue machine on the internet to send mail that claims to be written by "president@whitehouse.gov" and uses that identity throughout the mail transaction. 2.1 SPF Records Through SPF records, domain name owners can publish which hosts are allowed to use the domain name as an identity when transferring mail. For example, if the domain "example.com" published this SPF record: v=spf1 +ip4:10.0.30.0/24 -all it would be saying that it only permits hosts in the IP network 10.0.30.0/24 to use the identity "example.com" for sending mail. Any other host claiming that identity is not doing so with the blessing of "example.com". SPF records have a syntax that makes it especially convenient to declare which hosts are permitted based on other DNS information that is generally already existent for domains: For example, if the domain "example.com" instead published this SPF record: v=spf1 +mx +a:webfarm.example.com -all it says that any host listed as an MX for example.com, and any host that is in the webfarm.example.com domain, and no others are authorized to use the "example.com" identity. These records are published as DNS TXT records at the domain name they apply to. In a Bind style master host file, the second example would appear: example.com. IN TXT "v=spf1 +mx +a:webfarm.example.com -all" See [SPF Protocol] for the full definition of the SPF record format and publishing details. 2.2 Identity Scopes The four identities listed above are more formally called scopes in SPF and are defined as: 1- PTR - the reverse DNS name of the host that contacts a SMTP server; responsible for the STMP session 2- HELO - the name given in a SMTP HELO or EHLO command; responsible for mail with empty mailboxes ("<>") 3- MAIL-FROM - the domain portion of the mailbox given in the SMTP MAIL command; responsible for receiving bounce notices 4- PRA - the domain portion of the mailbox deemed the "responsible sender" by the PRA algorithm from the mail message headers; who the final recipient would generally reply to if they had concerns about the message SPF includes tests for these four identities. While mail receivers may make fewer than all four of these tests, domain name owners that publish SPF records must be prepared for all four tests. They must determine which hosts are allowed to use their domain names in each scope. The syntax of SPF records makes the common cases very easy to express (where the answers are the same for all scopes), but can accommodate more complex schemes. 2.2.1 Common Example A common case is where a domain sends and receives mail from a small number of mail servers under its control. For example, assume that example.com has two mail servers, mx1.example.com and mx2.example.com. If example.com only uses these two servers to send mail, then only those two servers should be authorized to use example.com as a MAIL-FROM and PRA identity. Thus, for the domain name "example.com", it publishes: v=spf1 +mx -all Most servers use their own hostnames in the HELO command. The two mx1 and mx2 servers do. SPF can explicitly indicate that they are authorized to use their names mx1.example.com and mx2.example.com in HELO. The domain names "mx1.example.com" and "mx2.example.com" would publish: v=spf1 +a -all If using Bind to serve DNS, example.com's master host file would include: example.com. IN TXT "v=spf1 +mx -all" IN MX 10 mx1.example.com. IN MX 10 mx2.example.com. mx1.example.com. IN TXT "v=spf1 +a -all" mx2.example.com. IN TXT "v=spf1 +a -all" This style of SPF records works for a large portion of domains that serve their own mail. Note that these records authorize two mail servers to use "example.com" as a PTR or HELO identity, even though they don't, and to use their own domain names as MAIL-FROM and PRA identities (which they might depending on how their mail software is configured.) This is not harmful since these machines are under administrative control by example.com (or entities they trust with their mail). This is an important point: Publishing records that permit your own machines to use your domain names in all four scopes, even when they do not, is not detrimental. It is only when your records authorize machines you do not control that you may need to make distinctions between scopes. 2.2.2 Distinguishing Scopes In some cases, a domain name holder may wish to permit an administratively independent entity to use its domain name for sending mail. If the domain name holder wishes to limit the other entity's authorization by scope, this can be achieved with the redirect and macro facilities of SPF. Continuing the example above, if example.com uses outsource.com to send its bulk mail, and wants to authorize their machines to send mail with the example.com name in MAIL-FROM and PRA contexts, it would change its records thus: example.com. IN TXT "v=spf1 +mx redirect=%{e}._spf.example.com" IN MX 10 mx1.example.com. IN MX 10 mx2.example.com. mx1.example.com. IN TXT "v=spf1 +a -all" mx2.example.com. IN TXT "v=spf1 +a -all" ptr._spf.example.com IN TXT "v=spf1 -all" helo._spf.example.com IN TXT "v=spf1 -all" mail-from._spf.example.com IN TXT "v=spf1 +a:outsource.com -all" pra._spf.example.com IN TXT "v=spf1 +a:outsource.com -all" We note that while this is possible, it many cases, authorizing another entity to use a domain name in MAIL-FROM or PRA indicates a level of trust that is extremely high, and as such, trusting such an entity to use or not use the name in HELO should easily be covered. Hence, example.com can publish the easier, though slightly more liberal SPF records: example.com. IN TXT "v=spf1 +mx +a:outsource.com -all" IN MX 10 mx1.example.com. IN MX 10 mx2.example.com. mx1.example.com. IN TXT "v=spf1 +a -all" mx2.example.com. IN TXT "v=spf1 +a -all" >>> Waiting for someone to come up with a good motivating example Suppose example.com finds that spammers are frequently forging its name in SMTP. Suppose its name is forged in both the HELO command and the MAIL FROM command. Suppose example.com is unwilling or unable to limit the use of example.com in MAIL FROM, but does want to limit abuse in HELO. Example.com would therefore like to permit the following: HELO somehost.net MAIL FROM: but prohibit the following: HELO example.com MAIL FROM: The %{e} macro (or the %{l} macro, which expands to "postmaster") can be used to distinguish the above scenarios. 3. Receiving Mail When a piece of mail is received, there are several identities that are associated with the transaction (see section 2). By testing if the sending host is permitted to use those identities, the receiving mail server can implement a stronger local mail policy, which in turn will allow it to reject more spam, accept legitimate mail without extra work, and focus further analysis on only those messages it needs to. 3.1 The Four Tests SPF defines four tests that may be applied to the identities: Test Equivalent Question ------------- ---------------------------------------------------------- SPF/PTR "Does the owner of the client host's domain name authorize that host to operate as a sending MTA?" SPF/HELO "Does the domain indicated in the HELO command authorize the client host to initiate SMTP sessions in its name?" SPF/MAIL-FROM "Does the entity in the return-path authorize the client host to inject mail using its name in the MAIL FROM?" SPF/PRA "Does the domain of the purported responsible address (PRA) authorize the client host to send mail on its behalf?" A receiving mail server may choose to make some or all of these tests. These questions match what might be reasonably included in a local mail policy. If the tests return a definite positive or negative result, the receiving mail server will have strong information for use in policy evaluation. These tests are similar to several tests that are implemented in existing MTA software and in popular use. For example, it is not uncommon to test that the HELO domain matches the client host's domain name, and to reject mail if it is not. In all cases, if the domain under test publishes SPF records, then the SPF test gives a stronger result that allows local mail policy to be more effective. If the domain does not publish SPF records, then the SPF test has no strong result and local policy may dictate falling back on other tests. The details of each test, how to perform them, and how to interpret the results can be found in the four documents [SPF/PTR], [SPF/HELO], [SPF/MAIL-FROM] and [SPF/PRA]. See later in this document for how to combine the tests into a conforming SPF mail policy. 3.2 The Results Each SPF test can return one of seven results. Generically, the results answer the SPF test question as: Result Answer --------- ----------------------------------------------------------- Pass the client host is permitted to use the identity Fail the client host is not permitted to use the identity Softfail in the MAIL-FROM and PRA tests, the client host may not be permitted to use the identity, but the domain isn't willing to rule it out; in PTR and HELO tests, proceed exactly as if the result was Fail None no SPF record was found Neutral the SPF record exists, but the sender domain cannot commit to a strong response. The receiver should proceed exactly as if the result was None. Unknown hard error during processing (such as syntax error in SPF record); proceed exactly as if the result was None. Error transient error (such as DNS timeout) while making the test; an MTA SHOULD reject the message using a transient failure code, such as 450. For a specific interpretation of these results in the context of each test, see the four documents [SPF/PTR], [SPF/HELO], [SPF/MAIL-FROM] and [SPF/PRA]. In general, a mail receiver will have to make all the tests it intends to make before determining the disposition of a given mail message. In some cases, such as an Error result, an early determination may be made as dictated by local mail policy. Note that we talk about performing a set of tests for each message, as if each message is considered independently. This makes the descriptions below easier. However, two of the tests, SPF/PTR and SPF/HELO, if they are to be made, need only be made once per SMTP session. This is an obvious optimization that we assume most MTA software will make. 3.3. Reputation When an SPF test results in Pass, a mail receiver knows that the domain permits the client host to use its identity in the tested scope. At that point, the mail receiver can base further decisions on the reputation of the domain. If the domain is known to be a "good citizen", local policy might dictate accepting the message without further checks. If the domain is known to be a "spammer", then local policy might dictate refusing the mail. Other reputations between these two extremes might cause local policy to continuing processing but apply further checks to the mail. A domain's reputation can be assessed in a number of ways. A simple local whitelist of domains that are known to send good mail is a crude reputation system. Even a plain text file containing no more than a dozen lines constitutes a reputation system for the purposes of this document. More complex systems might involve a network of reporting nodes each with their own reputation. Such a network might be commercial or grassroots. It is beyond the scope of this document to discuss the details of such services. Note that reputations systems may choose to rate domain names with or without respect to particular identity scopes. Note also that the result from a reputation system can be simple: good, bad, or unknown. The result can also be multifaceted and complex, shading from weak to strong. 3.4 Local Policy SPF documents often talk about a mail receiver's "local policy". By this we mean the organization's set of guidelines covering the reception of e-mail, separate from the requirements that all mail software must fulfill. For example, every organization has a choice about what to do with mail addressed to nonexistent mailboxes within the domain. Some choose to bounce the messages, some choose to deliver them to designated employee, and some choose to silently discard the messages. SPF's aim is to enable more effective local policies, especially in the area of handling unwanted e-mail. SPF doesn't dictate any particular policy. Indeed, it is possible to be fully SPF compliant and not alter one's current policies at all. We cannot stress enough that it is incumbent on organizations to consciously create local policy on receiving mail. SPF and the MTA software that implements gives you tools, but they are useless if you don't use them. Furthermore, since the choices in local policy come with trade-offs, we urge organizations to critically examine default configurations before applying them. 3.5. Local Policy and the SPF Tests While SPF supports a wide range of local policies, there are some rules that all conformant SPF receivers must follow. These rules are expressed here in terms of how the results of one or more SPF tests are combined and interpreted, This in turn puts limits on conformant local policy. These rules are necessary so that publishers of SPF records know the bounds within which they will be interpreted. SPF-conformant receivers perform one or more of the SPF tests against a given mail message. The mechanics and semantics of SPF tests are described in [SPF/PTR], [SPF/HELO], [SPF/MAIL-FROM], and [SPF/PRA]. This proposal does not recommend which identities to test; those recommendations are made in [SPF Best Practices]. The following algorithm describes how a receiver performs the test. An implementation MAY use any equivalent algorithm, including short-circuiting optimizations, but the effective result MUST be the same as described below. If a receiver chooses to perform only one of the SPF tests, the policies described in sections 3.1 of the test documents are conformant to this section. This algorithm is intended to help receivers accept wanted email and reject unwanted email. It involves both SPF tests and a reputation component which receivers can implement as they see fit. Example reputation components include whitelists and blacklists, but can be considerably more complex. The four identities are: PTR, HELO, MAIL-FROM, and PRA First, a receiver decides which identities it wishes to test. See [SPF Best Practices]. Identities that the mail receiver does not test are removed from the list. For each tested identity, a result is obtained by running the appropriate SPF test, and possibly also a reputation test: A positive result is defined as one for which: - the SPF test returns Pass, AND - the reputation test returns a positive opinion of the domain under test. A negative result is defined as one for which: - the SPF test returns Fail, OR - the reputation test returns a negative opinion of the domain under test. A zero result is defined as any which is neither positive or negative. This may be due to the lack of any published SPF data, a processing error, or a reputation test that yields no information. Note that for SPF/PTR and SPF/HELO, a test result of Softfail is treated as Fail, and so is grounds for a negative result. A positive result from any identity overrides a negative result from any other identity. If, during evaluation, a positive result is obtained, a mail receiver MAY choose to dispense with further checks and accept the mail. If, during evaluation, a negative result is obtained, a mail receiver MUST continue to test the other identities it has chosen to test in search of a positive result. This algorithm was formulated to support the following situations: 3.5.1 Legitimate "consumer-grade" broadband MTAs Some legitimate mail senders may, for reasons beyond their control, obtain an SPF/PTR test result of FAIL. These rules allow them to send mail as long as their SPF/HELO, SPF/MAIL-FROM, or SPF/PRA tests result in a PASS and their legitimacy is recognized by the receiver MTA. The intended beneficiaries in this scenario are legitimate broadband end-users who operate MTAs without the knowledge of the network owner, and their recipients. 3.5.2 Legitimate sender domains using disreputable MTAs Similar logic applies to legitimate mail senders whose MTAs have FAIL results for SPF/HELO. This provision allows those senders to send mail as long as their SPF/MAIL-FROM tests result in a PASS and their legitimacy is recognized by the receiver MTA. There intended beneficiaries in this scenario include legitimate domains who are required to relay outbound mail through a shared MTA. If that shared MTA becomes a source of unwanted mail, and it suffers a poor reputation, PTR/MAIL-FROM should still be able to override the host's misfortune, especially during the window in which the host's behaviour has improved but before its reputation has had a chance to catch up. Note that this scenario may collapse: if the malicious entities responsible for the MTA's bad reputation begin to spoof the legitimate domain in MAIL FROM, that legitimate domain's reputation will suffer. 3.5.3 Legitimate forwarding bypass An early positive result allows support for trusted forwarding services whose PTR/HELO tests return a positive result; even if the PTR/MAIL-FROM would return a FAIL, the trusted status of the receiving host should be sufficient to permit the mail to pass. 4. Conformance Definitions The following sections define SPF conformance applied to various entities. 4.1 Introduction In an SMTP+SPF transaction, there are three primary entites: - the sending host (the SMTP client) - the SMTP receiver - the envelope sender identity (which is one of PTR, HELO, MAIL-FROM, and PRA). The conformance status of each entity has implications for the transaction as a whole. 4.2 Conformance with regard to envelope sender identities For a domain to be considered SPF-conformant, its authoritative DNS servers are REQUIRED to publish an SPF record for that domain. Domains which do not publish SPF data are not deemed SPF-conformant. If foo.example.com claims SPF compliance, it must have a record of the form: foo.example.com IN TXT "v=spf1 ..." A receiver may query a domain's SPF record in context of any one of four identities. Publishing domains SHOULD configure their SPF records to return the appropriate result for each identity. If a single domain name wishes to designate different sets of servers for different identities, the easiest solution is for the SPF record to describe the union of all those sets. Suppose a domain "example.com" has multiple MTAs "mx1" and "mx2" which announce HELO "mx1.example.com" and "mx2.example.com" and have the PTR domain names "wayne.example.com" and "greg.example.com". It is RECOMMENDED that example.com publish five SPF records, one for each domain name. 4.3 Conformance with regard to sending e-mail systems To be considered SPF-conformant, an SMTP sending host SHOULD resolve a "pass" for all of its SPF-conformant identities. If the domain name used in a host's HELO command has an SPF record, that record MUST resolve a PASS for that host. An SMTP sending host SHOULD also resolve a "pass" for its PTR hostname. If the domains used in MAIL FROM and in HELO/EHLO do not publish SPF information, an SMTP sending host is considered conformant by default. Only when those domains do publish SPF is the SMTP sending host required to resolve a "pass". For example: in a transaction where host mx01 emits: HELO mx01.example.com MAIL FROM: It should be prepared for SMTP+SPF receivers to ask for an SPF record at either or both of example.com TXT mx01.example.com TXT If either query returns an SPF record, the test MUST return "pass". 4.4 Conformance with regard to receiving e-mail systems To describe itself as SPF-conformant, an SMTP receiver MUST perform SPF tests on at least one of the identities in the SMTP transaction, and combine the results in a mannar equivalent with section 3.5. SPF tests need not be performed while an SMTP transaction is ongoing: if the MDA performs the test, that is sufficient. A server need not reject a message; but if it does not, it SHOULD add a Received-SPF header. If a server rejects a message, it SHOULD include any provided by the SPF publisher. Exactly which tests should a receiver perform? See [SPF BestPractices]. Receiver systems MAY exclude special recipients such as postmaster@ and abuse@ from SPF processing. See [RFC2142]. SPF is only one component in a policy engine. An SPF-conformant SMTP receiver is NOT REQUIRED to perform SPF tests on messages whose dispositions have already been decided on the basis of other policy. Example 1: if an SMTP receiver requires that sender domains must possess MX or A records, and rejects transactions where they do not, then SPF tests are moot. Example 2: if an SMTP receiver expects messages from a trusted client, such as a secondary MX for its own domain, then SPF tests are not needed. Example 3: if an SMTP receiver is considering a transaction which does not yield a fully-qualified domain name in either the MAIL FROM sender or the HELO command, SPF tests are not appropriate, and the disposition of the message should be decided on the basis of other policy. 4.5 Conformance with regard to a particular SMTP transaction An email message during delivery is conformant if SPF evaluation results in a "pass", "neutral", or "softfail" for at least one of the four identities. 4.6 Conformance with regard to an email-sending user An email-sending user is conformant if all of her outbound mail is sent through a conformant MTA for her sender domain. 4.7 Rejection of non-SPF conformant email Mail from a domain SHOULD NOT be automatically treated as suspect just because the domain doesn't publish SPF records. If the algorithm in 3.5 above returns an overall negative result, the receiver domain MAY reject, label, or classify the message as it wishes. If the message is rejected, the receiver domain SHOULD provide the "exp" string specified in [SPF protocol] section 5.2. 4.8 Rejection of SPF conformant email An SPF email system MAY choose to reject or discard email on the basis of local policy. SPF is one component in an overall email-policy engine. SPF merely makes it possible for policy decisions to be made with confidence at the sender-domain level. The actual policy decisions are outside the scope of this document. 4.9 Recommendations If a domain contains subdomains or hostnames that have A or MX records, those subdomains and hostnames SHOULD publish SPF records. If they do not, they remain at risk of forgery. Domain names used in a legitimate envelope sender SHOULD possess MX records. This proposal recommends the deprecation of the legacy "implicit MX" rule defined in [RFC2821] section 5. Domains that want to receive mail SHOULD always define explicit MX records. This proposal also recommends that HELO arguments SHOULD be fully-qualified domain names that resolve to the IP address of the sending MTA. 5 Other Considerations 5.1 Adoption by disreputable domains It is trivial for a domain to publish "+all" to allow all. A disreputable domain could then send unwanted email from any host. This is a common objection to SPF. SPF provides a value-neutral framework for sender authentication and accreditation. Senders use that framework to make assertions regarding the quality of messages. It is the responsibility of the SMTP receiver to evaluate those assertions. First the SMTP receiver discards obvious forgeries. Then it evaluates the remaining messages according to the reputation of the sender and any accompanying accreditation assertions. Whether a given domain is reputable or not is a decision that belongs to an SMTP receiver. Policy decisions regarding particular messages are outside the scope of SPF. This is why reputation systems are an essential component of the policy algorithm described in section 3.5. 5.2 Limitations In an SPF-conformant environment, envelope sender forgery is limited to the local domain. Unless per-user macros are used, it is possible for one user to forge another user's address within that domain. However, the organization responsible for the domain presumably has the wherewithal to follow an audit trail. 5.3 Verbatim Forwarding SPF/MAIL-FROM changes the model of email from a store-and-forward system to an end-to-end system. Verbatim email forwarding suffers accordingly. In verbatim forwarding, an intermediate forwarding host rewrites the envelope recipient, but leaves the envelope sender untouched. There are two ways to preserve forwarding functionality under SPF. Either forwarders can change to remailing, or receiver systems can whitelist forwarders. In remailing, forwarding hosts rewrite the return-path address. The rewritten envelope sender can take a variety of forms, depending on whether bounces should be forwarded back to the original sender. If bounces are unimportant, the rewritten sender could be as simple as . If bounces are important, forwarders can use envelope encapsulation with a MAC nonce, or rewrite the address into a database-backed cookie. If return-path rewriting is not feasible, receiver systems can simply whitelist trusted sites which are known to forward mail to local receivers. The algorithm in section 3.5, in which a positive SPF/HELO result overrides a negative SPF/MAIL-FROM result, makes this possible. 6. IANA Considerations The registry of standard mechanism and modifier names may be turned over to IANA for management. Normative References [RFC2396] Informative References [RFC1034] [RFC1464] [RFC2119] [RFC2142] [RFC2234] [RFC2373] [RFC2505] [RFC2821] [RFC2822] Danisch, Hadmut. "The RMX DNS RR Type for light weight sender authentication", http://www.danisch.de/work/security/antispam.html, October 2003, Work In Progress. Fecyk, Gordon. "Designated Mailers Protocol", December 2003, Work In Progress. http://www.pan-am.ca/dmp/ Wong, M.W., "Sender Rewriting Scheme", Work In Progress, http://spf.pobox.com/srs.html DeKok, Alan. The LMAP discussion document. Vixie, Paul. "Repudiating Mail-From". http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00658.html http://nospam.couchpotato.net/ http://asrg.sp.am/ http://www.ietf.org/html.charters/marid-charter.html Authors Meng Weng Wong Singapore mengwong+spf@pobox.com Mark Lentczner 1209 Villa Street Mountain View, CA 94041 United States of America markl@glyphic.com Comments on this draft are welcome. In the interests of openness, before contacting the authors directly, please post to the spf-discuss mailing list. To join the mailing list, please see http://spf.pobox.com/mailinglist.html Developers of SPF-conformant software SHOULD join the spf-devel mailing list. They also SHOULD consult the SPF Developers Guide at http://spf.pobox.com/developers-guide.html. While specifications published as RFCs are relatively static, the mailing list and developers guide are living resources. They augment this core protocol specification with generally accepted implementation practices which are outside the scope of this document. They also provide a forum for interoperability testing.