to limit actions to limit-ban-action as the highest, and limit
ban times to limit-ban-time the highest, see
https://www.unrealircd.org/docs/Central_Spamfilter
This also changes highest_spamfilter_action() to highest_ban_action().
* This means we always run spamfilters, even if users are exempts
* This way we can gather hits for exempted users on individual
spamfilter entries, and possibly detect false positives
(which relies on the assumption that those users are innocent)
* The hit counters are shown in in RPL_STATSSPAMF and also
exposed via the JSON-RCP API.
* This commit also adds set::central-spamfilter::except but more
on that later since i still want to set a default for that in
a future commit.
* This also changes take_action() to take flags and adds the
option TAKE_ACTION_SIMULATE_USER_ACTION which i intended to
use but didn't in the end... not sure if i should keep it :D
This uses the RPC2 API. Tested with staging.
Note that there are likely some bugs here or there, like memory leaks,
but the functionality is there.
Also still need to implement various stuff, including spamreport::rate-limit
Only match was working earlier, and for now both are accepted,
like everywhere else. Reported by BlackBishop.
Also, added a missing check for unknown rpc-user items, so a
proper "Unknown directive" error is thrown.
(this missing check made the first issue worse)
that was added late in 6.1.1 development to fix a crash with removing
websocket listeners. Now replaced with a generic HOOKTYPE_CONFIG_LISTENER
that is not only called for removed listeners, but for all listeners.
The whole point of (G)ZLINEs is that it rejects instantly upon
accept, that's what makes them different from KLINE/GLINE.
Commit 89075e532a made it
accidentally use the slow path for this as well.
previously it was set to 'nick'
Also allow the full topic length for the nick-user-host case, now that
we have BIGLINES support. For non-BIGLINES-servers this could mean a
potential cutoff of the last 20 characters of the topic, which is why we
restricted it to 340 instead of 360 for nick-user-host previously, but
that is really only in the corner case / worst case, like with max NICKLEN,
max USERLEN, max HOSTLEN, max CHANNELLEN, etc... i think we can live
with that small "problem" until all servers upgrade.
when it is not possible, mixed server scenario).
Now a big RRPC response like server.module_list for a remote server
(44KB) fits in only 3 lines, instead of almost 100 lines.
`PROTOCTL BIGLINES` is set. This will allow us to do things more
efficiently and possibly raise some other limits in the future.
This 16k is the size of the complete line, including sender,
message tags, content and \r\n. Also, in server-to-server traffic
we now allow 30 parameters (MAXPARA*2).
The original input size limits for non-servers remain the same: the
complete line can be 4k+512, with the non-mtag portion limit set
at 512 bytes (including \r\n), and MAXPARA is still 15 as well.
* I chose 16k because I don't want to first raise it to like 8k
and then realize later that 16k would be better and raise it again.
* To receive BIGLINES in a command, you need to `CommandAdd()` with
flags `CMD_BIGLINES`, without it you still get regular 512 max.
This is so, because a lot of the code does not expect longer than
512 bytes lines or in parameters, so we can gradually change that
(where needed).
https://ircv3.net/specs/extensions/chathistory#isupport-tokens
The spec says they should be 'in order of decreasing preference'.
As currently the only backend is in-memory, this doesn't matter so I
picked `msgid` first (as it's less ambiguous); but this can be revisited
later if/when adding a backend which is more efficient with timestamps.
Has to do with running HOOKTYPE_SERVER_CONNECT too soon, before
introducing ourselves to the other side. This bug was created in
commit ddf639836b so exists in
all UnrealIRCd 6 versions (-beta1 and up).
The hook call is now moved further down.
and also for safety when redoing DNS and ident due to IP change,
we now:
ClearIdentLookupSent(client);
ClearIdentLookup(client);
ClearDNSLookup(client);
depending on what we get from the proxy, so it can be used later
in the websocket module for setting the user secure or not
(the latter similar to what k4be already did in the old code).
This now requires a proxy { } block -- docs follow soon
This uses part of k4be's code still, to do the parsing,
so still only "Forwarded" and quick workaround for bug
when for=XXX is the final item.
a function called start_dns_and_ident_lookup(). This can then
be easily called from other places as well, like the code k4be
did in src/modules/websocket.c to handle proxies.
Side-effect is that ident lookups would now be done, if we are
configured to do so, for forwarded webirc stuff (not that I
think many people use that feature at the moment...).
Bram Matthys