Monthly General Meeting, June 2025
Propositions and Motions
There were no propositions or motions for this meeting.
Other Questions
Spamfilter usage and features
Libera.Chat has a spam filter module that is loaded on all IRC servers.
It is possible to opt out of spam filtration with channel mode u
for messages sent to channels and user mode u for messages received as PMs.
Additionally, the spam filter can only inform staff of which user tripped the
filter, not the contents or target of the message that was filtered.
Spam filtration inherently comes with a risk of false positives, especially given that users might quote spam after it gets added to the filter. Therefore, it was generally understood that items should only be added to the spam filter when nothing else is effective at mitigation, and only with strong informal agreement from other members of staff. However, prior to this meeting, there was no explicit internal policy for when to add entries to the spamfilter. This meeting agreed to create an internal policy document for spam filter usage.
This meeting also discussed the possibility of having spam filter
patterns that cannot be opted out of. Following internal discussions outside
of general meetings, it was agreed that a superdrop flag type should be
implemented that causes messages to be discarded even when the target
is +u. It was decided that +u should still allow the sender to not trigger
any behaviour that notifies staff of the filtered message.
As before, private messages to staff would still bypass the filter.
It was also discussed how we should handle client-side exploits in the context
of spam filtration, such as denial of service attacks exploiting overeager
antivirus software or remote code execution on scriptable clients.
It was agreed that both classes of exploits should be filtered, but only
remote code execution exploit mitigation should use the superdrop flag.
Guidelines around the “security” status for staff
There exists an internal “security” status in our service management system that can be applied by the operations team in case of a security breach. When applied to a staffer, they are stripped of most of their privileges except for their reduced IRC connection limits, their email account, and access to a shell account on an internal server.
There hasn’t been a need for this status to be applied so far, but an item was added to the agenda to draft internal policy for its use. It was quickly agreed that no explicit internal policy for using this status is necessary at this time. It was, however, suggested that if the operations team uses this status, they must notify the board.
It was also mentioned that applying the status as-is could potentially violate bylaws, as members with the security status are still members of the organization but would not have access to the mailing list through which general meeting invites are sent. It was agreed that those under this status should be able to keep their access to the mailing list, as the operations team can simply remove their email access if it is being abused.