--- draft-schlitt-spf-classic-01pre1.xml	Fri Mar 04 22:38:02 2005
+++ draft-schlitt-spf-classic-01pre1+mehnle.xml	Sat Mar 05 01:58:39 2005
@@ -181,6 +181,6 @@
         <t>
           The "HELO" identity derives from either the SMTP HELO or
-          EHLO command (see <xref target="RFC2821"/>.) These commands
-          supply the SMTP client (sender) for the SMTP session.  Note
+          EHLO command (see <xref target="RFC2821"/>). These commands
+          supply the SMTP client (sending host) for the SMTP session.  Note
           that requirements for the domain presented in the EHLO or
           HELO command are not always clear to the sending party, and
#
# Fix punctuation.  Clarify.
#
@@ -189,7 +189,9 @@
         </t>
         <t>
-          SPF clients MAY check the "HELO" identity by applying the
+          It is RECOMMENDED that SPF clients not check only the "MAIL FROM" identity,
+          but also the "HELO" identity by applying the
           check_host() function (<xref target="function"/>) to the
-          "HELO" identity as the &lt;sender&gt;.  If the HELO test
+          "HELO" identity as the &lt;sender&gt;.
+          If a HELO test is performed and
           results in a "Fail", the overall result for the SMTP session is
           "Fail", and there is no need to test the "MAIL FROM" identity.
#
# Recommend HELO checking, not just suggest it.
#
@@ -199,5 +201,5 @@
         <t>
           The "MAIL FROM" identity derives from the SMTP MAIL command
-          (see <xref target="RFC2821" />.) This command supplies the
+          (see <xref target="RFC2821"/>.) This command supplies the
           "reverse-path" for a message, which generally consists of
           the sender mailbox, and is the mailbox to which notification
#
# Minor clean-up.
#
@@ -206,5 +208,5 @@
         </t>
         <t>
-          <xref target="RFC2821" /> allows the reverse-path to be null
+          <xref target="RFC2821"/> allows the reverse-path to be null
           (see Section 4.5.5).  In this case, there is no explicit
           sender mailbox, and such a message can be assumed to be a
@@ -212,5 +214,6 @@
           reverse-path is null, this document defines the "MAIL FROM"
           identity to be the mailbox composed of the localpart
-          "postmaster" and the "HELO" identity.
+          "postmaster" and the "HELO" identity (which may or may not
+          have been checked separately before).
         </t>
         <t>
#
# Clarify.
#
@@ -225,6 +228,6 @@
           An SPF compliant domain MUST publish a valid SPF record as
           described in <xref target="records"/>.  This record
-          authorizes the use of the domain name in the "HELO" and/or
-          "MAIL FROM" identity, by some sending MTAs, and not by
+          authorizes the use of the domain name in the "HELO" and
+          "MAIL FROM" identities, by some sending MTAs, and not by
           others.
         </t>
#
# Clarify.
#
@@ -242,12 +245,14 @@
       <section title="Checking Authorization">
         <t>
-          A mail receiver can perform an SPF compliant check for each
-          mail message it receives.  This check tests the
-          authorization of a client host to emit mail with a given
-          "MAIL FROM" identity.  This check MAY also be applied to the
-          "HELO" identity.  Typically, such checks are done by a
+          A mail receiver can perform a set of SPF checks for each
+          mail message it receives.  An SPF check tests the
+          authorization of a client host to emit mail with a given identity.
+          Typically, such checks are done by a
           receiving MTA, but can be performed elsewhere in the mail
           processing chain so long as the required information is
-          available and reliable.  Checking other identities against
+          available and reliable.
+          At least the "MAIL FROM" identity MUST be checked, but it
+          is RECOMMENDED that the "HELO" identity also be checked beforehand.
+          Checking other identities against
           SPF records is NOT RECOMMENDED because there are cases
           (e.g. <xref target="forwarding"/>) that are known to give
#
# Clarify.  Recommend HELO checking, not just suggest it.
#
@@ -255,4 +260,18 @@
         </t>
         <t>
+          SPF checks MUST NOT be applied to invalid identities, that
+          is, domains that do not exist.  The result of such a check
+          is an error.  Many mail receivers already discriminate
+          against messages that use identities with non-existent
+          domains, and while there are no strict requirements for the
+          identity used in the "HELO" SMTP command,
+          <xref target="rfc2821"/>, Section 3.6, requires the identity
+          used in the "EHLO" command to either be a valid host name or
+          an IP address literal.  So even if a mail receiver would not
+          normally validate the "HELO" identity, it must do so before
+          subjecting it to an SPF check, or expect the check to result
+          in an error.
+        </t>
+        <t>
           It is possible that mail receivers will use the SPF check as
           part of a larger set of tests on incoming mail.  The results
#
# Do not allow SPF to be applied to non-existent domains.
# This effectively redefines the result of SPF(non-existent-domain)
# from "None" to "PermError".  Also see below.
#
@@ -288,14 +307,4 @@
         </t>
         <t>
-          Note that the &lt;domain&gt; argument may not be a well
-          formed domain name.  For example, if the reverse-path was
-          null, then the EHLO or HELO domain is used.  In a valid SMTP
-          session, this can be an address literal or entirely
-          malformed.  In these cases, check_host() is defined in <xref
-          target="initial" /> to return a "None" result.
-          <!-- FIXME: should this be "None"? lots of conflict between -->
-          <!-- PermError in the various specs and implementations -->  
-        </t>
-        <t>
           Care must be taken to correctly extract the &lt;domain&gt;
           from the &lt;sender&gt; as many MTAs will still accept such
#
# Paragraph got replaced by the above.  Also see below.
#
@@ -345,7 +354,7 @@
         <section title="Neutral">
           <t>
-            The domain owner has explicitly stated that doesn't know
-            whether the IP address is authorized or not.  A Neutral
-            result MUST be treated exactly like the None result; the
+            The domain owner has explicitly stated that he doesn't know
+            whether the IP address is authorized or not.  A "Neutral"
+            result MUST be treated exactly like the "None" result; the
             distinction exists only for informational purposes.
           </t>
#
# Fix grammar: "that _he_ doesn't know".
# Quote symbolic error codes.
#
@@ -433,5 +442,5 @@
         An SPF record is a DNS Resource Record (RR) that declares
         which hosts are, and are not, authorized to use a domain name
-        for the "HELO" or "MAIL FROM" identity. Loosely, the record
+        for the "HELO" and "MAIL FROM" identities. Loosely, the record
         partitions all hosts into permitted and not-permitted
         sets. (Though some hosts might fall into neither category.)
#
# Clarify: s/or/and/.
#
@@ -452,5 +461,5 @@
         <t>
           Domain owners wishing to be SPF compliant must publish SPF
-          records for the hosts that are used in both the MAIL FROM
+          records for the hosts that are used in the MAIL FROM
           and HELO identities.  The SPF records are placed in the DNS
           tree at the host name it pertains to, not a subdomain under
#
# Clarify: not just domains ("hosts"??) that are used in _both_
# MAIL FROM _and_ HELO are affected.  Domains that are just used in
# either one are affected, too.
#
@@ -471,5 +480,5 @@
           When publishing via TXT records, beware of other TXT records
           published there for other purposes.  They may cause problems
-          with size limits (see <xref target="rsize"/>.)
+          with size limits (see <xref target="rsize"/>).
         </t>
         <section title="DNS Resource Record Types">
#
# Fix punctuation.
#
@@ -565,5 +574,5 @@
             TXT records published at the domain name.  Records that
             are too long to fit in a single UDP packet MAY be
-            silently ignored. 
+            silently ignored by SPF clients.
           </t>
         </section>
#
# By _whom_ may oversized records be ignored?  By SPF clients?  Or by
# DNS servers, too??
#
@@ -661,5 +670,5 @@
           If the &lt;domain&gt; is malformed or is not a fully
           qualified domain name, check_host() immediately returns the
-          result "None".
+          result "PermError".
         </t>
         <t>
#
# Do not allow SPF to be applied to non-existent domains.
# This effectively redefines the result of SPF(non-existent-domain)
# from "None" to "PermError".  Also see above and below.
#
@@ -679,5 +688,10 @@
           other error (RCODE other than 0 or 3), or the query times
           out, check_host() exits immediately with the result
-          "TempError"
+          "TempError".
+        </t>
+        <t>
+          If the DNS lookup returns a Name Error (RCODE 3), the
+          &lt;domain&gt; does not exist, and check_host() exits
+          immediately with the result "PermError".
         </t>
       </section>
#
# Do not allow SPF to be applied to non-existent domains.
# This effectively redefines the result of SPF(non-existent-domain)
# from "None" to "PermError".  Also see above.
#
@@ -744,6 +758,6 @@
 terms            = *( 1*SP ( directive / modifier ) )
 
-directive        = [ prefix ] mechanism
-prefix           = "+" / "-" / "?" / "~"
+directive        = [ sign ] mechanism
+sign             = "+" / "-" / "?" / "~"
 mechanism        = ( all / include
                    / A / MX / PTR / IP4 / IP6 / exists )
#
# Is "prefix" a highly traditional term?  If not, I'd strongly
# prefer the term "sign", which is more descriptive.
#
@@ -780,5 +794,5 @@
           </t>
           <t>
-            If it matches, processing ends and the prefix value is
+            If it matches, processing ends and the sign value is
             returned as the result of that record.  If it does not
             match, processing continues with the next mechanism.  If
@@ -787,5 +801,5 @@
           </t>
           <t>
-            The possible prefixes, and the results they return are:
+            The possible signs, and the results they return are:
             <list style="hanging">
               <t hangText="&quot;+&quot;">Pass</t>
@@ -795,7 +809,7 @@
             </list>
           </t>
-          <t> The prefix is optional and defaults to "+". </t>
+          <t> The sign is optional and defaults to "+". </t>
           <t>
-            When a mechanism matches and the prefix is "-", then a
+            When a mechanism matches and the sign is "-", then a
             "Fail" result is returned and the explanation string is
             computed as described in <xref target="mod-exp"/>.
@@ -957,5 +971,5 @@
           the overall processing and does not necessarily result in a
           overall "Fail".  (Better names for this mechanism would have
-          been "if-pass", "on-pass", "call", or "eval, etc.)
+          been "if-pass", "on-pass", "call", "eval", etc.)
         </t>
         <t>
#
# Fix quotes.  Improve wording: "or" is redundant if followed by "etc.".
#
@@ -1218,5 +1232,5 @@
       </t>
       <t>
-        Unrecognized modifiers SHOULD be ignored no matter where in
+        Unrecognized modifiers MUST be ignored no matter where in
         a record, nor how often.  This allows implementations of
         this document to gracefully handle records with modifiers that are
#
# What would be the effect of having "SHOULD" here instead of "MUST"?
# What happens if unrecognized modifiers are not ignored?  Should
# implementations really be allowed to die on unrecognized modifiers?
#
@@ -1299,5 +1313,5 @@
         <t>
           If &lt;domain-spec&gt; is empty, or there are any processing
-          errors (any RCODE other than 0), or if no records are
+          errors (any RCODE other than 0 or 3), or if no records are
           returned, or if more than one record is returned, then
           proceed as if no exp modifier was given.
#
# Fix semantics.  Note that this is essentially unrelated to the
# "SPF(non-existent-domain) = PermError" series of changes.
#
@@ -1428,8 +1442,7 @@
       </t>
       <t>
-        The header SHOULD include a "(...)" style &lt;comment&gt; after the
-        result, conveying supporting
-        information for the result, such as &lt;ip&gt;,
-        &lt;sender&gt; and &lt;domain&gt;.
+        The header SHOULD include a "(...)" style &lt;comment&gt;
+        after the result, conveying supporting information for the
+        result, such as &lt;ip&gt;, &lt;sender&gt; and &lt;domain&gt;.
       </t>
       <t>
#
# Fix formatting.
#
@@ -1456,5 +1469,5 @@
       </t>
       <t>
-        Other key-value pairs may be defined by SPF clients.  Until
+        Other keys may be defined by SPF clients.  Until
         a new key name becomes widely accepted, new key names should
         start with "x-".
#
# Improve wording: s/key-value pairs/keys/.
#
@@ -1664,10 +1677,10 @@
         <t>
           Uppercased macros expand exactly as their lower case
-          equivalents, and are then URL escaped. URL escaping is
-          needed for characters not in the set "uric", which is
+          equivalents, and are then URL escaped. URL escaping must be
+          performed for characters not in the "uric" set, which is
           defined in <xref target="RFC2396"/>.
         </t>
         <t>
-          Note: Domains should avoid using the "s", "l", "o", or "h"
+          Note: Domains SHOULD NOT use the "s", "l", "o", or "h"
           macros in conjunction with any mechanism directive. While
           these macros are powerful and allow per-user records to be
#
# Be more explicit (in both statements).
#
@@ -1773,5 +1786,5 @@
       <section title="Mailing Lists">
         <t>
-          Mailing lists must be aware of how they re-inject mail that
+          Mailing lists must be aware of how they re-send mail that
           is sent to the list. Mailing lists MUST comply with the
           requirement in <xref target="RFC2821"/> Section 3.10 and
#
# Clarify.
#
@@ -1796,5 +1809,5 @@
           and direct it to some external mailbox.  At the time of this
           writing, the near-universal practice of such services is to
-          use the original MAIL FROM of a message when re-injecting
+          use the original MAIL FROM of a message when re-sending
           it for delivery to the external mailbox.  <xref
           target="RFC1123"/> and <xref target="RFC2821"/> describe this
#
# Clarify.
#
@@ -1811,13 +1824,13 @@
               <list style="symbol">
                 <t>
-                  Neutral results can be given for IP addresses that may
-                  be forwarders, instead of Fail results.  For example:
+                  "Neutral" results could be given for IP addresses that may
+                  be forwarders, instead of "Fail" results.  For example:
                   <list style="empty">
                     <t>"v=spf1 mx -exists:%{ir}.sbl.spamhaus.org ?all"</t>
                   </list>
                   This would cause a lookup on an anti-spam DNS
-                  blocklist (DNSBL) and reject only e-mail coming from such
-                  sources.  All other email, including email sent
-                  through forwarders, would receive a Neutral result.
+                  blocklist (DNSBL) and result in "Fail" only for e-mail coming from listed spam
+                  sources.  All other mail, including mail sent
+                  through forwarders, would receive a "Neutral" result.
                   By checking the DNSBL after the known good sources,
                   problems with incorrect listing on the DNSBL are
#
# Quote symbolic result codes.
# Do not imply that receivers reject messages on "Fail".  The
# specification suggests this, but does not require it.
#
@@ -1825,20 +1838,22 @@
                 </t>
                 <t>
-                  The MAIL FROM identity can have additional information
-                  in the local part that cryptographically identifies
-                  the mail as coming from an authorized source.  Then,
-                  an SPF can bue used record such:
+                  The MAIL FROM identity could have additional information
+                  in the localpart that cryptographically identifies
+                  the mail as coming from an authorized source.  In this case,
+                  such an SPF record could be used:
                   <list style="empty">
                     <t>"v=spf1 mx exists:%{l}._spf_verify.%{d} -all"</t>
                   </list>
-                  Then, a specialized DNS server can be attached to the
-                  _spf_verify subdomain which validates the local part.
+                  Then a specialized DNS server can set up to serve the
+                  _spf_verify subdomain which validates the localpart.
                   While this requires an extra DNS lookup, this only
                   happens when the e-mail would otherwise be rejected.
+                  (ATTN: localpart might be >64 chars, especially if using SRS
+                  or similar, but domain labels are truncated to 64 chars!)
                 </t>
                 <t>
-                  Similarly, a specialized DNS servers can be created
-                  that will rate limit the e-mail coming from an
-                  unexpected IP.
+                  Similarly, a specialized DNS server could be set up
+                  that will rate-limit the e-mail coming from
+                  unexpected IP addresses.
                   <list style="empty">
                     <t>"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"</t>
#
# When explaining the various options, say "could" instead of "can".
# Improve wording: s/local part/localpart/ -- "localpart" is a fixed technical term.
# Fix grammar/semantics: "Then, an SPF can bue used record such" -- huh??
# Improve wording.
# NOTE:  The "(ATTN:)" line should not be taken as literal text for
#   the specification.  It is just something that occurred to me when
#   reading the specification.  Perhaps you can take care of this
#   issue.
# Fix grammar: s/a ... DNS servers/a ... DNS server/.
# Improve wording.
#
@@ -1877,6 +1892,6 @@
                 </t>
                 <t>
-                  Tests against some other identity, such as the HELO
-                  identity, may be used to override the test against the
+                  Tests against other identities, such as the "HELO"
+                  identity, may be used to override a failed test against the
                   "MAIL FROM" identity.
                 </t>
#
# Improve wording.  Clarify.
#
@@ -1884,5 +1899,5 @@
                   For larger domains, it may not be possible to have a
                   complete or accurate list of forwarding services used by the
-                  owners of the domain's mailboxes.  In such cases, white
+                  owners of the domain's mailboxes.  In such cases, white-
                   lists of generally recognized forwarding services could be
                   employed.
@@ -1941,9 +1956,9 @@
     </section>
     <section title="Security Considerations" anchor="security">
-      <section title="SPF Authorized E-Mail May Be UBE">
+      <section title="SPF-Authorized E-Mail May Be UBE">
         <t>
           The "MAIL FROM" and "HELO" identity authorizations must not be
           construed to provide more assurance than it does.  It is
-          entirely possible for a malicious sender to inject a message
+          entirely possible for a malicious sender to send a message
           using their own domain in the identities used by SPF, to have
           that domain's SPF record authorize the sending host, and yet
#
# Fix grammar.
# Clarify.
#
@@ -1983,5 +1998,5 @@
       <section title="Processing Limits">
         <t>
-          As with most aspects of mail, there are a number of ways
+          As with most aspects of e-mail, there are a number of ways
           that malicious parties could use the protocol as an avenue
           of a Denial-of-Service (DoS) attack.  The processing limits
#
# Clarify: s/aspects of mail/aspects of e-mail/.
#
@@ -1993,5 +2008,5 @@
               A malicious party could create an SPF record with many
               references to a victim domain, send many e-mails to
-              different SPF clients and the SPF clients would create a
+              different SPF clients and those SPF clients would then create a
               DoS attack.  In effect, the SPF clients are being used
               to amplify the attacker's bandwidth by using fewer bytes
#
# Improve wording.
#
@@ -2003,5 +2018,5 @@
               While implementations of check_host() are supposed to
               limit the number of DNS lookups, malicious domains could
-              publish records exceed these limits in an attempt to
+              publish records that exceed these limits in an attempt to
               waste computation effort at their targets when they send
               them mail.  Malicious domains could also design SPF
#
# Fix grammar.
#
@@ -2024,5 +2039,5 @@
           individual mail server can still allow an unreasonable
           amount of bandwidth amplification.  Therefore the processing
-          limits need to be quite small.
+          limits need to be quite low.
         </t>
         <t>
#
# Improve wording.
#
@@ -2117,8 +2132,8 @@
           Checking SPF records causes DNS queries to be sent to the
           domain owner.  These DNS queries, especially if they are
-          caused by the exist: mechanism, can contain information about
+          caused by the "exists" mechanism, can contain information about
           who is sending e-mail and likely to which MTA the e-mail is
           being sent to.  This can introduce some privacy
-          considerations, which may be more or less of an issue
+          issues, which may be more or less of an issue
           depending on local laws and the relationships between the
           domain owner and the persons sending the e-mail.
#
# Fix text: s/exist:/"exists"/.
# Improve wording: s/introduce privacy considerations/introduce privacy issues/.
# (Yes, I know, this causes a double occurrance of the word "issue",
# but it's still better, I think.)
#
@@ -2254,6 +2269,6 @@
 terms            = *( 1*SP ( directive / modifier ) )
 
-directive        = [ prefix ] mechanism
-prefix           = "+" / "-" / "?" / "~"
+directive        = [ sign ] mechanism
+sign             = "+" / "-" / "?" / "~"
 mechanism        = ( all / include
                    / A / MX / PTR / IP4 / IP6 / exists )
@@ -2431,5 +2446,5 @@
         <t>
           This record would be used if mail from example.org actually came
-          through servers at example.com and example.net. Example.org's
+          through servers at example.com and example.net. example.org's
           designated servers are the union of example.com's and example.net's
           designated servers. 
#
# Lower-case symbolic "example.org" domain name.
#