On 1/22/2015 8:59 PM, Kurt Andersen wrote:
I think that the crux of the issue is this:
1) The DMARC spec was written with 4408 as context. That remains true
today, except that in the meantime 7208 was finalized (thanks to
SPFbis) and Murray was seeking to keep up with the times by following
the "7208 obsoletes 4408" statement.
2) The key problem is that 7208 changes the checking precedence.
Here's what the two specs actually say:
4408, section 2.2: "SPF clients MUST check the "MAIL FROM" identity."
7208, section 2.4: "SPF verifiers MUST check the "MAIL FROM" identity
if a "HELO" check either has not been performed or has not reached a
definitive policy. . ."
My recommendation is to take -12 and amend it to change the SPF
reference back to 4408 and let the WG wrestle through how to handle
the change that was introduced in 7208.
--Kurt
+0.8
I believe this -12 rev "jumped the gun" to presume 4408 is obsolete
when its not in practice and probably won't be for a very long time.
I understand the IETF idea that 7208 updates 4408 but there are
differences besides the HELO issue and the reality would be there may
be both type of SPF receivers and that includes support for
5322.Authentication-Result (AUTH-RES) in 7208, and 4408 which only
supports 5322.Received-SPF. 7208 was suppose to be compatible to both
possible consumers of these 5322 reporting headers.
So if DMARC requires AUTH-RES, then it should reference 7208 for this
key reason and it should also continue to reference 4408 to provide
design semantics regarding adding DMARC support existing 4408 only
systems with the official SPF reporting trace header. Its possible for
DMARC implementations to add support for detecting both reporting
headers. That would be an "informational" type of design semantics
that should be in this document, if not already, i.e, future DMARC
implementations need to understand that current software SPF modules
SPF may not be 7208 ready and will A) change it if they can, and/or b)
add support for SPF 4408 Received-SPF results.
For new developers, starting with this Informational version of DMARC,
there is a mix of inconsistencies. And until the official IETF
standard track "solid spec" version is done, this IETF-produced
informational doc will be the "pseudo" standard to work with. So it
should be ready for the "solid spec."
Finally, just look at its ADSP references, with semantics, direct or
indirect, regarding ADSP, it should probably be removed at this point.
The informational doc should be as clean and clear as possible about
what is expected to come and that includes support for 3rd party
Policy augmented protocol extensions.
One last thing, it should also add some Migration considerations such as:
- SPF 4408 to SPF 7208,
- ADSP to DMARC,
- Other future software enhancement "Get Ready" considerations.
For future implementations that do not use the open source libraries,
the "OpenDMarc" or any other 3rd party package, this would be a big
item.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
