On Tue, Jan 24, 2023 at 08:03:16AM -0800, Michael Peddemors wrote:
> On 2023-01-24 07:15, Mark Martinec wrote:
> > > Messages via o365 seem to have a problem with this..
> > >
> > > Jan 23 09:51:51.081 [1569369] dbg: check: tagrun - tag
> > > RELAYSUNTRUSTEDREVIP is now ready, value:
> > > ARY:[71.53.92.40,5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.2.8.0.6.9.0.1.3.0.6.2]
> > > Jan 23 09:51:51.081 [1569369] dbg: check: tagrun - tag
> > > RELAYSEXTERNALREVIP is now ready, value:
> > > ARY:[71.53.92.40,5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.2.8.0.6.9.0.1.3.0.6.2]
> > >
> > >
> > > Only the first element of the array is an IP Address, correct?
> > > Makes is a little more difficult to do validation on it..
> >
> > They are both IP addresses - in reverse byte order, suitable for
> > a DNS PTR lookup:
> >
> > 71.53.92.40 -> 40.92.53.71 (Microsoft)
> >
> > 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.2.8.0.6.9.0.1.3.0.6.2
> > -> 2603:1096:0820:0040::5 (Microsoft)
> >
> > SA::Util.pm:
> >
> > # Given a quad-dotted IPv4 address or an IPv6 address, reverses the order
> > # of its bytes (IPv4) or nibbles (IPv6), joins them with dots, producing
> > # a string suitable for reverse DNS lookups. Returns undef in case of a
> > # syntactically invalid IP address.
> > #
> > sub reverse_ip_address {
>
> Understood.. I guess I wasn't clear.. Should this not be in it's own array,
> eg RELAYUNTRUSTEDREVIPV6, since the use case is of course much different?
>
> Otherwise additional validation has to be written.
>
> But yes, I guess it is by design ;) Just questioning this going forward,
> given the use cases for RBL lookups can be quite different, whether it's a
> IPv6 or not. (Eg, different bogon sets etc, that do not qualify for an RBL
> Lookup)
What is your exact use case anyway?
It wouldn't make much sense to split things into a separate IPv6 tag, how
would you ever find out the original IP order if they are split between
different tags?
But as these tags don't even seem to be documented, YMMV..
