Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset
On 24/02/2019 19:17, Jeremy Harris via Exim-dev wrote: > I don't know if a lookup done via the list-syntax > "hosts = corkipset:/filename" > will be different. Probably it will, sigh. Dots, and always seven. I tested by adding "pipeline_advertised_hosts = net-corkipset;DIR/aux-var/TEST.ipset" to the config, some "exim -bh" to the script and some debug_printf() in the code. I didn't look at actual results of the lookups though. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset
On 24/02/2019 18:52, Jeremy Harris via Exim-dev wrote:
> On 24/02/2019 18:11, Ian Zimmerman via Exim-dev wrote:
>>> I'd expect conversion to unabbreviated form to have been done too.
>>
>> Do you mean I can expect an IPv6 address (mapped or not) to have exactly
>> 7 separators, whatever these might be? If yes, there is no ambiguity.
>
> That is my hope. But hope is all it is. This is why I say you need to
> test. And leave the testcases in the testsuite.
I gave in and ran some tests myself.
My optimism was misplaced, but it doesn't matter. Your code gets
given the raw string from the user; it is _not_ colon-to-dot
translated - it can have any format of ipv6 or ip4 address
(and possibly also just be bogus).
This is with a direct ${lookup } call as per your testcases.
I don't know if a lookup done via the list-syntax
"hosts = corkipset:/filename"
will be different. Probably it will, sigh.
More testing needed.
-J
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset
On 24/02/2019 18:11, Ian Zimmerman via Exim-dev wrote: >> I'd expect conversion to unabbreviated form to have been done too. > > Do you mean I can expect an IPv6 address (mapped or not) to have exactly > 7 separators, whatever these might be? If yes, there is no ambiguity. That is my hope. But hope is all it is. This is why I say you need to test. And leave the testcases in the testsuite. > > I think I must keep in mind 2 cases: > > 1. Addresses coming from exim itself, for example $sender_host_address. > Unfortunately the spec doesn't say what format this is in (if it is > IPv6). Can you enlighten me about this? That specific expansion returns whatever the library inet_ntop() does. The Linux manpage says, for ipv6, "the most appropriate ... format". I think that means "abbreviated". It does note that ipv6-mapped ipv4 addresses are converted to ipv6, which I assume means "no dotted tail section" (it lists that as a bug, so it could change sometime). > 2. Addresses explicitly written into the configuration by user. This > one is about what I can require from users. I need to document that in > the experimental documentation file. I'm hoping it turns out that you can handle all reasonable input representations with minimal effort, so placing few restrictions on the user. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset
On 2019-02-24 15:01, Jeremy Harris wrote: > On 24/02/2019 07:47, Ian Zimmerman via Exim-dev wrote: > > > > How are the IPv4-mapped IPv6 addresses written in Exim? > > > > The straight translation to dots instead of colons would be ambiguous, > > wouldn't it? Say, ...1.2.3.4 could mean either the mapped address > > or the normal IPv6 address 0:0:0::0001:0002:0003:0004 . > > You can write them either way; both are acceptable and the number-base > of the dotted-portion gets translated ( .234 does _not_ become :0234 ). But that was not the question I asked. It's not about one address having multiple representations; it's that -- after a blind colon-dot transliteration -- the same string representation may denote multiple addresses. > But that's ipv6 addresses given to exim, not how they are given to > the place you're coding. I think you need to check, given that a > colon-to-dot translation has been done by the time it hits you. Of course, that is why I'm asking. > I'd expect conversion to unabbreviated form to have been done too. Do you mean I can expect an IPv6 address (mapped or not) to have exactly 7 separators, whatever these might be? If yes, there is no ambiguity. I think I must keep in mind 2 cases: 1. Addresses coming from exim itself, for example $sender_host_address. Unfortunately the spec doesn't say what format this is in (if it is IPv6). Can you enlighten me about this? 2. Addresses explicitly written into the configuration by user. This one is about what I can require from users. I need to document that in the experimental documentation file. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] Bug 2369: single-key lookup type based on libcorkipset
On 24/02/2019 07:47, Ian Zimmerman via Exim-dev wrote: > On 2019-02-10 23:03, Jeremy Harris wrote: > >> If you can reliably detect the ipv6-ness, yes, that sounds like the >> minimally intrusive way. > > How are the IPv4-mapped IPv6 addresses written in Exim? > > The straight translation to dots instead of colons would be ambiguous, > wouldn't it? Say, ...1.2.3.4 could mean either the mapped address > or the normal IPv6 address 0:0:0::0001:0002:0003:0004 . You can write them either way; both are acceptable and the number-base of the dotted-portion gets translated ( .234 does _not_ become :0234 ). But that's ipv6 addresses given to exim, not how they are given to the place you're coding. I think you need to check, given that a colon-to-dot translation has been done by the time it hits you. I'd expect conversion to unabbreviated form to have been done too. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] Test suite unusable?
On 24/02/2019 02:23, Ian Zimmerman via Exim-dev wrote: > Do you have a suggestion for the version mismatch? Ignore it. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
