Fix more CVE releases notes

RELEASE_NOTES

@@ -4,6 +4,17 @@ This listing shows the versions of the OpenDMARC package, the date of
 release, and a summary of the changes in that release.
 
 1.4.1		2021/03/??
+
+	NOTE: In response to CVE-2019-20790, opendmarc has changed
+		how it evaluates headers added by previous
+		SPF milters.  Users are encouraged to read the
+		CVE-2019-20790 file in the "SECURITY" folder
+		for more details. (#49, #158)
+	NOTE: OpenDMARC's internal SPF handling will be removed
+		in a future version.  Users are encouraged to
+		build linked against libspf2.  Many pre-built 
+		packages provided by OS packagers
+		already do this.  (https://www.libspf2.org)
 	Addition of defines for MUSL C Library. (#129/#133).  Patches by
 		Marco Rebhan.
 	Updated opendmarc.conf manpage and opendmarc.conf.sample to point to 

SECURITY/CVE-2019-20790

@@ -5,37 +5,67 @@ with the MAIL FROM field.
 
 Link: https://nvd.nist.gov/vuln/detail/CVE-2019-20790
 
-Details: While the SPF RFC (RFC 7208) says that entities MUST check 
-the envelope sender during an SPF check (Section 2.4), Section 2.3 also
-says that checking the HELO/EHLO string is RECOMMENDED.  
-
-It further states (Section 2.3): 
-
-    If a conclusive determination about the message can be made based on 
-    a check of "HELO", then the use of DNS resources to process the typically 
-    more complex "MAIL FROM" can be avoided.
-
-The HELO string is trivially forgeable and can be set to any value by 
-anyone delivering mail to a system.  It does not depend on the hostname 
-of the transmitting system.  There is no guarantee that the HELO value
-will be validated by the receiving system.  Moreover, RFC 5321 (the
-current SMTP specification) says:
-
-    An SMTP server MAY verify that the domain name argument in the EHLO
-    command actually corresponds to the IP address of the client.
-    However, if the verification fails, the server MUST NOT refuse to
-    accept a message on that basis. 
-
-Resolution/Workaround: It is the job of OpenDMARC to trust information 
-provided to it by upstream filters.  OpenDMARC itself can be configured 
-to validate SPF, but there are use cases where OpenDMARC may be running 
-further inside a network and not have access to the connection strings as 
-logged.  No standard exists for relaying the IP address of the client
-to inward systems when relaying occurs.
-
-It is the view of the OpenDMARC developers that this is working as 
-designed, but if this behavior is undesirable, then any filter that adds 
-a Received-SPF header field should not set a spf=pass result based solely on
-the HELO/EHLO string.  It is not the job of OpenDMARC to second-guess other 
-filters in the chain, but simply to compare their stated values and make 
-a weight-based judgement.
+Summary: opendmarc has added options to validate the Received-SPF: and 
+spf-based Authentication-Results: headers as are added by some SPF 
+validating implementations.
+
+Details:
+
+For the Received-SPF header field, opendmarc will not accept a result 
+delivered via a discovered Received-SPF header field unless, in 
+addition to stating "pass":
+
+(a) it includes the "identity" key and its value is "mailfrom", 
+
+AND 
+
+(b) it includes the "envelope-from" key and its value matches the envelope 
+sender we got via milter.  
+
+AND
+
+(c) per RFC 7208, that it is the topmost header field of its kind.
+
+If any of those tests fails, a "pass" or a "fail" is interpreted 
+as "neutral".  This is necessary to be compliant with RFC 7489 Section 4.1,
+which says the SPF evaluation of MAIL FROM is what DMARC consumes.
+
+For the Authentication-Results header field, in addition to requiring
+a "spf=pass" key/value, we now require that:
+
+(a) The smtp.mailfrom key be present
+
+AND
+
+(b) The domain portion of the value of the above key matches the 
+envelope sender as above.  
+
+Note carefully that many elements of both of the above header fields
+that are relied upon for opendmarc to validate SPF processing by an 
+earlier filter in the chain are not required by the RFC.
+
+Some filters can set [email protected], others can 
+set smtp.mailfrom=example.com.  RFC 7001, which defines the
+Authentication-Results header field allows both.
+
+In fact even the presence of a Received-SPF or Authentication-Results 
+header field at all is not required.
+
+Admins are encouraged to carefully evaluate which header fields and
+keys/values their milters add, and that it provides enough information
+for opendmarc to make a decision.
+
+Note that some mail filters may generate an SPF pass based on the
+HELO result, which OpenDMARC will not accept.
+
+This can result in the presence of a header which indicates that
+SPF passed, but via an identity that DMARC does not consider, which
+may be misleading to both users and admins.
+
+Even if you are validating SPF earlier in your mail stream, for 
+example to hard-reject mail from SPF-failing domains which set "-all",
+you may wish to have OpenDMARC do its own SPF lookups, which
+requires enabling at compile-time.  See the options "SPFIgnoreResults"
+and "SPFSelfValidate" in either opendmarc.conf.sample or the
+opendmarc.conf manpage.
+