spamfilter (F, not f) and qline (Q, not q).
2) Error out when invalid ban exception types are given, so such errors
don't go undetected anymore. Eg it will now print:
"ERROR: bantype 'f' is unrecognized (in 'fgkz'). Note that the bantypes are case sensitive. Type /ELINE to see a list of all possible bantypes."
Reported by westor and Mi_01 in https://bugs.unrealircd.org/view.php?id=5528
Also, when at it:
3) Remove type 't' from ELINE syntax docs, which is in fact 'c'
(which is already present in the list)
Remove old option set::ban-include-username and replace it with a more
generic option which defines what target a ban should apply to.
Also add some parts of set::manual-ban-target which will follow soon.
Although not entirely true, exempting a user from 'd' when using
an extended server ban or IP or ident is not recommended.
The information needed to exempt the user may not be available
at the time of the flood. Better to reject it than have it partially work.
See https://www.unrealircd.org/docs/Extended_server_bans
Examples with ELINE:
/ELINE ~a:TrustedAccount kg 0 This user can bypass kline/gline when using SASL
/ELINE ~S:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef kgf 0 Trusted user with this certificate fingerprint
It also works with bans, although this would be less common:
/GLINE ~a:EvilAccount
A more useful purpose would be to use ~r (realname):
/GLINE ~r:*some*stupid*real*name*
(Although you could already ban realnames via spamfilter 'u')
For third party module coders:
If you have an extban in group 3 (a "matcher"-extban) then you
can opt-in to support this. You do so at extban registration time:
req.options = EXTBOPT_TKL;
or, if you already had another flag set, like for +I, then:
req.options = EXTBOPT_INVEX|EXTBOPT_TKL;
In any case, you set the .options before you call ExtbanAdd().
Note that if you do indicate support then your is_ok function
will be called like:
extban->is_ok(client, NULL, mask, EXBCHK_PARAM, MODE_ADD, EXBTYPE_TKL);
Important here is the NULL channel (since there is none)
Similarly your is_banned function will be called with BANCHK_CONNECT:
extban->is_banned(client, NULL, banstr, BANCHK_JOIN, &msg, &errmsg);
Here too, it is important to note that channel is NULL.
Add new config option "exempt-webirc yes;" in set::restrict-commands::<commandname> in order to give exceptions in all WEBIRC user. This closes one of the 3 suggestions in https://bugs.unrealircd.org/view.php?id=5506
1) Fix issue if HOOKTYPE_IS_HANDSHAKE_FINISHED rejects the user
2) Fix authprompt issue. We now allow adding the TKL in
place_ban_host() for soft-kline/etc. Previously all the
soft-kline/gline/zline/gzline acted like soft-kill.
3) The blacklist module did not allow clients in with action 'warn',
reported by westor in https://bugs.unrealircd.org/view.php?id=5501
In the configuration item you can now achieve the same via:
except ban { mask 1.2.3.4; type maxperip; }
Or even:
except ban { mask { 1.2.3.4; 8.8.8.8; }; type maxperip; }
etc.
Suggested by The_Myth in https://bugs.unrealircd.org/view.php?id=5507
Also, fixed an issue where the IRCd was counting servers as
clients for maxperip, which doesn't make much sense in practice,
so it only counts users now.
MLOCK restrictions when services are down (set::services-server).
Suggested by westor in https://bugs.unrealircd.org/view.php?id=5273
By default all opers with the *-with-override privilege have this,
which sounds OK to me.
if you are running a mixed U4 and U5 network, but it solves the situation
where a knock-flood is only detected locally. Since KNOCK usage isn't
that common and flooding is worse than double notices during the
transition period, I went with this change..
for the user. Otherwise with post-connect SASL authentication you will
have different login information on server X compared to server Y
(the server with the user on it was always correct, though).
Also, add a function called user_account_login() which is used by both
SVSMODE/SVS2MODE and SVSLOGIN to send ACCOUNT messages to the channel.
This too was missing for SVSLOGIN (post-authentication SASL).
For this fix to be 100% effective, you need 100% UnrealIRCd 5.
in a sending loop if you used a services logging channel.
Reported by The_Myth in https://bugs.unrealircd.org/view.php?id=5469
The same bug was reported and seemingly fixed before, but wasn't
actually.
westor