The issue is that I would need to split the extended ban address into the case-sensitive and case-insensitive parts in order to compare them separately. For example, on UnrealIRCd, these would be identical:
~r:abc!def@ghi.org
~r:abc!DEF@ghi.org
case-sensitive comparison: ~r and ~r
case-insensitive comparison: abc!def@ghi.org and abc!DEF@ghi.org
And these would be different:
~r:abc!def@geh.org
~R:abc!def@geh.org
case-sensitive comparison: ~r and ~R
case-insensitive comparison: abc!def@ghi.org and abc!def@ghi.org
So I would need to parse the extended ban prefixes all the way to the data parts in both addresses, so I can compare the prefixes case-sensitively and the data parts case-insensitively.
In order to do that, I would need to know:
1) The exact method that the ircd itself uses to parse the prefixes, to make sure I do it the same way.
2) That all ircds use the same method. If they do not, it will fail on different ircd implementations.
This is why I wanted to avoid the above by not performing tracking. But that would break features/scripts that have worked for 15+ years.
I have already implemented a routine that extracts:
EXTBAN=$,ajrxz (on irc.freenode.net)
EXTBAN=~,SOcaRrnqj (on irc.unrealircd.org)
And uses the specified prefix. It then stores and scans everything after , and determines if extban types are case-sensitive or not. If case-sensitive, a banmatch routine parses the ban addresses to be compared, checking for a prefix (required), a ~ negation (optional), an extban type character (optional), and a : colon (optional), repeatedly (to handle stacked types) until no more prefixes are available. It then assumes whatever is left is the data part. It then compares the extban section case-sensitively and the data part case-insensitively. However, there is no way to know if this will work across ircd implementations.
I am also going to add a $ibl() .extban and .extdata property that return the split information. That might help debug the routine to see if it is working correctly with different extbans.
