diff --git a/RELEASE_NOTES b/RELEASE_NOTES index 44ca9f0..b1d4f33 100644 --- a/RELEASE_NOTES +++ b/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 diff --git a/SECURITY/CVE-2019-20790 b/SECURITY/CVE-2019-20790 index d93bb14..937be5e 100644 --- a/SECURITY/CVE-2019-20790 +++ b/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 smtp.mailfrom=user@example.com, 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. +