On Mon 20 Mar 2023 at 07:36:41 (+0800), Jeremy Ardley wrote: > On 20/3/23 02:48, David Wright wrote: > > > Checking the RFC. To my reading the final stanza is not checked > > > " The <ip> is compared to the given network. If CIDR prefix length > > > > > > high-order bits match, the mechanism matches." > > > > > > https://datatracker.ietf.org/doc/html/rfc7208#section-5.6 > > > > > > So in this case AI got it right. > > I don't follow. What's your "final stanza" referring to, and > > what's wrong with the RFC in connection with it? > > > I should have used the term 'final qnum' but I think that would be obscure. > > I meant the fourth number in the IPv4 dotted-quad notation.
Ah, I see now. I was trying to apply "stanza" to a bullet point in the AI, or a section/paragraph from the RFC. > As for the RFC? It's precise and definitive. My only concern is that > some mail system implementer may 'improve' the RFC and restrict the > acceptable address range to a /32 when they see a non zero final qnum > in a /24 I don't know whether there are regression tests knocking around for checking check_host(), but they would definitely fail in that case. Hopefully some of the users (those affected) would complain. I assume the reason that host-ip-address/cidr-length is a permitted domain-spec for ipv4: is by analogy with host-domain/cidr-length for a:. So a:colo.example.com/28 could, if colo.example.com had an A record with 93.184.216.34, be written 93.184.216.34/28. If you had to write a strict network address, you'd have to figure out that it's 93.184.216.32/28. Easy in this case, but error-prone when you're obliged to convert, say, a looked-up x.y.z.185/28 to its network address of x.y.z.176/28. A minor point that I noticed was included in the AI output, which AFAIK would have to be found elsewhere than in the SPF specification or RFC7208, are the range extremities, which correctly exclude the network and broadcast addresses. Cheers, David.
