spf-discuss
[Top] [All Lists]

RE: latest and greatest: draft-schlitt-spf-classic-00

2005-01-03 19:59:02
Hi Wayne,

I have now finally managed to read through the whole spec.  Here are my 
suggestions, with "#" style comments embedded (below the
changes they belong to).

You can also find the complete patch attached as a file.  It includes the 
comments, too, but current versions of `patch` should
properly ignore them.

--- draft-schlitt-spf-classic-00.xml    Fri Dec 31 17:41:35 2004
+++ draft-schlitt-spf-classic-00-mehnle.xml     Tue Jan 04 00:33:31 2005
@@ -2,3 +2,3 @@

-<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!DOCTYPE rfc SYSTEM "http://xml.resource.org/public/rfc/bibxml/rfc2629.dtd"; [
     <!ENTITY rfc1035 PUBLIC ''
@@ -36,3 +36,3 @@
 ]>
-<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
+<?xml-stylesheet type='text/xsl' 
href='http://greenbytes.de/tech/webdav/rfc2629.xslt' ?>

@@ -170,3 +170,4 @@
           casually, this document defines the "MAIL FROM" identity in
-          <xref target="mfrom-ident"/>.  Note that other terms, that
+          <xref target="mfrom-ident"/>, and the "HELO" identity in
+          <xref target="helo-ident"/>.  Note that other terms, that
           may superficially look like the common terms, such as
#
# The HELO identity should be mentioned.
#
@@ -189,7 +190,7 @@
         <t>
-          SPF clients MAY check the "HELO" identity by calling the
-          check_host() function (<xref target="function"/>) with the
+          SPF clients MAY check 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
-          returns a "fail", the overall result for the SMTP session is
-          "fail", and there is no need to test the "MAIL FROM" identity.
+          results in a "Fail", the overall result for the SMTP session is
+          "Fail", and there is no need to test the "MAIL FROM" identity.
         </t>
#
# "Applying the function" and "the function results in" sound less code-ish and
# more algorithmic.
#
@@ -202,3 +203,3 @@
           the sender mailbox, and is the mailbox to which notification
-          messages are sent if there are problems delivering the
+          messages are to be sent if there are problems delivering the
           message.
@@ -207,3 +208,3 @@
           <xref target="RFC2821" /> allows the reverse-path to be null
-          (see Section 4.5.5.) In this case, there is no explicit
+          (see Section 4.5.5).  In this case, there is no explicit
           sender mailbox, and such a message can be assumed to be a
#
# Fix grammar.
#
@@ -212,3 +213,3 @@
           identity to be the mailbox composed of the localpart
-          "postmaster" and the "HELO" identity
+          "postmaster" and the "HELO" identity.
         </t>
#
# Fix grammar.
#
@@ -216,4 +217,4 @@
           SPF clients MUST check the "MAIL FROM" identity unless HELO
-          testing produced a "fail".  SPF clients check the "MAIL
-          FROM" identity by calling the check_host() function with the
+          testing produced a "Fail".  SPF clients check the "MAIL
+          FROM" identity by applying the check_host() function to the
           "MAIL FROM" identity as the &lt;sender&gt;.
#
# Use upper case in result codes everywhere for consistency.
# "Applying the function": see above.
#
@@ -244,3 +245,3 @@
           mail message it receives.  This check tests the
-          authorization of a client host to inject mail with a given
+          authorization of a client host to emit mail with a given
           "MAIL FROM" identity.  This check MAY also be applied to the
@@ -249,3 +250,3 @@
           processing chain so long as the required information is
-          available. Checking other identities against SPF records is
+          available and reliable.  Checking other identities against SPF 
records is
           NOT RECOMMENDED because there are cases that are known to
#
# Requiring the information to be reliable should be explicit.
#
@@ -257,3 +258,3 @@
           of other tests may influence whether or not a particular SPF
-          check is performed.  For example, finding the sending host
+          check is performed.  For example, finding the sending host's IP 
address
           on a local white list may cause all other tests to be
@@ -271,3 +272,3 @@
           To make the test, the mail receiver MUST evaluate the
-          check_host() with the arguments set as follows:
+          check_host() function with the arguments set as follows:
         </t>
@@ -276,3 +277,3 @@
             <t hangText="&lt;ip&gt;">- the IP address of the SMTP client
-              that is injecting the mail, either IPv4 or IPv6.
+              that is emitting the mail, either IPv4 or IPv6.
             </t>
@@ -289,8 +290,6 @@
           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
+          null, then the EHLO/HELO domain is used.  In a valid SMTP
+          session, this could be an IP address literal or entirely
#
# "EHLO or HELO domain" implies that these are distinct concepts,
# "EHLO/HELO domain" doesn't.
# "can be" somewhat implies that IP address literals and entirely null
# identities are the usual case, the subjunctive is less strong in this
# regard.
# Make it clear that "address literal" refers to an IP address literal.
#
           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>
#
# I think "None" is a good choice.  The only real alternative would be
# "PermError", but that one shouldn't be used to indicate problems with
# messages, but only problems with SPF records.
#
@@ -306,5 +305,5 @@
         <t>
-          Software SHOULD perform this authorization check during the
-          processing of the SMTP transaction that injects the mail.
-          This allows errors to be returned directly to the injecting
+          This authorization check SHOULD be performed during the
+          processing of the SMTP transaction that sends the mail.
+          This allows errors to be returned directly to the sending
           server by way of SMTP replies.  Software can perform the
#
# Avoid mentioning the "software" in the first sentence because not every
# software that might be acting as an SPF client handles SMTP transactions
# (MUAs for example).  Instead, give emphasis to the main point of the
# sentence.
#
@@ -314,4 +313,4 @@
         <t>
-          Software can perform the authorization after the
-          corresponding SMTP transaction has completed.  There are two
+          Software can also perform the authorization after the
+          corresponding SMTP transaction has completed.  However there are two
           problems with this approach: 1) It may be difficult to
#
# Improve wording to make clear that "offline" SPF checking is just a
# suboptimal alternative to "on-the-fly" checking.
#
@@ -321,3 +320,3 @@
           notification to the alleged sender is problematic due to the
-          large number of forged emails on the Internet today.  Such
+          large number of forged e-mails on the Internet today.  Such
           an action would go against the explicit wishes of the
#
# Fix spelling of the word "e-mail".  Also, be consistent with other
# occurrances of the word.
#
@@ -328,3 +327,3 @@
         <t>
-          The check_host() function returns one of seven results.
+          The check_host() function returns one of several result codes.
           This section describes how software that performs the
#
# Do not "hard-code" the number of distinct result codes.
#
@@ -336,4 +335,5 @@
           <t>
-            A result of None means that no records were published by
-            the domain.  The checking software cannot ascertain if the
+            A result of "None" means that no records were published by
+            the domain, or that no checkable sender domain could be
+            determined from the given identity.  The checking software cannot 
ascertain if the
             client host is authorized or not.
#
# For consistency, always quote result codes.  Also, note the other valid
# reason why a "None" result could occur.
#
@@ -343,5 +343,6 @@
           <t>
-            The domain owner has explicitly stated that doesn't know
-            whether the IP is authorized or not.  A Neutral result
-            MUST be treated exactly like the None result.
+            The domain owner has explicitly stated that he doesn't know
+            whether the IP is authorized or not.  A "Neutral" result
+            SHOULD be treated exactly like the "None" result; the
+            distinction exists only for informational purposes.
           </t>
#
# Fix grammar: insert missing "he".  Quote result code.
# There is no point in trying to enforce local policy decisions.  We can
# make it clear that the meaning of "Neutral" is supposed to match that of
# "None", but we cannot force receivers to treat them identically.
#
@@ -350,3 +351,3 @@
           <t>
-            A Pass result means that the client is authorized to
+            A "Pass" result means that the client is authorized to
             inject mail with the given identity.  Further
@@ -358,3 +359,3 @@
           <t>
-            A Fail result is an explicit statement that the client is
+            A "Fail" result is an explicit statement that the client is
             not authorized to use the domain in the given
@@ -369,3 +370,3 @@
             target="RFC2034"/>), in addition to an appropriate
-            message.  The check_host() function may return either a
+            reply text.  The check_host() function may return either a
             default explanation string, or one from the domain that
#
# Clarify: "reply text" is the wording used by RFC 2821.
#
@@ -386,4 +387,4 @@
           <t>
-            A SoftFail result should be treated as somewhere between a
-            Fail and a Neutral.  The domain believes the host isn't
+            A "SoftFail" result should be treated as somewhere between a
+            "Fail" and a "Neutral".  The domain believes the host isn't
             authorized but isn't willing to make that strong of a
@@ -396,8 +397,4 @@
             receivers MAY try to inform either the sender or the
-            recipient of the e-mail.  As examples, the recipient's MUA
-            could highlight the SoftFail status.  Or the MTA could
-            give the sender a message using a technique called
-            "greylisting" where by the MTA can issue an SMTP reply
-            code of 451 (4.3.0 DSN code) with a note the first time
-            the message was received, but accept it the second time.
+            recipient of the e-mail.  For example, the recipient's MUA
+            could highlight the "SoftFail" status.
           </t>
#
# Drop the "greylisting" example.  The point of greylisting "SoftFail"
# messages is not evident, especially since some spammers already know how
# to circumvent greylisting.
#
@@ -406,3 +403,3 @@
           <t>
-            A TempError result means that the SPF client encountered a
+            A "TempError" result means that the SPF client encountered a
             transient error when performing the check.  Checking
@@ -417,3 +414,3 @@
           <t>
-            A PermError result means that the domain's published
+            A "PermError" result means that the domain's published
             records couldn't be correctly interpreted.  Checking
@@ -428,3 +425,3 @@
       <t>
-        An SPF record declares which hosts are, and are not,
+        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"
#
# This first paragraph about SPF records should explain right away that
# they are DNS RRs.
#
@@ -443,3 +440,3 @@
       <t>
-        This record has a version of "v=spf1" and three directives:
+        This record has a version of "spf1" and three directives:
         "+mx", "a:colo.example.com/28" (the + is implied), and "-all".
#
# The version string is not "v=spf1", but "spf1".
#
@@ -453,3 +450,3 @@
           it, such as is done with SRV records.  This is the same
-          whether TXT RRs or SPF RRs are used.
+          whether the TXT or SPF RR type is used.
         </t>
#
# Fix semantics of sentence.
#
@@ -468,12 +465,12 @@
           published there for other purposes.  They may cause problems
-          with size limits (see <xref target="rsize"/>.)
+          with size limits (see <xref target="rsize"/>).
         </t>
#
# Fix grammar.
#
         <t>
-          An SPF record published at the zone cut for the domain will
-          be used as a default for all subdomains within the zone (See
-          <xref target="version"/>.) Domain owners SHOULD publish SPF
+          An SPF record published at the zone cut for the domain is
+          considered a default for all subdomains within the zone (see
+          <xref target="version"/>).  Domain owners SHOULD publish SPF
#
# The described assumption applies to publishers and publishing software
# as well, not just to SPF checking software.  Fix grammar.
#
           records for hosts used for the HELO and MAIL FROM identities
-          instead of using the zone cut default because the fallback
+          instead of relying on the zone cut default because the fallback
#
# Domain owners AKA publishers don't "use" the zone cut default, only
# receivers do.
#
           requires additional DNS lookups.  The zone cut default does
-          reduce the need to publish SPF records for non-email related
+          reduce the need to publish SPF records for non-e-mail related
           hosts, such as www.example.com.
#
# Fix spelling of the word "e-mail".
#
@@ -482,3 +479,3 @@
           <t>
-            This document defines a new DNS Resource Record (RR) of
+            This document defines a new DNS RR of
             type SPF, type code to be determined. The format of this
#
# "DNS RR" has been explained above already (see suggested change), so use
# the abbreviation.
#
@@ -512,6 +509,8 @@
           <t>
-            An SPF compliant check SHOULD lookup both types. Lookups
-            can be performed serially or in parallel. If both types of
-            records are obtained for a domain, the SPF type MUST be
-            used.
+            An SPF compliant check SHOULD try to look up and use
+            a record of the SPF type first, before falling back to the
+            TXT type.  However, the client MAY also perform lookup
+            of both types in parallel.  If for a domain both types
+            are obtained but their contents do not match, the SPF
+            client SHOULD return a "PermError" result.
           </t>
#
# Make it clear that the SPF record type is preferred.  But if both TXT
# and SPF type records are actually obtained, make sure they are
# congruent.
#
@@ -519,3 +518,3 @@
             Example RRs in this document are shown with the TXT record
-            type, however they could also be published with both RR types.
+            type, however they could be published with the SPF type or with 
both types.
           </t>
#
# Avoid the misconception that only publishing the SPF type were
# unacceptable.
#
@@ -571,3 +570,3 @@
             are too long to fit in a single UDP packet MAY be
-            silently ignored.
+            silently ignored by SPF clients.
           </t>
#
# Clarify.
#
@@ -618,3 +617,3 @@
         The check_host() function fetches SPF records, parses them,
-        and interprets them to evaluate if a particular host is or is
+        and interprets them to determine if a particular host is or is
         not permitted to send mail with a given
@@ -625,3 +624,3 @@
         Implementations MAY use a different algorithm than the canonical
-        algorithm defined here, so long as the results are the same.
+        algorithm defined here, so long as the results are the same in all 
cases.
       </t>
@@ -632,6 +631,7 @@
             <t hangText="&lt;ip&gt;">- the IP address of the SMTP client
-              that is injecting the mail, either IPv4 or IPv6.
+              that is emitting the mail, either IPv4 or IPv6.
             </t>
-            <t hangText="&lt;domain&gt;">- the domain portion of the
-              "MAIL FROM" or "HELO" identity.
+            <t hangText="&lt;domain&gt;">- the domain that provides the
+              sought-after authorization information; initially the
+              domain portion of the "MAIL FROM" or "HELO" identity.
             </t>
#
# Mention the point that <domain> is not constant, and more accurately
# explain its meaning.
#
@@ -645,3 +645,3 @@
           same as the &lt;domain&gt; argument when check_host() is
-          initially evaluated. However, it will generally not be true for
+          initially evaluated. However, this will generally not be true for
           recursive evaluations (see <xref target="mech-include"/>
@@ -650,5 +650,5 @@
         <t>
-          Actual implementations of the check_host() function will
-          likely need additional arguments.
-          </t>
+          Actual implementations of the check_host() function may
+          need additional arguments.
+        </t>
       </section>
#
# It is not clear why implementations of check_host() would "likely" need
# additional arguments.
#
@@ -656,3 +656,3 @@
         <t>
-          The function check_host() can result in one of seven results
+          The function check_host() can return one of several results
           described in <xref target="op-result"/>. Based on the
#
# "To result in a result" is poor wording.  Also, do not "hard-code" the
# number of distinct result codes.
#
@@ -678,3 +678,3 @@
           for the &lt;domain&gt; name, querying for either RR type
-          TXT, SPF or both.
+          TXT, SPF, or both.
         </t>
#
# Fix grammar.
#
@@ -721,3 +721,3 @@
         <t>
-          If no matching records are returned for the &lt;domain;&gt;,
+          If no matching records are returned for the &lt;domain&gt;,
           the SPF client MUST find the Zone Cut as defined in <xref
@@ -758,4 +758,4 @@

-directive        = [ prefix ] mechanism
-prefix           = "+" / "-" / "?" / "~"
+directive        = [ sign ] mechanism
+sign             = "+" / "-" / "?" / "~"
 mechanism        = ( all / include
#
# The term "prefix" is too generic.
#
@@ -794,3 +794,3 @@
           <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
@@ -801,3 +801,3 @@
           <t>
-            The possible prefixes, and the results they return are:
+            The possible signs, and the results they return are:
             <list style="hanging">
@@ -809,5 +809,5 @@
           </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 "-" so that a
+            When a mechanism matches and the sign is "-", then a
             "Fail" result is returned and the explanation string is
#
# Fix grammar/semantics.
#
@@ -815,3 +815,3 @@
           </t>
-          <t> Specific mechanisms are described in <xref 
target="mechanisms"/>. </t>
+          <t> The specific mechanisms are described in <xref 
target="mechanisms"/>. </t>
         </section>
#
# Fix semantics.
#
@@ -821,3 +821,3 @@
             not-match.  Instead they provide additional information.
-            While modifiers do not directly effect the evaluation of
+            While modifiers do not directly affect the evaluation of
             the record, the "redirect" modifier has an effect after
@@ -831,3 +831,3 @@
           modifier, then the check_host() returns a result of
-          "Neutral". If there is a "redirect" modifier, check_host()
+          "Neutral", just as if "?all" were specified as the last directive.  
If there is a "redirect" modifier, check_host()
           proceeds as defined in <xref target="mod-redirect"/>.
#
# Clarify.
#
@@ -964,7 +964,9 @@
           In hind sight, the name "include" was poorly chosen.  Only
-          the evaluated results of the referenced SPF record is used,
+          the evaluated result of the referenced SPF record is used,
#
# Fix grammar.
#
           rather than acting as if the referenced SPF record was
-          literally included in the first. Better names for this
-          mechanism would have been something like "on-pass" or
-          "if-pass".
+          literally included in the first.  For example, evaluating a
+          "-all" directive in the referenced record does not terminate
+          the overall processing and does not necessarily result in a
+          overall "Fail".  Better names for this mechanism would have
+          been "call", "eval, "on-pass", or "if-pass".
         </t>
#
# Clarify.  Also, suggest better names for the "include" mechanism.
#
@@ -985,3 +987,3 @@
           That would direct check_host() to, in effect, check the
-          records of example.com and example.org for a "pass"
+          records of example.com and example.org for a "Pass"
           result. Only if the host were not permitted for either of
@@ -1056,4 +1058,5 @@
           each MX name returned. The &lt;ip&gt; is compared to each
-          returned IP address. To prevent DoS attacks, a limit of 10
-          MX names MUST be enforced (see <xref target="security" />).
+          returned IP address. To prevent DoS attacks, more than 10
+          MX names MUST NOT be looked up during the evaluation of a
+          "mx" mechanism (see <xref target="security" />).
           If any address matches, the mechanism matches.
#
# Clarify.
#
@@ -1088,4 +1091,5 @@
           name by looking up its IP address.  To prevent DoS attacks,
-          a limit of 10 PTR names MUST be enforced (see <xref
-          target="security" />).  If &lt;ip&gt; is among the returned
+          more than 10 PTR names MUST NOT be looked up during the
+          evaluation of a "ptr" mechanism (see <xref target="security" />).
+          If &lt;ip&gt; is among the returned
           IP addresses, then that domain name is validated. In
#
# Clarify.
#
@@ -1153,3 +1157,2 @@
 ip6-cidr-length  = "/" 1*DIGIT
-dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

#
# Drop irrelevant ABNF rule.  (It's still in the collected ABNF, though.)
#
@@ -1227,5 +1230,5 @@
       <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 handle records with modifiers that are
+        this document to gracefully handle records with modifiers that are
         defined in other specifications.
#
# There is no point in not strictly requiring unrecognized modifiers to be
# ignored.  What should implementations do if they choose not to ignore
# them?
#
@@ -1278,3 +1281,3 @@
           same, there is no guarantee that the record at domain "B"
-          will correctly work for addresses in domain "A", especially
+          will correctly work for mailboxes in domain "A", especially
           if domain "B" uses mechanisms involving localparts. An
#
# Use the term "mailbox" instead of "address" or "e-mail address" for
# consistency, just like Mark Lentczner did everywhere.
#
@@ -1386,6 +1389,6 @@
         <t>
-          Note: During recursion into an "include" mechanism, exp=
-          modifiers do not propagate out.  In contrast, during
-          execution of a "redirect" modifier, the explanation string
-          from the target of the redirect is used.
+          Note: During recursion into an "include" mechanism, an exp=
+          modifier from the target domain MUST NOT be used.  In
+          contrast, when executing a "redirect" modifier, an exp=
+          modifier from the original domain MUST NOT be used.
         </t>
#
# "Do not propagate out"?  Huh?  Clarify.  Also, make behavior a strict
# requirement.
#
@@ -1426,11 +1429,10 @@
         <t>
-          SPF implementations MUST limit the number of mechanism that
-          do DNS lookups to at most 10, if this number is exceeded, a
-          PermError MUST be returned.  The mechanisms that count
-          against this limit are "include", "a", "mx", "ptr", "exists"
-          and the "redirect" modifier.  The "all", "ip4" and "ip6"
+          SPF client implementations MUST limit the number of mechanisms
+          and modifiers that do DNS lookups to at most 10 per SPF check.
+          If this number is exceeded during a check, a PermError MUST be
+          returned.  The "include", "a", "mx", "ptr", and "exists"
+          mechanisms as well as the "redirect" and "exp" modifiers do
+          count against this limit.  The "all", "ip4" and "ip6"
           mechanisms do not require DNS lookups and therefore do not
-          count against this limit.  The "exp" modifier requires a DNS
-          lookup, but it is not counted as it is used only in the case
-          of errors.
+          count against this limit.
         </t>
#
# Only _client_ implementations should be concerned by this.  Explicitly
# mention modifiers in this requirement.
# Also, there is no point in excluding the "exp" modifier just because "it
# is used only in the case of errors".  Attackers will not care about it
# only being used in the case of errors, and thus might exploit such an
# exemption.
#
@@ -1498,3 +1500,3 @@
           defined here.  This information is intended for the
-          recipient.  (Information intended for the sender described
+          recipient.  (Information intended for the sender is described
           in <xref target="mod-exp"/>, Explanation.)
@@ -1502,3 +1504,3 @@
         <t>
-          The Received-SPF header is a trace field (See <xref
+          The Received-SPF header is a trace field (see <xref
           target="RFC2822"/> section 3.6.7) and SHOULD be
@@ -1512,7 +1514,7 @@
             <artwork type="abnf">
-header           = "Received-SPF:" [CFWS] result [CFWS]
+header           = "Received-SPF:" [CFWS] result [FWS [comment]]
                    [ key-value-list ]
#
# Although the semantics were already correct, the <comment> string should
# be explicitly mentioned so that the below text can refer to it.
#

-result           = "Pass" / "Fail" / "TempError" / "SoftFail" /
-                   "Neutral" / "None" / "PermError"
+result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
+                   "None" / "TempError" / "PermError"

#
# Re-order the result codes intelligently.
#
@@ -1524,6 +1526,6 @@
 dot-atom         = ; unquoted word as per [RFC2822]
-
 quoted-string    = ; quoted string as per [RFC2822]
-
+comment          = ; comment string as per [RFC2822]
 CFWS             = ; comment or folding white space as per [RFC2822]
+FWS              = ; folding white space as per [RFC2822]
             </artwork>
#
# Define <comment> and <FWS>.  Drop unnecessary blank lines.
#
@@ -1532,3 +1534,4 @@
         <t>
-          The &lt;comment-string&gt; should convey supporting
+          The header SHOULD include a "(...)" style <comment> after the
+          result, conveying supporting
           information for the result, such as &lt;ip&gt;,
#
# Clarify.
#
@@ -1544,3 +1547,3 @@
             <t hangText="client-ip">      the IP address of the SMTP client</t>
-            <t hangText="envelope-from">  the envelope sender address</t>
+            <t hangText="envelope-from">  the envelope sender mailbox</t>
             <t hangText="helo">           the host name given in the HELO
@@ -1626,3 +1629,3 @@
         <t>
-          Many mechanisms and modifiers perform macro interpolation on
+          Many mechanisms and modifiers perform macro expansion on
           part of the term.
@@ -1633,2 +1636,3 @@
 domain-end       = ( "." toplabel ) / macro-expand
+
 toplabel         = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
#
# Insert a blank line to make the ABNF more readable.
#
@@ -1636,5 +1640,7 @@
 alphanum         = ALPHA / DIGIT
-macro-string     = *( macro-expand / macro-literal )
+
 explain-string   = *( macro-string / SP )
-macro-expand     = ( "%{" macro-letter transformer *delimiter "}" )
+
+macro-string     = *( macro-expand / macro-literal )
+macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
                    / "%%" / "%_" / "%-"
#
# Insert blank lines to make the ABNF more readable.  Also, swap around
# the definitions of "macro-string" and "explain-string" for the same
# reason.
# Rename the "transformer" item into "transformers", as it stands for
# multiple transformers, not just for a single one.
#
@@ -1644,3 +1650,3 @@
                    "c" / "r" / "t"
-transformer      = *DIGIT [ "r" ]
+transformers     = *DIGIT [ "r" ]
 delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
#
# Rename the "transformer" item into "transformers".  See above.
#
@@ -1742,3 +1748,3 @@
           The "s" macro expands to the &lt;sender&gt; argument. It is
-          an e-mail address with a localpart, an "@" character, and a
+          a mailbox address with a localpart, an "@" character, and a
           domain. The "l" macro expands to just the localpart. The "o"
@@ -1770,3 +1776,3 @@
           any name from the list may be used.  If there are no
-          validated domain name or if a DNS error occurs, the string
+          validated domain names or if a DNS error occurs, the string
           "unknown" is used.
#
# Fix grammar.
#
@@ -1776,5 +1782,5 @@
           SHOULD be a fully qualified domain name, but if one does not
-          exist (as when the checking is done by a script) or if
+          exist (as when the checking is done by a MUA) or if
#
# "A script"?  Huh?
#
           policy restrictions dictate otherwise, the word "unknown"
-          should be substituted. The domain name may be different than
+          SHOULD be substituted. The domain name may be different than
           the name found in the MX record that the client MTA used to
#
# Make the statement a formal recommendation.
#
@@ -1793,3 +1799,3 @@
           (the maximum length of a domain name), the left side is
-          truncated to fit, by removing successive subdomains until
+          truncated to fit, by removing successive domain labels until
           the total length does not exceed 253 characters.
@@ -1799,6 +1805,6 @@
           equivalents, and are then URL escaped. URL escaping for the
-          non-uric characters is described in <xref target="RFC2396"/>.
+          non-URIish characters is described in <xref target="RFC2396"/>.
         </t>
#
# Is "uric" supposed to be a pun on the word "urine"?  No, thanks.
#
         <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
#
# Make statement a formal recommendation.
#
@@ -1855,13 +1861,13 @@
 %{lr-}.lp.%{ir}.%{v}._spf.%{d2}
-bad.strong.lp.3.2.0.192.in-addr._spf.example.com
+                    bad.strong.lp.3.2.0.192.in-addr._spf.example.com

 %{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
-3.2.0.192.in-addr.strong.lp._spf.example.com
+                        3.2.0.192.in-addr.strong.lp._spf.example.com

 %{d2}.trusted-domains.example.net
-example.com.trusted-domains.example.net
+                             example.com.trusted-domains.example.net

 IPv6:
-%{ir}.%{v}._spf.%{d2}         1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.
-5.d.a.0.8.0.0.0.2.5.0.f.5.ip6._spf.example.com
+%{ir}.%{v}._spf.%{d2}                               1.0.0.0.0.0.0.0.
+0.0.0.0.0.0.0.0.0.0.8.5.d.a.0.8.0.0.0.2.5.0.f.5.ip6._spf.example.com
           </artwork>
#
# Align the expanded strings to the right to make the examples more
# readable.
#
@@ -1896,3 +1902,3 @@
           "tracking exists:" mechanism.  By looking at the name server
-          logs, an incompletely list may be generated. For example:
+          logs, an rough list may then be generated. For example:
           <list>
#
# Fix grammar/semantics.
#
@@ -1906,3 +1912,3 @@
         <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
@@ -1910,3 +1916,3 @@
           <xref target="RFC1123"/> Section 5.3.6 that say that the
-          reverse-path MUST be changed to be the address of a person
+          reverse-path MUST be changed to be the mailbox of a person
           or other entity who administers the list.  While the reasons
@@ -1918,3 +1924,3 @@
           complies with this requirement.  Mailing lists that do not
-          comply, may or may not encounter problems depending on how
+          comply may or may not encounter problems depending on how
           access to the list is restricted.  Such lists that are
#
# Fix grammar.
#
@@ -1929,3 +1935,3 @@
           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
@@ -1941,3 +1947,3 @@
           mailbox wishes to trust the forwarding service, they can
-          direct the external mailbox's MTA to skip such tests when
+          direct the external mailbox's MTA to skip SPF tests when
           the client host belongs to the forwarding service.  Tests
#
# Clarify.
#
@@ -1954,4 +1960,4 @@
         <t>
-          Forwarding services can also solve the problem by using
-          MAIL FROM that contain their own domain.  This means
+          Forwarding services can also solve the problem by rewriting the
+          MAIL FROM to be in their own domain.  This means
           that mail bounced from the external mailbox will have to be
#
# Clarify.
#
@@ -1960,8 +1966,8 @@
           resource requirements on the part of the forwarding service.
-          Several popular MTAs can change "alias" semantics to
-          "mailing list" semantics by including an adding another
-          alias with "owner-" added to the beginning of the alias
-          name.  (e.g. an alias of "friends: george(_at_)example(_dot_)com,
+          Also, several popular MTAs can be forced from "alias" semantics to
+          "mailing list" semantics by configuring an additional
+          alias with "owner-" prepended to the original alias
+          name (e.g. an alias of "friends: george(_at_)example(_dot_)com,
#
# Improve wording.
#
           fred(_at_)example(_dot_)org" would need another alias of the form
-          "owner-friends: localowner")
+          "owner-friends: localowner").
         </t>
#
# Fix grammar.
#
@@ -1970,7 +1976,7 @@
         <t>
-          Entities that offer mail services to other domains such as
-          sending of bulk mail will may have to alter their mail in
-          light of the authorization check in this document.  If the
+          Service providers that offer mail services to third party domains, 
such as
+          sending of bulk mail, may have to adjust their setup in
+          light of the authorization check described in this document.  If the
           MAIL FROM used for such e-mail uses the domain of the
-          mail service provider, then the provider needs only to
+          service provider, then the provider needs only to
           ensure that their sending host is authorized by their own
#
# Improve wording.
#
@@ -1981,4 +1987,4 @@
           domain, then extra care must be taken.  The SPF record
-          format has several options for authorizing the sending MTAs
-          of another domain (the service provider's)
+          format has several options for the third party domain to authorize
+          the service provider's MTAs to send mail on its behalf.
         </t>
#
# Improve wording.
#
@@ -1993,4 +1999,4 @@
           However, for purposes of this document, such relays are effectively
-          invisible.  The "MAIL FROM" identity authorization check is a check
-          between border MTAs.
+          transparent.  The "MAIL FROM" identity authorization check is a check
+          between border MTAs of different domains.
         </t>
#
# Improve wording.  Clarify.
#
@@ -2004,3 +2010,4 @@
           Mail receivers will generally want to perform the authorization check
-          at the border MTAs.  This allows mail that fails to be rejected
+          at the border MTAs, specifically including all secondary MXes.
+          This allows mail that fails to be rejected
           during the SMTP session rather than bounced.  Internal MTAs then do
#
# Clarify.
#
@@ -2018,3 +2025,3 @@
         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
@@ -2068,3 +2075,3 @@
           <t>
-            While implementations of check_host() need to limit the
+            While implementations of check_host() are supposed to limit the
             number of DNS lookups, malicious domains could publish
#
# Fix semantics.
#
@@ -2132,3 +2139,3 @@
       <t>
-        Philip Gladstone contributed macros to the specification,
+        Philip Gladstone contributed the concept of macros to the 
specification,
         multiplying the expressiveness of the language and making
#
# Fix semantics.
#
@@ -2139,3 +2146,3 @@
         individuals who have participated in the development of this
-        design.  There are far too numerous to name, but they include:
+        design.  They are far too numerous to name, but they include:
       </t>
#
# Fix grammar.
#
@@ -2269,5 +2276,7 @@
 alphanum         = ALPHA / DIGIT
-macro-string     = *( macro-expand / macro-literal )
+
 explain-string   = *( macro-string / SP )
-macro-expand     = ( "%{" macro-letter transformer *delimiter "}" )
+
+macro-string     = *( macro-expand / macro-literal )
+macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
                    / "%%" / "%_" / "%-"
#
# Replicate inline ABNF grammar changes from above.
#
@@ -2277,3 +2286,3 @@
                    "c" / "r" / "t"
-transformer      = *DIGIT [ "r" ]
+transformers     = *DIGIT [ "r" ]
 delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
#
# Replicate...
#
@@ -2282,7 +2291,7 @@

-header           = "Received-SPF:" [CFWS] result [CFWS]
+header           = "Received-SPF:" [CFWS] result [FWS [comment]]
                    [ key-value-list ]

-result           = "Pass" / "Fail" / "TempError" / "SoftFail" /
-                   "Neutral" / "None" / "PermError"
+result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
+                   "None" / "TempError" / "PermError"

#
# Replicate...
#
@@ -2294,6 +2303,6 @@
 dot-atom         = ; unquoted word as per [RFC2822]
-
 quoted-string    = ; quoted string as per [RFC2822]
-
+comment          = ; comment string as per [RFC2822]
 CFWS             = ; comment or folding white space as per [RFC2822]
+FWS              = ; folding white space as per [RFC2822]
         </artwork>
#
# Replicate...
#
@@ -2307,8 +2316,7 @@
 ; and two servers at the domain name
-
 $ORIGIN example.com.
 @           MX  10 mail-a
-MX  20 mail-b
-A   192.0.2.10
-A   192.0.2.11
+            MX  20 mail-b
+            A   192.0.2.10
+            A   192.0.2.11
 amy         A   192.0.2.65
#
# Fix formatting.
#
@@ -2320,4 +2328,3 @@
 ; A related domain
-
-$ORIGIN example.org
+$ORIGIN example.org.
 @           MX  10 mail-c
@@ -2326,3 +2333,2 @@
 ; The reverse IP for those addresses
-
 $ORIGIN 2.0.192.in-addr.arpa.
@@ -2338,3 +2344,2 @@
 ; something it's not
-
 $ORIGIN 0.0.10.in-addr.arpa.
@@ -2411,4 +2416,4 @@
           This record would be used if mail from example.org actually came
-          through servers at example.com and example.net. Example.org's
-          designated servers are the union of example.com and example.net'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.
#
# Fix syntax and grammar.
#
@@ -2425,3 +2430,3 @@
           system to make use of that mail system's record. In this way, only 
the
-          mail system's record needs to updated when the mail setup changes.
+          mail system's record needs to be updated when the mail setup changes.
           These domains' records never have to change.
#
# Fix grammar.
#
@@ -2436,3 +2441,3 @@
           <artwork>
-$Origin _spf.example.com.
+$ORIGIN _spf.example.com.
 mary.mobile-users                   A 127.0.0.2
#
# Improve formatting.
#

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

Attachment: draft-schlitt-spf-classic-00-mehnle.xml.diff
Description: Binary data