1 · What is a channel?
A channel is a room where users meet other users and discuss a certain topic. A channel can be registered and owned by anyone. The person who registers a channel with ChanServ is called the founder. ChanServ is DALnet’s channel registration service that is free for anyone who wishes to open his or her own channel and run it.
Channels are maintained by channel operators to make sure that the channel runs in a smooth order. They are able to kick and ban users with or without reason. Therefore, the founder would not lose the channel within a month due to inactivity. It should be taken into consideration that different channels have different rules and ways of handling issues. Setting of channel rules and policies are at the discretion of the channel’s management.
2 · Creating and registering a channel
Creating and registering a channel is an easy and painless procedure. Once the channel is registered, you have full control over how to run and manage it. Before registering a channel, please be sure you own a fully registered nickname with NickServ. If you haven't, please read http://docs.dal.net/docs/nsemail.html. Once you are done registering your nick, you are all set to register a channel.
Firstly, to create a channel, select a channel name and type /join #channelname. Example, if you wish to select the channel name #FleetStreet, you will type /join #fleetstreet. Be sure you have Ops (@) besides your nickname. To be sure the channel has not been registered to someone else, use /chanserv INFO #channelname where in this example, you will use /chanserv info #fleetstreet. Note that you have to include # before the channel name when registering channels and amending their options. If you get:
-ChanServ- The channel #fleetstreet is not registered.
it means the channel is open for you to register it. To register a channel, you can use /chanserv REGISTER #channelname [password_here] [channel_description]. In this example, we will register the channel #FleetStreet using ToRnAdO as the password and A Cool Chat Channel as its description. So, you will type:
/chanserv register #FleetStreet ToRnAdO A Cool Chat Channel .
Please remember that passwords are case sensitive. Example, STAR and star are not the same. If you do forget the channel password, you may use /chanserv SENDPASS #channelname [founder’s_email]. Please take note that in the event you have MAILBLOCK on, you cannot retrieve the channel password. Also remember to change your passwords regularly and not share them with anyone. For help with choosing passwords, please refer to http://docs.dal.net/docs/passwords.html.
Once done, you will get a response message from ChanServ informing you it was successful and some important information that is important to be read. For more information on ChanServ commands and options, you can refer to http://docs.dal.net/docs/chanserv.html.
3 · How can I make my channel grow?
This is the most common question channel founders ask after registering their channels. The main key to a channel’s success is patience. A new channel cannot grow overnight and there are many things you need to consider before you get the channel really moving. Mass inviting is against DALnet's policies and may lead to your channel being closed. You may read section 6.1 for more information on mass inviting and its consequences. Ask yourself what has the channel got to offer the users. Set a topic that would be of interest to all channel users. Try not to be too hard on the users. A good channel founder must know how to make users "feel welcome" to the channel. When a user enters a channel, first thing they look at is at the topic. Be sure not to have anything that might offend users and cause them to leave. The idea here is to Treat people the way you want to be treated.
When setting channel rules, be sure to be fair to all users. No one likes double standards. Use kicks and bans moderately and only when necessary. Adding wide bans unnecessarily will lead to nothing but an empty channel. Be fair-minded and treat everyone the same way you want to be treated. The most common channel rules are no flooding, no spamming, no advertising/ inviting and no begging for Ops. The rest will depend solely on you; the founder and the rest of the channel’s management.
There are many ways of making your channel popular. These include having a game bot, or a support channel for a good cause. Channels gain their popularity by word of mouth. In order for your current visitors to invite their friends, there must be something to attract users. Have a channel website and put up some useful information on your channel there that might be of interest to the users. It is recommended not to clone another channel just to challenge. Example, #optraining and #trainingop. It would show the lack of creativity on the founder's part and make users think that there has been some sort of problems. Channels created should have a clean and positive environment for everyone.
4 · What is XFLAG and how to Enable?
XFLAG is a new command to protect your channel from floodbots, to enable it you will need to use the recommended option
Syntax: /ChanServ XFLAG #channel RECOMMENDED
For more information about XFLAG, please visit the document http://docs.dal.net/docs/chanflags.html
5 · Channel Security and Problems
The one thing users need to know is how to secure their channel. In this section, we will discuss the problems commonly faced by the channel management.
5.1 ChanServ Security Options
One common problem that most channel founders face is Opping of unknown people by his or her SOps/ AOps. This is a threat in some way to the channel’s security. Therefore, DALnet Services has created the OPGUARD option on ChanServ. When this option is turned on, only those who are listed in the channel access list will get Opped by ChanServ.
Another option that is handy is the IDENT option. Because NickServ’s access list (NickServ ACC 2) has its disadvantages especially on dynamic addresses, a user that matches the Op’s nick access list will get Opped by ChanServ though the user is not in the channel access list. For more information on NickServ's access list and how to secure it, please read http://docs.dal.net/docs/nsaccess.html. When the IDENT option is turned on, users must identify to NickServ (NickServ ACC 3) before they get Opped by ChanServ for that channel. OPGUARD and IDENT options enhance the channel security and thus provides relief to the channel founder.
When you first register your channel, your channel's MLOCK (mode lock) is set at +nt-k by default. It is recommended to leave +nt alone. +n prevents external messages from users who are not in the channel. This is extremely useful to prevent external flooding. +t on the other hand prevents non channel operators from changing the topic.
It is not recommended to use LEAVEOPS and UNSECURE options. When you turn LEAVEOPS on, the first Op that joins the channel will not be deopped by ChanServ. If UNSECURE is turned on, the channel founder does not need to identify to ChanServ to change the channel settings. Please take note that both of these options do have their advantage but pose a security threat. The LEAVEOPS option does not secure an empty channel and may cause problems. When UNSECURE is turned on, anyone that has identified to the founder's nick or has an access that matches the founder's nickname access list will be able to change critical channel settings. These 2 options are best not to be used.
5.2 Selecting Channel Operators
This is a very important decision in a channel management and where security is concerned. Channel operators are the ones whom the founder depends on to manage a channel during his or her absence. They are there to maintain the channel ensuring that nothing goes out of hand. There are 2 kinds of channel operators and have different access all together. They are SOps and AOps.
SOps or SuperOperators are channel operators who are more or less the founder's assistant. They have the ability to add and remove AKicks (permanent bans) and AOps (AutoOperators). Basically, selection of these Ops should be done carefully. It is recommended to add someone who has a sound knowledge on IRC, DALnet Services and Channel Security. AOps or AutoOperators have limited access and cannot amend channel access lists. They should have a sound knowledge on basic IRC commands and DALnet Services and channel security.
Selecting channel operators should not be I will give you access if you give me. This is a common mistake most Ops make and has led to problems within the management of one or both channels. Use your discretion when considering someone to be a potential operator. Work with him in the channel and observe his skills and knowledge. An interview too will help you evaluate his knowledge and is a time for sharing and exchanging ideas.
5.3 Flooding
A channel flood is not only disruptive but also a menace and slows things down. Flooding can be in the form of text, notice, ctcp or even join/ part. All these cause panic among users. This section will guide you how to sort this problem. As a channel operator, you have the ability to set channel modes. The following channel modes are recommended as soon as you spot a flood:
+m Moderates the channel preventing anyone who is not opped or voiced from chatting.
+M Only registered nicks may chat in the main
+i Invite only locks flooders who have not gotten in from entering the channel.
+R Only registered nicks may enter the channel since most of these attackers use non-registered nicks.
+c Stops colours included bold, underline, reverse, and etc from being sent to the main channel.
For more information on channel modes, please refer to http://docs.dal.net/docs/modes.html. Note: It is advised not to lock these modes in MLOCK at (-). Doing this will disable the modes from being set in the event a flood takes place.
5.4 Spam
Spamming is another problem that most channels face. Sometimes, they are easy to track down and sometimes it is difficult and you need to look harder to see who these people are. Not all spam can be detected easily by channel operators or bots since there are some that have timer delays set to avoid messaging anyone who is opped or voiced. Drones or ‘relay bots’ are difficult to track down because you don’t see the actual spammer in the channel. Here is what you can do to track down a drone.
Let’s take an example. You join #DALnetHelp and find there is a spammer there but cannot be seen (drone). The nick you got the spam from is UB40. First of all, do a /whois on UB40. It will display the following result.
UB40 is ~pest@219.94.62.166 * bleh
UB40 using broadway.ny.us.dal.net 42nd Street
UB40 has been idle 29secs, signed on Sat Jan 17 20:37:48
UB40 End of /WHOIS list.
Now perform the command /who +ch #DALnetHelp 219.94.62.166. This command searches for anyone with the host 219.94.62.166 on #DALnetHelp. You should get something like this:
#dalnethelp Road_Runner H+ kevin@219.94.62.166:0 Silence is Golden
#dalnethelp End of /WHO list.
So now we know that the infected user is Road_Runner. For more information on dealing with spam, you may refer to http://docs.dal.net/docs/annoy.html#2.
5.5 Channel Desynch
There are a few different things that may get your channel desynched. The most common reason is that the channel does not resynch properly after a netsplit and the settings are different between servers.
There are many means which you can know that your channel is desynched. The first common thing that happen with most DALnet channels is to see ChanServ's behaviour, for example like setting the mode locks for several time and/or keeps changing the channel topic or changing modes repeatedly. You may not see what the other person is saying. Basically you can say that things are not in proper order.
If your channel is not synched properly, go to #operhelp. DALnet staff will help you to synch the channel again.
5.6 Channel Takeovers and Miscellaneous
The one problem that frightens most channel founders is having someone taking over their channel. Someone who knows or has the channel password with or without the founder’s knowledge mainly causes takeovers. There are several causes of this:
1- Sharing of founder’s nick and/ or channel password
2- Sharing of founder’s email account password
3- Identification to services impersonators
4- Using scripts or auto identifiers to identify to services
It is not a good idea to share your passwords with anyone no matter how close you are with that person. Passwords are something private and confidential and it is an access word that helps you gain access to the channel you registered.
When you share the email password, with anyone, that user is able to use SENDPASS to retrieve the channel password (providing the channel's MAILBLOCK is not set on). Setting MAILBLOCK is a good idea if you do not have secured email account but if you set MAILBLOCK on, you will not be able to retrieve the channel password if you lose it.
Identification to services impersonators means identifying to non services eg. ChanServ and NickServ. The 2 common ways of telling if it is real services is that services nicknames have ONLY 8 characters with the first 4 characters represent the service and the last 4 is Serv. Also remember that services ONLY connect to services.dal.net. For more information on services impersonation, please read http://docs.dal.net/docs/ircimps.html.
Using of auto-identification scripts is not safe especially when you share your scripts with others. Some scripts contain backdoors that may not send the password to the actual services. It is best to use the /nickserv identify or /chanserv identify rather than losing your nickname or channel.
Sometimes, channel operators may attempt to takeover the channel by simply kicking and banning other channel operators or even the channel founder and lock them out. Fortunately, services have built-in commands that you can use without the need of being in the channel. If you are kick banned from the channel, you can use the UNBAN command included in ChanServ to remove the ban and enable you to return to the channel. Type /chanserv UNBAN #channel If you're banned again or find that the operator in question is using a script that kick bans you automatically, use /chanserv deop #channelname [nickname]. This will deop the operator in question. Note: You cannot deop someone who has higher access than you have. Example, AOps cannot deop SOps and SOps cannot deop the founder. If you are an SOp or the founder and find that this user is abusive, you can always delete his/ her access without being in the channel. Once you have removed the user and unbanned yourself, you may rejoin the channel. Remember not to op anyone your don't know no matter what the condition is and be careful of how you select your channel staff. It is better to be safe than sorry :-)
Sometimes, you find someone else who is not in the access list is opped and wonder how he/ she got the access. A user may have identified to the Op nick and is using another. To find out how that user got the access, you will use /chanserv WHY #channelname [nickname]. Let's take a look at an example. The nick dungunban is not registered and yet he has Op access in #Fleetstreet. When I typed /chanserv WHY #fleetstreet dungunban, the following will be displayed:
-ChanServ- dungunban has SOp access to #fleetstreet. Reason: Identification to the nickname Road_Runner. Channel Frozen: NO
So, now we know that dungunban has SOp access because he has identified to the nickname Road_Runner.
Another similiar command is the ACC command that tells us the user's access level for that channel. The command is /chanserv ACC #channelname [nickname]. Example, I want to know what access does Road_Runner have in #fleetstreet, I would use /chanserv ACC #fleetstreet Road_Runner. The following will be displayed:
-ChanServ- Road_Runner ACC #fleetstreet 2 (SOP)
For more information on channel access and their levels, please refer to http://docs.dal.net/docs/csaccess.html.
6 · Channels and DALnet’s AUP
DALnet has provided us free Services and ample resources for us to make use of. We should know how to use these resources properly. All DALnet users that connect to the IRC Network are bound by the network’s AUP. Remember that it is a privilege and not a right. You can read the policies at http://www.dal.net/aup . We will now discuss 2 sections of the policy that affect channel operations. They are Mass Inviting and Services Abuse.
6.1 Mass Inviting
Mass inviting includes but not limited to the following:
1- Excessive use of /invite command
2- Mass messaging via scripts/ channel notices/ messages to join their channel(s)
3- Excessive /quit and /part messages that advertises the channel(s)
Mass inviting is not allowed on DALnet due to the fact that this network has over 10,000 registered channels for users to choose from. This is not to say you can’t invite someone to your channel but forcing a user to join, mass messaging every user on other channels or even on the network is considered against the network’s AUP and is dealt with seriously including warnings, mass kicks and closing of the channels.
To know more on the Mass Advertising policy, please visit http://kline.dal.net/massads/mup.htm.
6.2 Services Abuse
DALnet services are provided for the convenience of its users including registration of nicks and channels as well as the maintenance of such. Users must make sure to use them carefully in order to avoid abusing them. Services Abuse can include Spamming/ flooding users via MemoServ, and flooding services. The DALnet Services Abuse Team which is inline with the Services Root Administrators (SRAs) and a sub- team of KLine is responsible for enforcing these regulations.
Registering channels should be done moderately and common sense should be used. There is no necessity to register channels for the sole purpose of preventing others from using them. Selling and trading of channels (including channel access) is not allowed on DALnet since its services are free for all.
Flooding ChanServ includes misuse of the MKICK and MDEOP commands and repeated identification to services in a short period of time. Mass commands like MKICK should only be used once and when necessary. You only need to identify to services once. Please be patient and wait for a response from ChanServ. Kicking of channel ops repeatedly causing ChanServ to reop them on their return to the channel is also an abuse. Please do not do them even in fun.
Depending on the severity of the offence, a channel can be frozen/ closed or a user could be completely ignored by services. For more information on Services Abuse, please read http://kline.dal.net/sabuse. If you have any questions regarding services abuse, you may email sabuse@dal.net.
7 · Summary
All Channel Operators and non-Ops should work together in developing a channel. It works both ways. Without Ops, the channel will be in a disastrous state, and drives the founder to sacrifice his channel to another random user to take due to inactivity. Without the users, it defeats the purpose of having the channel in the first place. It is best to select a channel name wisely. A name that will attract users. Patience and creativity is the main idea of a channel's growth. A good host (channel operator) knows how to treat his guests right.
The channel founder is solely responsible for all the happenings in the channel. Learn how to secure the channel. Train your SOps and AOps on channel security and channel management. Learn the necessary steps need to be taken in an emergency like flood and attempted takeover situations.
All users are bound to the network's policies. When you connect to the network, we assume that you have read and have fully understood the network's policies. Ignorance is not an excuse. DALnet reserves the right to remove anyone who is found to have breached the network's policies.
Hopefully, this document has given you some ideas on what to expect and how to face the problems and resolve them :o)
8 · Credits
There are a few people who have helped me in writing this document. Firstly, I would like to thank the Documentation Team Leader; Fredfred, ssr and Kzoo for giving me ideas on the outline for this document and also special thanks to squirrel and LadyDana who have helped me too along the way. Not forgetting the staff of #DALnetHelp who have given me their support and training. I could not have created this document without you guys ;)
Please direct any comments or feedback about this document (only! no help requests!) to docs@dal.net. If you need help on issues not covered in this document, please see the information at http://help.dal.net.