If this option is yes (default), KLINE by itself sets global (propagated) bans.
If this option is no, KLINE by itself sets a local kline following cluster{},
compatible with 3.2 and older versions.
Special modes like +j can be tracked easily just by adding the necessary
code to parse them to set_channel_mlock(). This will cover propagation
as well.
Such bans are not applied locally, but are propagated normally.
They can only be removed on a server that applies them.
Note that normally KLINE will not accept such bans.
This is mainly for services, differing min_wildcard and
ircd changes.
A KLINE command without the ON clause now sets a propagated
("global") ban. KLINE commands with the ON clause work as
before.
Propagated klines can only be removed with an UNKLINE command
without the ON clause, and this removes them everywhere.
In fact, they remain in a deactivated state until the latest
expiry ever used for the mask has passed.
Propagated klines are part of the netburst using a new BAN
message and capab. If such a burst has an effect, both the
server name and the original oper are shown in the server
notice.
No checks whatsoever are done on bursted klines at this time.
The system should be extended to XLINE and RESV later.
There is currently no way to list propagated klines,
but TESTLINE works normally.
The value 0 indicates the creation time is unknown (currently the case
for bandb).
Also store a creation time for xlines and resvs, but do not use it yet.
When a user receives a private message, notice or RPL_UMODEGMSG,
add the source to a special set of 5 target slots.
These slots are checked in the normal way when sending messages,
allowing a reply without using up a free target.
This feature will not be very useful if a user is being messaged
by many different users; to help this, messages blocked entirely
by +g or +R do not affect the targets. CTCP replies also remain
free in terms of targets.
The server protocol for this is
:<uid> ENCAP * CERTFP :<40 hex chars>
both in new user introductions and in burst.
As in oftc-hybrid, only the user themselves and opers can see the certfp.
Displaying the certfp on connect seems unnecessary to me,
the user can whois themselves if needed.
A notice will be sent to any force parted users that the channel
is temporarily/permanently unavailable on the server.
A new config option channel::resv_forcepart can be used to disable this.
from ircd-ratbox (dubkat)
A large group is any $$ or $# or a channel with more than
floodcount/2 local members, checked on each server separately.
Note that floodcount checks are done on the sender's server.
The special treatment is active for 15 seconds.
Spaces in xline.conf files are changed to \s in memory
and recognized on unxline, but are not changed in the
file. New xlines are added to xline.conf files with \s.
xline.conf written by this commit or newer will not work
properly with charybdis older than 1124:131254925f32 (which
introduced \s support in match_esc()).
to restrict channel names to printable ascii only.
Like disable_fake_channels this only applies to joins
by local users; unlike disable_fake_channels it applies
to opers as well.
Note that in some cases (different TS delta settings,
heavy lag) it is possible only one of the servers
detects the problem and autoconnect may be left enabled.
The mechanism used for disabling is the same as
/quote set autoconn <server> 0; the A flag in /stats c
disappears and a rehash or /quote set autoconn can put
it back.
Use /quote help who for details.
The format code "o" (oplevel) is not documented,
but implemented showing dummy information (999 for
chanop, n/a otherwise).
Specifying need_ssl on auth{} denies the connection if
it is not SSL/TLS, much like need_ident or need_sasl.
Specifying need_ssl on operator{} refuses opering with
ERR_NOOPERHOST if the connection is not SSL/TLS.
from ircd-ratbox
Throttle replaces max_unknown_ip, reject is like before
(including the charybdis-specific unkline handling).
Both of these now apply before SSL negotiation.
This commit does not include the global_cidr and new dline code.
m_webirc is a bit nasty with throttling (unlike before
with max_unknown_ip), this may be fixed later (or
the webirc IP needs to be exempt{}ed).
