Fix "header" vs. "header field" where appropriate.

SECURITY/CVE-2019-13678

@@ -17,17 +17,17 @@ same section) that all domains be tested, and the strictest policy be
 applied.
 
 However, having even two distinct administrative domains in the same From: 
-header (for example, [email protected], [email protected]) leads to an issue: 
+header field (for example, [email protected], [email protected]) leads to an issue: 
 
 * For SPF, mail can only be delivered to a receiving system from one IP  
   address.  Unless that IP address is (coincidentally or intentionally) in both 
   domains' SPF records (or the domains "include:" each other), then the SPF 
   check will fail (forged HELO's notwithstanding).
 
 * For DKIM, there can only be one selector/domain in a given DKIM-Signature, 
-  referencing a single "From:" header.  So in the case where either domain 
-  specifies a DMARC policy of either p=reject or p=quarantine, the result 
-  will be a failure.  The message would have to bear valid signatures
+  referencing a single "From:" header field.  So in the case where either
+  domain specifies a DMARC policy of either p=reject or p=quarantine, the
+  result will be a failure.  The message would have to bear valid signatures
   from both domains.
 
 In practice, citing the example above, a message cannot have been signed 
@@ -66,5 +66,5 @@ containing a multi-valued From: field.  If set, messages can be rejected at
 receipt-time.  If unset, messages will be ignored by the filter.  (They will 
 not pass, but they will not fail).
 
-The Authentication-results header added for the DMARC check in this case will 
-have a result of dmarc=permerror.
+The Authentication-results header field added for the DMARC check in this case
+will have a result of dmarc=permerror.

SECURITY/CVE-2020-12272

@@ -7,7 +7,7 @@ results, as demonstrated by the "example.net(.example.com" substring.
 Link: https://nvd.nist.gov/vuln/detail/CVE-2020-12272
 
 Resolution: OpenDMARC has added checking to validate that the domain
-element in both SPF and DKIM headers being inspected argument contains 
+element in both SPF and DKIM header fields being inspected argument contains 
 only valid domain name characters.  This has been fixed as of
 OpenDMARC 1.4.1 (March 2021).  While not mentioned in the CVE, fixes 
 are in a soon-to-be released branch of OpenDKIM as well so that a