I believe in the situation where standard is absolutely clear like this, any implementer must strictly follow the standard. Otherwise, it can lead to unpredictable behavior and security issues.
Example: there are absolutely legal situations where non-trusted or less privileged side can partially control the name and/or content of the DNS record. I can provide users or customers with possibility to register a hostname and TXT record in my zone but I want to prevent them from corrupting or changing SPF/DMARC/etc policy. I can rely on filtering TXT record content. Non-standard behavior of DMARC implementation can allow to bypass this filtering. While this example doesn't seem realistic, I can demonstrate quite realistic ones. For example, a minor relaxation for ARC version check can lead to DKIM signature spoofing, compromising DMARC as a result. For DMARC DNS record itself, realistic scenario may appear in the future. We already have a lot of problems in-the-wild because of standards relaxations, e.g. it's usually possible to bypass DMARC which relies on RFC5322 via malformed From: due to fact invalid From: header is generally accepted and parsing From: header for DMARC validation and for visual representation is usually made by different pieces of code with different behavior. 16.01.2019 21:34, Grant Taylor пишет: > On 01/16/2019 10:26 AM, John R Levine wrote: >> Maybe, but that's not what standards are about. The point of a >> standard is to say here's what you do if you want to interoperate. I >> have never found it productive to speculate about what you might or >> might not want to do when you run into people who didn't read the spec. > > I agree with you conceptually. > > However I feel like rejecting things because of additional white space > (in front of v=...) or the wrong case is being a little bit pedantic. > > Rather, I think that if removing a spurious / leading space or folding > case causes the DMARC record to be valid, it behooves us to tolerate > such minor errors. > > I don't want to be so pedantic that people push back on adopting what > I (and I assume others) think is a good technology. > > Is doing so against the letter of the specification, absolutely. Is > it within the spirit of the specification, I think so. > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
