On 01/16/2019 11:34 AM, Grant Taylor wrote:
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.
I've seen a number of intriguing, if not compelling, replies in this thread. Some of which have changed my thoughts some.
I now concede accommodating a leading space is questionable.However I still feel like /requiring/ exact case is contrary to the idea of "Be liberal in what you accept and conservative in what you send.".
I don't see any security implications in accepting the following:dmarc-version = ("v" / "V") *WSP "=" *WSP ("D" / "d") ("M" / "m") ("A" / "a") ("R" / "r") ("C" / "c") "1"
I agree that this is contrary to the letter of the specification. However I think it is completely within the spirit. Especially when dealing with DNS data which is inherently / invariable human entered.
I don't (yet) see any security implications of accepting improper case record data for the dmarc-version *IF* that is the /only/ TXT record at a given QName that is DMARC related. - If there are multiple DMARC records, especially if they are conflicting, strictly adhere to the standard.
I'm curious if anyone sees any security implications with the above dmarc-version.
This is me trying to learn and understand. I'm not trying to argue one way or the other.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
