On 10/19/24 17:29, John R Levine wrote: >> On 10/19/24 13:06, Daniel K. wrote: >> The value in source_ip SHOULD either be a globally >> routable IPv4 unicast address in the dotted-decimal >> format, or a globally routable IPv6 Global Unicast >> address in the canonical textual representation format; >> see RFC 5952 for details. > > That's OK with me with the usual caveat that you need to say why it's > SHOULD and not MUST.
Thanks, this is not something that needs to be written together with the above proposed text, is it? It just needs to be mentioned on this list. I don't think we can or should enumerate in the text the things we can currently think of as valid SHOULD exceptions, because suddenly there might be others. Caveats could be: * [from alevesely] obsolete library functions * It's that time of year, and someone decided to use RFC 1924 * Using libowfat::fmt_ip6() or other non-conforming implementations to format your IPv6 address. * IPvNG happened and the mail service moved to it. I looked into the libc situation and found that inet_ntop() was first specified in: https://www.rfc-editor.org/rfc/rfc2133.html#section-6.5 glibc, freebsd, netbsd, openbsd, opensolaris, and macos all use inet_ntop() code originaly from ISC written by Paul Vixie. This code works correctly according to the rules in RFC 5952. dietlibc and musl libc have their own implementation, and both produce non-conforming output. dietlibc: * compresses the first run of zero-bits, not the longest run * compresses on only one 16-bit field. * compresses even one leading and one trailing zero-bit field musl: * compresses on only one 16-bit field, but leaves one leading or one trailing zero-bit field alone. > Given that nobody seems to look at the regex, and just uses library > IP address routines to produce and read the IPs, how about just using the > really short one I suggested? There's a lot of development here, and I think the consensus moved to your suggestion from later in this thread as the better option. Paraphrased: No pattern, and a note like the one suggested above. Daniel K. _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
