Internet Draft                                           Mark Lentczner
Category: Experimental                                    Wayne Schlitt
draft-schlitt-marid-spf-from-hdr-00.txt       Meng Weng Wong, pobox.com
Expires: December 2004                                        July 2004

                                SPF/FROM-HDR
            Determining sender policy for the From: header


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 December 2004.


Abstract

   This document is part of the Unified SPF series.  It defines the
   SPF/FROM-HDR test, which uses the spf_test() function in
   conjunction with the From: header of the email. This document
   describes the mechanics, semantics and utility of the SPF/FROM-HDR
   test.  It also recommends receiver policy actions.
   

Table of Contents

   1. Introduction
      1.1 Requirement levels
         1.1.1 The operations described are NOT REQUIRED of receivers.


Schlitt, Wong & Lentczner                                     [Page 01]

Internet-Draft           Sender Policy Framework            Jul 12 2004


         1.1.2 DNS publishers SHOULD expect evaluation in this context.
      1.2 Terminology
   2 Inputs to the spf_test() Function
      2.2 Considerations
      2.1. Email Authentication Algorithm
   3. Applicability Statement
      3.1 Interpretation of Results
   4. Changes to Existing Semantics
   5. Recommendations for MTAs and MUAs
      5.1 Simple E-mailers
      5.2 E-mail Forwarders
      5.3 Mailing List Servers
      5.4 MUA Implementers
   Normative References
   Informative References
   Authors



1. Introduction

   Owners of domain names can publish SPF records to distinguish
   between hosts which are and are not permitted to use their names in
   the email's From: header.

   Mail receivers perform the SPF/FROM-HDR test to determine if a
   particular host is permitted according to the domain's published
   SPF record.
   
   This distinction is useful to mail receivers who seek to ensure
   that the email address on the From: header is either from a source
   authenticated by the "from" domain owner, or from a source approved
   (whitelisted) by the receiver.
   
1.1 Requirement levels

1.1.1 The operations described are NOT REQUIRED of receivers.

   Mail receivers are NOT REQUIRED to perform the operations described
   herein.  If they choose to perform these operations, however, they
   MUST follow the forms prescribed.  This document defines how to
   evaluate the spf_test function described in [spf-protocol] in the
   context of the From: header domain name, and assigns a meaning to
   the result of that evaluation.

1.1.2 DNS publishers SHOULD expect evaluation in this context.

   Domain owners who publish an SPF record for a given domain name


Schlitt, Wong & Lentczner                                     [Page 02]

Internet-Draft           Sender Policy Framework            Jul 12 2004


   should expect that record to be evaluated in the context of the
   SPF/FROM-HDR test, and ensure their record reflects their domain's
   policy on who is permitted to use the domain name in the From: header.
   
   For example, suppose the MTA 192.0.2.2 sends mail with the header:
      From: <grumpy@example.org>

   If the owner of the domain example.org approves of this use of its
   name by 192.0.2.2, the SPF record for example.org MUST return a
   PASS result for 192.0.2.2.

   For more information on interactions with other tests, see: [SPF
   Unified].

1.2 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].

   This document uses other terminology defined in the [SPF protocol]
   document.
   
2 Inputs to the spf_test() Function

   To perform the SPF/FROM-HDR Test, an SMTP server or MUA evaluates
   the spf_test() function with these arguments:
      <ip>     -- the IP address of the SMTP client
      <domain> -- the domain from the first email address on the From:
                  header
      <scope>  -- the string "from-hdr"
      
2.2 Considerations

   
   Email received by an individual mail box may come from many
   different sources, but the vast majority of email will come from
   one of two sources.  First, email may be sent directly, in which
   case the From: header of the email should be able to be
   authenticated.  Second, email may be sent indirectly through a
   forwarding relationship that the receiver has set up and
   authorized.

   While there may be many email forwarding relationships in general,
   each individual mail box will usually have a very small set of
   these relationships, and the set does usually change very often.
   Since such forwarding relationships are created by the receiver,
   the receiver will generally try not to use forwarders that do not


Schlitt, Wong & Lentczner                                     [Page 03]

Internet-Draft           Sender Policy Framework            Jul 12 2004


   abuse the receivers trust.

   There are many types of email forwarding relationships, but the two
   most common are mailing lists and mailbox aliases where the
   receiver has elected to have all email sent to one mail box to be
   forwarded to another, possibly on a different system.  In the case
   of mailing lists, RFC2821 says that the return address (the
   envelope from) is changed to the list administrator, which can be
   used as a receiver approved whitelist value.  In the case of
   aliases, the To: header usually contains the mail box that the
   email was forwarded from, and thus can be used as a receiver
   approved whitelist value.  The MTA doing the forwardering will also
   usually be from a limited set, which can be used as a receiver
   approved whitelist value.
   
   Email that does not come directly to the mail box or through a
   receiver approved forwarding relationship should be considered
   highly suspect.

2.1. Email Authentication Algorithm

   In order authenticate the email as being valid, the following steps
   SHOULD be followed.  Additional step and/or omitting steps may be
   appropriate, depending on the email receiver's situation.


   1.  Check the first mailbox found on the From: header to see if it
       passes.  That is, from_result = spf_test(From:,IP).  If the
       result passes, then exit and return the from_result.

   2.  Check to see if any of the mailboxes on the To: header has been
       whitelisted by the receiver.  For each whitelisted mailbox,
       check to see if the spf_test(To:,IP) passes.  If any of them
       do, then the exit and return "pass".

   3.  Check to see if the RFC2821 envelope from domain is whitelisted
       by the receiver.  If it is, check to see if the spf_test(MAIL
       FROM, IP) passes.  If the result passes, then exit and return
       "pass". 

   4.  Check to see if the RFC2821 HELO domain is whitelisted by the
       receiver.  If it is, check to see if the spf_test(HELO,IP)
       passes.  If the result passes, then exit and return "pass".

   5.  Return the from_result as obtained from step 1.

      
3. Applicability Statement


Schlitt, Wong & Lentczner                                     [Page 04]

Internet-Draft           Sender Policy Framework            Jul 12 2004



   The SPF/FROM-HDR test is equivalent to asking the question "Does the
   domain indicated in the From: header authorize the client host to
   initiate SMTP sessions on its behalf?"
   
   Receivers may use the result as an input to local policy decisions.

   For example, rejections can be returned early in the SMTP
   transaction if the host is not authorized by the domain.
   
   If the host is authorized, then policy can be based on the
   reputation of the domain, rather than the host IP.
   
   For more information on local policy decisions, see [SPF Unified].
   

3.1 Interpretation of Results

   This section gives recommendations for local policy regarding the
   SPF/FROM-HDR test.  A compliant SPF local policy needs to take into
   account any other SPF tests that are performed.  See [SPF Unified]
   for a complete set of requirements for local policy.
   
   If SPF/FROM-HDR is the only SPF test performed on the SMTP session,
   then these recommendations are a conformant policy under [SPF
   Unified].  If any other SPF tests are performed, [SPF Unified] MUST
   be consulted.

   In the case of conflict between this section and [SPF Unified], the
   latter is considered normative.

   Result: Fail
   Policy: The client is explicitly not authorized by the domain to
   initiate SMTP sessions.  Receivers MAY terminate the SMTP session
   with a 550 code.  The text of the 550 rejection should include the
   explanation string, if any, that was set in the SPF record's exp=
   modifier.
   
   Result: Pass
   Policy: Since the client is authorized by the domain, further
   processing can be based on the reputation of the domain name.  For
   example, if the domain is in a local white-list, all further mail
   could be accepted without further checks.  On the other hand, if
   the domain has a negative reputation, the session MAY be terminated
   with a 550 Local Policy response.
   
   Result: Error
   Policy: this indicates a transient error.  Receivers MAY return an


Schlitt, Wong & Lentczner                                     [Page 05]

Internet-Draft           Sender Policy Framework            Jul 12 2004


   SMTP 450 Temporary Failure code.
   
   Result: Neutral, Unknown, or None
   Policy: In these cases, no determination about the client can be
   made.  Local policy may dictate that the messages in this session
   will be subject to further tests and/or marked as being from an
   unverified MTA.

   Result: Softfail
   Policy: This result SHOULD be treated as equivalent to a FAIL
   result.

   In any case, if the domain has a negative reputation, a receiver
   MAY terminate the session with a 550 Local Policy rejection.

   
4. Changes to Existing Semantics

   There are no changes in semantics to existing protocols.  However,
   the existence of this test may cause system administrators to make
   some choices differently.
   
5. Recommendations for MTAs and MUAs

   This section describes the actions that certain members of the
   Internet email ecosystem must take to be compliant with this
   specification.



5.1 Simple E-mailers

   A domain that injects original email into the Internet, using its
   own name in From: headers, need do nothing to be compliant.
   However, such domains SHOULD publish e-mail policy records in DNS.


5.2 E-mail Forwarders

   A program that forwards received mail to other addresses SHOULD
   rewrite the RFC2821 envelope from to their own domain to accept
   responsibility for any bounces that are created and to facilitate
   receiver approved whitelisting.  Email forwarders should also use a
   consistent and valid HELO domain to facilitate whitelisting.


5.3 Mailing List Servers



Schlitt, Wong & Lentczner                                     [Page 06]

Internet-Draft           Sender Policy Framework            Jul 12 2004


   A mailing list server SHOULD rewrite the RFC2821 envelope from to
   the the list administrators email address to accept responsibility
   for any bounces that are created and to facilitate receiver
   approved whitelisting.

   Almost all of today's mailing list software already rewrites the
   RFC2821 envelope from.


5.4 MUA Implementers

   When displaying a received message, an MUA SHOULD display the
   results of the email authentication algorithm.

   


Normative References

  [RFC2396]

Informative References

  [RFC1034]
  [RFC1464]
  [RFC2119]
  [RFC2142]
  [RFC2234]
  [RFC2373]
  [RFC2505]
  [RFC2821]
  [RFC2822]





Authors

   Wayne Schlitt
   4615 Meredeth #9
   Lincoln, NE 68506
   United Status of America
   wayne@midwestcs.com

   Meng Weng Wong
   Singapore
   mengwong+spf@pobox.com


Schlitt, Wong & Lentczner                                     [Page 07]

Internet-Draft           Sender Policy Framework            Jul 12 2004



   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