This adds a configuration option that determines whether the NOTICE is
sent to clients that do not support the IRCv3 invite-notify capability.
Requested by LiberaChat MGM.
rejectcache entries can now use either a K-line aconf or a static
string as a reason. This will be sent in a 465 numeric before the usual
ERROR. In the case of K-lines, it resembles the 465 you would have been
sent without being rejected:
; nc -s 127.6.6.6 127.0.0.1 5000
:staberinde.local 465 * :You are banned from this server- Temporary
K-line 4320 min. - abc123 (2019/12/31 01.07)
ERROR :Closing Link: (*** Banned (cache))
; nc -s 127.128.0.0 127.0.0.1 5000
:staberinde.local 465 * :You are not authorised to use this server.
ERROR :Closing Link: (*** Banned (cache))
As it stands, oper hiding is rather messy and inconsistent. Add
SeesOper(target, source), which is true iff target should appear as an
oper to source. If I haven't missed something, all commands that reveal
oper status now use the same logic.
general::hide_opers_in_whois is a special case, and affects /whois only.
general::hide_opers is introduced, and has the same effect as giving
everyone oper:hidden. All commands that reveal oper status respect both.
This only supports two addresses as the intended use is 1 IPv4 and 1 IPv6
address on a single-homed host, and the only supported configuration of
outgoing connections to other servers is to bind a single IPv4 or IPv6
address.
Fix the server connection configuration so that it can simultaneously
handle a hostname/IPv4/IPv6 for connecting and a hostname/IPv4/IPv6
for binding. Maintains backwards compatibility for matching a hostname
with a mask.
Multiple host/vhost entries can be specified and the last value for
each address family is stored. Hostnames that resolve automatically
overwrite the IP address.
Server connections can now be made to either IPv4 or IPv6 at random
as well as preferring a specific address family.
It seems to come from an era where long long didn't exist and 64-bit
machines weren't common. 32-bit machines are still common but I can't
imagine this will have much performance impact there.
This "fixes" #179 in title only, but see comments within.
While functionally compatible with the implementation in ElementalIRCd, our approach is different,
specifically pre-calculating the bitmask at config load time. This is more efficient, and allows us
to report errors as part of the configuration phase.
