The reason why we do this is because some clients are dependent on receiving a numeric
for every channel join failure, even due to this limit where it can be assumed that
subsequent joins failed.
This has a separate enabling option channel::channel_target_change.
It applies to PRIVMSG, NOTICE and TOPIC by unvoiced unopped non-opers.
The same slots are used for channels and users.
* does not apply to NOTICE (as those may well be automated)
* mirrors +g behaviour so that no useless accept entries are added for services
* respects max_accept, if it would be exceeded the message is dropped with numeric 494
* check moved up so this is checked before floodcount/tgchange
This shouldn't provide any way for a client to get on a CALLERID list
without authorization, as if a client is +g already, a CTCP request, for
example, won't be replied to.
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.
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.
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.
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.
This gives a useful meaning to the cmode combo +mz-n:
messages from ops and voices go to all channel members,
messages from anyone else (on or off channel) go to ops.
With +mnz, messages from outside are not allowed at all.
A juped server is defined as a server that already
exists with a service{} server as uplink.
If a juped server is introduced by another server,
this generates snotes/logs as before.
Local-only server notices kept here because
hub_mask/leaf_mask tends to be specific to a (hub)
server. The same information is now available in
Netsplit notices.
These come from the name field which is empty for unknown
connections attempting to become a server.
Instead, put [@255.255.255.255] just like ratbox3 does.
These are unreliable in general and only useful
for violating certain restrictions.
Sending such messages to remote servers is still
possible, for securely messaging pseudoservers whether
service{}'ed or not. The special oper-only syntax
opers@server remains as well.
This avoids annoying users when someone links a test
server with the wrong nicklen and is more likely to lead
to the inconsistency being fixed than a kill.
This way, the information remains valid after a split.
For clients on TS5 servers, the nick is used; this is
not much of a problem because these are on pseudoservers
and not assumed to change nick much at all.
- the number of messages blocked by target change on
this server since it was started
- the number of IPs currently subject to a a lower
target limit on this server (these expire over time)
This check sometimes blocks oper overrides (OMODE).
It does not stop any hacks that the channelTS check
already stops, because CHFL_DEOPPED is only set when
this server ignored an @ in an incoming SJOIN (the
SJOIN is then propagated without the @) and this
can only be because of a TS difference.
- Do not use hide_error_messages for certain "safe" ERRORs.
- If hide_error_messages hides an ERROR from a handshake,
send a server notice anyway, but without the message
text.
- Send server notices about ERRORs from handshakes network
wide if it was a remote connect.
This changes flattened /links output to disclose less
routing information and slightly increases memory "leak"
from server names that do not come back anymore.
If we are connecting outward to a server, check if the
server name they sent is the same as what we tried to
connect to. Previously such a connection could succeed
if there existed connect blocks with the same IP and
passwords for the other server name.
Another handling of SJOINs without nicks:
Propagate them if the channel is +P or the channel
already existed, otherwise remove the channel again
and do not propagate the SJOIN.
Change TS6 JOIN processing
- don't send out simple modes in TS6 JOIN and TS5 SJOIN when
a local user joins an existing channel
- don't send out simple modes in TS6 JOIN and TS5 SJOIN when
propagating a TS6 JOIN
- don't interpret simple modes in an incoming TS6 JOIN
This is to avoid desyncs when certain mode changes (e.g. -im)
cross with joins. A downside is that simple modes will be
more desynched when a JOIN creates a channel or lowers TS,
but that's less important.
Update the TS6 specification to include this, and clarify
that TMODE can come from a server and that MODE must be
translated into TMODE from other servers too.
server name existed taking hostmasking into account
and just check with find_server(); admittedly
this checks if the name is a SID but that's not
a real problem.
