maximum number of conversations a user can have with other users at the
same time. Until now this was hardcoded at limiting /MSG and /INVITE to
20 different users in a 15 second period. The new default is 10 users,
which serves as a protection measure against spambots.
See https://www.unrealircd.org/docs/Set_block#maxcc for more details.
* You can now set more custom limits. The default settings are shown below:
set {
topic-length 360; /* maximum: 360 */
away-length 307; /* maximum: 360 */
quit-length 307; /* maximum: 395 */
kick-length 307; /* maximum: 360 */
};
* A new 005 token has been added: QUITLEN. Works similar to KICKLEN.
The ability to adjust the topic length in the configuration file was
requested by Amiga600 in https://bugs.unrealircd.org/view.php?id=4692
At that place is also additional information on why there is a
"maximum" for topic length.
to control synchronization of the +beI setter across server links
(that is, the feature just introduced one commit ago):
set {
topic-setter [nick|nick-user-host]; /* nick = default */
ban-setter [nick|nick-user-host]; /* nick = default */
ban-setter-sync [yes|no]; /* yes = default */
};
This also means that --with-topicisnuhost / TOPIC_NICK_IS_NUHOST
is now removed, since this now goes via set::topic-setter.
Also, moved the "first" PROTOCTL from include/common.h to send_proto()
in src/s_serv.c so the bunch of PROTOCTL lines is all in one place
(and so I could conditionally send SJSBY).
Ok, it's not entirely all in one place, PROTOCTL EAUTH is still sent
at another place (early, duh), but still..
that use outdated SSL/TLS protocols (eg: TLSv1.0) and ciphers.
The default settings are to warn in all cases: users connecting,
opers /OPER'ing up and servers linking in. The user will see a message
telling them to upgrade their IRC client.
This should help with migrating such users since in the future, say one
or two years from now, we would want to change the default to only allow
TSLv1.2+ with ciphers that provide Forward Secrecy. Instead of rejecting
clients without any error message, this provides a way to warn them and
give them some time to upgrade their outdated IRC client.
https://www.unrealircd.org/docs/Set_block#set::outdated-tls-policy
places by spamfilters (and some other systems) to be placed not on *@ip
but rather on user@ip. Note that this won't work for ZLINE/GZLINE since
no ident/username lookups are done in such cases.
Bit of a niche feature but okay..
This allows you to for example specify a specific certificate/key on an
serversonly port and in link block (a self-signed 10 year valid certificate)
and use a short-lived (XX day) Let's Encrypt certificate on the other ports.
And several other uses, of course.
Accepted values are: All (enable all), TLSv1, TLSv1.1, TLSv1.2
You can use + and - modifiers, in fact you are encouraged to.
Example: set { ssl { protocols "All,-TLSv1,-TLSv1.1"; }; };
This will only allow TLSv1.2 at time of writing, and later whenever
TLSv1.3 is released it will allow TLSv1.2 and TLSv1.3.
Note that 'SSLv2' and 'SSLv3' do not exist, as UnrealIRCd 4.x never
supported these old versions (and never will).
By default this is set to 'yes' which means that once a spamfilter matches
UnrealIRCd will take action immediately and any additional (other)
spamfilters will not be processed.
When this is set to 'no' then after the first spamfilter match other
spamfilters will still be checked. All of these matches will be logged and a
message will go to IRCOps (snomask +S) for each one. The affected user,
however, will only see one spamfilter action (eg: block or kill) which will
be the spamfilter with the 'gravest action' (gzline is highest, block and
warn are lowest).
DH parameters files must be encoded in PEM format, and the path is
set using the ssl::dh config setting. This is based on a patch
submitted by wolfwood, with some modifications to avoid using stdio
unnecessarily and to avoid code duplication.
If this is not set, then SASL is off and not advertised.
If the specified server is not connected, then SASL is off as well.
This prevents unnecessary delay (and the inability for some clients to
get online) when SASL is not in use or when the SASL server is down.
it to 'no', the default is 'yes' (on). Requested by Robin (#0003885) as
UHNAMES may increase the time of the nick list being loaded from 1 to 4
seconds when joining several channels with more than 1000 users. As this
problem is only present on some networks, we keep UHNAMES enabled by
default.
Bram Matthys