Removed non-ASCII punctuation mark

draft-ietf-dmarc-dmarcbis-35.html

@@ -3541,7 +3541,7 @@ <h3 id="name-issues-specific-to-spf">
 on behalf of the Domain Owner before publishing a DMARC Policy Record. Furthermore,
 Domain Owners should periodically review their SPF records to ensure that
 the authorization conveyed by the records matches the domain's current needs.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
-<p id="section-7.1-2">SPF was intended to be implemented early in the SMTP transaction, meaning it<span class="unicode">‘ (U+2018)</span>s
+<p id="section-7.1-2">SPF was intended to be implemented early in the SMTP transaction, meaning it's
 possible for a message to fail SPF validation prior to any message content being
 transmitted, and so some Mail Receiver architectures might implement SPF in
 advance of any DMARC operations. This means that an SPF hard fail ("-") prefix

draft-ietf-dmarc-dmarcbis-35.txt

@@ -2144,25 +2144,24 @@ Internet-Draft                  DMARCbis                   November 2024
    needs.
 
    SPF was intended to be implemented early in the SMTP transaction,
-   meaning it‘ (U+2018)s possible for a message to fail SPF validation
-   prior to any message content being transmitted, and so some Mail
-   Receiver architectures might implement SPF in advance of any DMARC
-   operations.  This means that an SPF hard fail ("-") prefix on a
-   sender's SPF mechanism, such as "-all", could cause a message to be
-   rejected early in the SMTP transaction, before any DMARC processing
-   takes place, if the message fails SPF authentication checks.  Domain
-   Owners choosing to use "-all" to terminate SPF records should be
-   aware of this, and should understand that messages that might
-   otherwise pass DMARC due to an aligned DKIM-Authenticated Identifier
-   (#dkim-identifiers) could be rejected solely due to an SPF fail.
-   Moreover, messages rejected early in the SMTP transaction will never
-   appear in aggregate DMARC reports, as the transaction will never
-   proceed to the DATA phase and so the RFC5322.From domain will never
-   be revealed and its DMARC policy will never be discovered.  Domain
-   Owners and Mail Receivers (#mail-receiver) can consult [M3SPF] and
-   [M3AUTH] for more discussion of the topic and best practices
-   regarding publishing SPF records and when to reject based solely on
-   SPF failure:
+   meaning it's possible for a message to fail SPF validation prior to
+   any message content being transmitted, and so some Mail Receiver
+   architectures might implement SPF in advance of any DMARC operations.
+   This means that an SPF hard fail ("-") prefix on a sender's SPF
+   mechanism, such as "-all", could cause a message to be rejected early
+   in the SMTP transaction, before any DMARC processing takes place, if
+   the message fails SPF authentication checks.  Domain Owners choosing
+   to use "-all" to terminate SPF records should be aware of this, and
+   should understand that messages that might otherwise pass DMARC due
+   to an aligned DKIM-Authenticated Identifier (#dkim-identifiers) could
+   be rejected solely due to an SPF fail.  Moreover, messages rejected
+   early in the SMTP transaction will never appear in aggregate DMARC
+   reports, as the transaction will never proceed to the DATA phase and
+   so the RFC5322.From domain will never be revealed and its DMARC
+   policy will never be discovered.  Domain Owners and Mail Receivers
+   (#mail-receiver) can consult [M3SPF] and [M3AUTH] for more discussion
+   of the topic and best practices regarding publishing SPF records and
+   when to reject based solely on SPF failure:
 
 7.2.  Rejecting Messages
 
@@ -2181,6 +2180,7 @@ Internet-Draft                  DMARCbis                   November 2024
 
 
 
+
 Herr (ed) & Levine (ed)    Expires 15 May 2025                 [Page 39]
 
 Internet-Draft                  DMARCbis                   November 2024

draft-ietf-dmarc-dmarcbis-35.xml

@@ -1432,7 +1432,7 @@ their SPF records to understand which networks are authorized to send
 on behalf of the Domain Owner before publishing a DMARC Policy Record. Furthermore,
 Domain Owners should periodically review their SPF records to ensure that
 the authorization conveyed by the records matches the domain's current needs.</t>
-<t>SPF was intended to be implemented early in the SMTP transaction, meaning it<u format="char-num">‘</u>s
+<t>SPF was intended to be implemented early in the SMTP transaction, meaning it's
 possible for a message to fail SPF validation prior to any message content being
 transmitted, and so some Mail Receiver architectures might implement SPF in
 advance of any DMARC operations. This means that an SPF hard fail (&quot;-&quot;) prefix

draft-ietf-dmarc-dmarcbis.md

@@ -1440,7 +1440,7 @@ on behalf of the Domain Owner before publishing a DMARC Policy Record. Furthermo
 Domain Owners should periodically review their SPF records to ensure that
 the authorization conveyed by the records matches the domain's current needs.
 
-SPF was intended to be implemented early in the SMTP transaction, meaning it‘s 
+SPF was intended to be implemented early in the SMTP transaction, meaning it's 
 possible for a message to fail SPF validation prior to any message content being
 transmitted, and so some Mail Receiver architectures might implement SPF in 
 advance of any DMARC operations. This means that an SPF hard fail ("-") prefix