It appears that Daniel K. <[email protected]> said: >RFC 7489, in the DMARC XML Schema of Appendix C, only allowed the full >IPv6 address textual representation without zero bit compression (::) > > ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}
I agree that is wrong. >I think it is prudent to specify what values we want to see in those >reports, and that is, in my opinion, values matching the canonical >textual representation format specified by RFC 5952. Having done this kind of stuff before, I can report that trying to make the syntax as super strict as possible is rarely a good idea. For one thing, it's hard to get right (see above) and for another, it means that the only error message you ever see is "syntax error". I'd rather have a loose regex and let whatever is parsing the addresses complain if they're bad. A well written IPv6 handler will also know that all of the valid IPv6 addresses are in the 2xxx: range and will reject link local, ULA, and other invalid stuff. For the same reason a well written IPc4 handler will reject 0.x.x.x 10.x.x.x and 127.x.x.x. >RFC 5952 has more to say about leading zeroes being disallowed in a >16-bit field, unless the field contains a single zero. This is not >disallowed by the proposed regex. Indeed it says that, but it is obvious what 2001:0123:: means and it's silly to reject it. I would also accept addresses like ::ffff:12.34.56.78 which can appear in logs when a single server handles both v4 and v6 addresses. Again, it's obvious what it means, what benefit is there to rejecting it? R's, John _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
