This is reference material for IRC Operators, giving preffered usage of commands, as well as overall policies. The policies stated here are not hard and fast rules, but rather an overview of what is expected as a representative of the network. For the most part, the IRC Operator should use their initiative when making decisions. ***** Network AKILL/K-Line Policy ***** Network bans should only be placed on violation of the network's AUP. Length and Banmask is up to the IRC Operator concerned. Permanant bans should be avoided, however, ban evaders may be granted a permanant ban. For better organization, K-Lines should be placed via OperServ: /msg OperServ AKILL ADD (nick OR user@hostname) (!T OR !P) (if !T: expiration time) (reason) /msg OperServ AKILL ADD C405129 !T 1d Example 1-Day Temporary akill on the (connected) nick "C405129" /msg OperServ AKILL ADD luser@*.dsl.isp.net !P Example 1-Day Permanant akill on the hostmask luser@*.dsl.isp.net Outright K-Lines are generally OK for a relatively short ban. /kline (optional duration in minutes) (user@hostname) :(Reason) Remember: K-Lines are propagated network-wide, the optional "ON (server)" part will not have an effect on this network configuration. /kline 5 luser@*.dsl.isp.net :Example 5-minute K-Line for luser@*.dsl.isp.net When choosing a banmask, it's generally a good idea to use as narrow a banmask as possible. Wide banmasks should be avoided unless a hostname is known to go across large ranges. CIDR-Notation is also possibile in both akills and klines. D-Lines should be used against flooding drones, this allows the IRC server to disconnect them with minimal processing. CIDR-Notation is also possible. /dline (optional duration in minutes) (user@hostname) :(Reason) /dline 5 169.254.103.143 :5-Minute D-Line on 169.254.103.143 ***** Network Ban Exception Policy ***** This is specifically targeted towards server administrators. Regular IRC operators who do not have access to configuration files may skip this. If you receive notices about legitimate users affected by K-Lines, you should make sure it is a legitimate user, and not the banned pest trying to find a way in. Once you have determined that, add another auth block, covering the K-Line EXACTLY as it appears in /stats K. Password is of your choosing. A spoof MUST be used in this circumstance too, more information below. Use the normal users class for your server. Give these flags: dnsbl_exempt, kline_exempt, spambot_exempt, spoof_notice. Regarding the spoof itself. syntax is "KLINE_MASK.kline-exempt.rfc1337" Due to the kline mask not supporting wildcards and forward slashes, replace * and ? with a -, and, in CIDRs, replace / with a -C. Examples: *.dsl.someisp.net == -.dsl.someisp.net.kline-exempt.rfc1337 123.45.*.* == 123.45.-.-.kline-exempt.rfc1337 123.45.0.0/16 == 123.45.0.0-C16.kline-exempt.rfc1337 Reasoning for this, is that it gives at a glance information about the usage of K-Line excepting I-Lines, as well as exactly which K-Line is being exempted. Server administrators should inform all other administrators ASAP about kline exemptions so they are able to apply it to their servers. ***** Network KILL Policy ***** KILLs may be used as a warning, before issuing a K-Line. They should only be issued on violation of the network's AUP. Kill reason is up to the IRC Operator concerned, but should be described. Vanity kills should be avoided, however, since when did anybody care about this? 2 different syntaxes for a KILL: Standard kills: /kill target :reason Anonymous kills: /msg OperServ KILL target reason ***** Network Routing Policy ***** Re-routing should be avoided where possible, unless there is severe lag on the main links, and/or large amounts of netsplits in a short period of time. If there is a large amount of latency on a link, and it is disrupting the network, it is advisable to /squit the affected server, and relink it to another uplink. Once you have done that, avoid re-linking it back to the original uplink, that simply causes more noise than necessary. ***** Channel Interference Policy ***** IRC Operators must not interfere in the affairs of other channels. /omode and /msg OperServ MODE should only be used in 2 cases: The channel is unregistered and opless, or someone on the access list with ALL these flags requests assistance: +srRf If users on a channel require assistance, you may help them by whatever means available to you. Changing channel flags via /msg ChanServ FFLAGS should be avoided. The users should be referred to the HELP commands... Really... ***** Server Link Policy ***** Server applications may be submitted to an IRC Operator, who will notify the staff. From there, a vote will be called. If the vote is passed, the server will be accepted to a testlink period. New IRC servers will be testlinked for 30 days. During this 30-day period, the server must not split more than 3 times, and must not be split for more than 60 minutes in total. The server MUST NOT have ANY O:Lines not permitted by the core administration. Failure to comply with this, will result in the immediate delink of the server. The server administrator will not be able to participate in any network votes while in the testlink period. Once the testlink period has ended, the server's administrator will have full voting rights. The server's administrator may appoint one IRC operator to assist in operation with the server. Any additional operators must go through the voting process outlined below. ***** Network Staff Hiring Policy ***** New network staff will be appointed when there is need. The existing staff will vote in candidates. Ones which stand out, will be queried on IRC, and given a chance to an interview which tests on policy knowledge. After the interview, the existing staff will have a further vote, based on the answers given in the interview. Largest amount of "YES" votes win. In the event of a tie, one of two things can happen. If there are enough openings, both will be appointed. Otherwise, the candidates will be interviewed and voted on again, this time testing more about knowledge of IRC itself, initiative, and what to do in certain situations. ***** Voting Policy ***** Votes may be called by anyone on the staff. Before voting can begin, the vote must be seconded by another member of the staff. When the vote is seconded, all admins may begin voting. A vote will be considered 'passed' if: (yes votes) / (yes and no votes) >= 51%. Each staffer is given 1 vote, administrators and operators on test servers may not vote until the testlink has completed. Voting duration is up to the person who calls the vote, it's advisable to be around 1 week. ***** Current Network Staff ***** - Core Administrators: C405129 Server Sponsor: terra.rfc1337.net Server Sponsor: alioth.rfc1337.net Server Administrator: centauri.rfc1337.net Service Sponsor: services.int Service Sponsor: (test.)psd.int MiFU Server Administrator: terra.rfc1337.net Server Administrator: alioth.rfc1337.net Server Administrator: centauri.rfc1337.net Service Administrator: services.int Service Administrator: (test.)psd.int - Server Sponsors: Eruanna Server Sponsor: centauri.rfc1337.net Service Operator: services.int Service Operator: (test.)psd.int - IRC Operators: RaymondTracer IRC Operator: terra.rfc1337.net IRC Operator: alioth.rfc1337.net IRC Operator: centauri.rfc1337.net Service Operator: services.int Service Operator: (test.)psd.int Set_Abominae IRC Operator: terra.rfc1337.net IRC Operator: alioth.rfc1337.net IRC Operator: centauri.rfc1337.net Service Operator: services.int Service Operator: (test.)psd.int Wartorn IRC Operator: terra.rfc1337.net IRC Operator: alioth.rfc1337.net IRC Operator: centauri.rfc1337.net Service Operator: services.int Service Operator: (test.)psd.int Nixcluster IRC Operator: terra.rfc1337.net IRC Operator: alioth.rfc1337.net IRC Operator: centauri.rfc1337.net Service Operator: services.int Service Operator: (test.)psd.int Updated: 14/08/2010 23:32 UTC+10