--- draft-schlitt-spf-classic-01pre5.xml	2005-05-06 00:35:37.000000000 +0200
+++ draft-schlitt-spf-classic-01pre5+mehnle.xml	2005-05-08 03:07:56.903923982 +0200
@@ -231,5 +231,5 @@
           described in <xref target="records"/>.  This record
           authorizes the use of the domain name in the "HELO" and
-          "MAIL FROM" identity, by some sending MTAs, and not by
+          "MAIL FROM" identities, by some sending MTAs, and not by
           others.
         </t>
@@ -298,5 +298,5 @@
           formed domain name.  For example, if the reverse-path was
           null, then the EHLO/HELO domain is used, with its associated
-          problems. (see <xref target="helo-ident" />)  In these
+          problems (see <xref target="helo-ident"/>).  In these
           cases, check_host() is defined in <xref target="initial"/>
           to return a "None" result.
@@ -324,5 +324,5 @@
           checks to return "none" because no SPF record can be found,
           it has long been the policy of many MTAs to reject e-mail
-          from such domains, especially in the MAIL FROM. In order to
+          from such domains, especially in the "MAIL FROM". In order to
           prevent the circumvention of SPF records, rejecting e-mail
           from invalid domains should be considered.
@@ -492,5 +492,5 @@
         <figure>
           <artwork>
-   example.com.          IN TXT "v=spf1 +mx a:colo.example.com -all"
+   example.com.          IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
    smtp-out.example.com. IN TXT "v=spf1 a -all"
           </artwork>
#
# You had removed "/28" from the end of line 494, probably due to line
# length limits.  But that made the example inconsistent with the other
# examples in section 3.  Either change all of them, or none.
#
@@ -1839,5 +1839,5 @@
         <t>
           Forwarding services take mail that is received at a mailbox
-          and directs it to some external mailbox.  At the time of this
+          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
#
# You had done s/direct/directs/, but this is grammatically wrong.
#
@@ -1883,5 +1883,5 @@
                   While this requires an extra DNS lookup, this only
                   happens when the e-mail would otherwise be rejected
-                  as not coming from a known, good source.
+                  as not coming from a known good source.
                 </t>
                 <t>
@@ -1954,5 +1954,5 @@
           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
+          this document.  If the "MAIL FROM" identity used for such e-mail uses
           the domain of the service provider, then the provider needs
           only to ensure that their sending host is authorized by
@@ -1960,5 +1960,5 @@
         </t>
         <t>
-          If the "MAIL FROM" does not use the mail service provider's
+          If the "MAIL FROM" identity does not use the mail service provider's
           domain, then extra care must be taken.  The SPF record
           format has several options for the third party domain to
@@ -2001,5 +2001,5 @@
     </section>
     <section title="Security Considerations" anchor="security">
-      <section title="SPF-Authorized E-Mail May Still Be UBE">
+      <section title="SPF-Authorized E-Mail May Be UBE">
         <t>
           The "MAIL FROM" and "HELO" identity authorizations must not be
#
# You had added the word "Still", but this insinuates that SPF makes, in
# some way, an assertion about the UBE-ishness of messages, the exact
# notion of which this section is trying to refute according to its title.
# IMO, the section title is significantly better without the word "Still".
#
@@ -2071,5 +2071,5 @@
             </t>
             <t>
-              Malicious parties could send a large volume mail
+              Malicious parties could send a large volume of mail
               purporting to come from the intended target to a wide
               variety of legitimate mail hosts.  These legitimate
#
# Fix semantics.  "a large volume mail" means a single message of great
# size, which is inappropriate here.
#
@@ -2167,6 +2167,6 @@
         <t>
           SPF uses information supplied by third parties, such as the
-          "HELO" domain name, the "MAIL FROM" and SPF records.  This
-          information is then sent to the receiver in the Received-SPF:
+          "HELO" domain name, the "MAIL FROM" address, and SPF records.  This
+          information is then passed to the receiver in the Received-SPF:
           mail headers and possibly returned to the client MTA in the
           form of an SMTP rejection message.  This information must be
#
# Improve wording.
#
@@ -2181,7 +2181,7 @@
           who is sending e-mail and likely to which MTA the e-mail is
           being sent to.  This can introduce some privacy
-          concerns, which may be more or less of an issue
+          problems, 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.
+          domain owner and the person sending the e-mail.
         </t>
       </section>
#
# "introduce concerns" isn't any better than "introduce considerations".
# It's still bad style.  Let's try "introduce problems".
#