* 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
Pulled from Charybdis upstream changeset 1388:b1ef26176350 done by jilles.
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.
Modeset files are modules stored in shadowircd/modes. All they do is initalize
a set of modes on load, and orphan said modes on unload.
All cmodes not included in ircd-ratbox are now located in modeset files, rather
than being in the core. These modes no longer simply use defines, their
locations are stored in a the new struct module_modes. Each of these is set
when intializing the mode in the modeset files, and set to 0 when orphaning
the mode upon unloading the modeset file.
In addition, use_forward has been removed, as it is now obsoleted by modesets.
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.
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.
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.
JD Horelick
William Pitcock
B.Greenham
Jilles Tjoelker
Stephen Bennett