Controls whether services will add the default access mask when you register a nickname. "OFF" means no access list is added. "ON" means that the default access list will be added.
Example:
/as services set acclists on
This will still give users the control of being able to add access masks but does not do it for them.
Controls whether services will add the default access mask when you register a nickname. "OFF" means no access list can be added. "ON" means that the default access list will be added.
Example:
/as services set acclists on
This will disable the ability for services to add access lists to nicknames.
Normal: Newly registered nicknames will require positive identification before access to the nickname is granted.
High: Enables the 'aggressive protection' mode for nicknames. When enabled, if you attempt to use a nickname that you do not have access to, services with immediately change your nickname to Guest.
Example:
/as services set autoprotect high
/as services set autoprotect off
The reason that we don't enable this by default is that new users that are not familiar with chat will register a nickname, disconnect and then when they reconnect they don't know the NICKSERV IDENTIFY command. So you might want to give some thought to how your user base will deal with this being enabled. An Enterprise Edition only feature.
Enables the 'enhanced security' mode for nicknames. When enabled, NickServ does not check access lists at all, and positive authentication via password is required before you can use your nickname.
When this is set to high services will aggressively protect a nickname and when it detects that a nickname is being used the user will be switched to guest nickname.
Example:
/as services set autosecure high
/as services set autosecure on
When high mode is used users must identify to their nicknames prior to using them.
Enables or Disables the buddy list feature set.
Example:
/as services set buddylists on
An Enterprise Edition only feature.
This command sets how many days a room must go without services opping anyone before it expires.
Example:
/as services set chanexpire 30
Expiration is important because it frees up rooms that are no longer being used or properly managed for others to take over and run. This is especially important if room registration is open to all users. Many users will register rooms and then forget about or abandon them. Short expiry times make it easier for new users to find good room names. However, too low an expiry time will cause people's rooms to expire too easily. Even well managed rooms may have quiet times, especially if most of the users are students and have vacations at the same time.
This command sets the default trigger level for clone warnings. Clone warnings go off when there are multiple users from the same address.
Example:
/as services set deftrigger 7
Low trigger values will pick up several legitimate sources for multiple users from the same address, primarily cybercafes. Although you can set custom triggers for specific addresses, see SECURITY TRIGGER. A large default trigger will fail to pick up many examples of harmful clones. A setting between 5 to 12 is probably best and then each warning can be investigated and dealt with appropriately.
The folder commands set the limits for how many folders each user can have, how many memos each folder can hold, and how many memos from the same nick each folder can hold. The FOLDER commands work with MemoServ, which is an Enterprise-only feature.
CAPACITY - Set how many memos each folder can hold or how many memos from the same nick each folder can hold.
LIMIT - Sets how many folders each user may have.
Examples: /as help services set folder <topic>
When setting your folder limits, decide how you want to your users to use MemoServ and set limits that encourage that use. Larger limits will make memos more useful and encourage their use. Smaller limits may encourage users to only send memos for quick notes and to use other options, such as email, for more important messages.
Granularity works with clone alerts. After the first clone alert is triggered, the granularity determines when a second clone alert is sent if the user keeps adding more clones. If the trigger is at 10 and the granularity is at 5 then the next warning comes at 15, another at 20, and so forth.
Example:
/as services set granularity 6
Larger granularities decrease the number of clone warnings, which can be useful on larger networks. Smaller granularities make it more obvious which clone alerts need to be dealt with more urgently. Hosts that increase rapidly are almost always harmful clones, since valid hosts such as cybercafes will rarely have users all deciding to log in to your server within seconds of each other.
This command sets the host name for your services. It will show up when people /whois the nicks for any of the services and also in the messages sent with kills.
Example:
/as services set host webmaster.com
Your host should probably be set to something related to your network. This is merely an aesthetic detail, it doesn't affect the actual operation of the chat server, but allows for a more professional or personalized appearance for your network. For other commands that customize the appearance of services see SET USER and SET HOST.
Have NickServ log all e-mail addresses used to register nicknames.
Example:
/as services set logemail enable
An Enterprise only feature.
This command sets the type of network that you are running. The default is CRnet, which stands for ConferenceRoom network.
Example:
/as services set network CRnet
This information will show up at times when a response includes the network type. It is an aesthetic detail rather than a functional one.
This command lets you set how many days without use it takes before a registered nickname will be dropped.
Example:
/as services set nickexpire 25
As with CHANEXPIRE, the larger the expiry time the harder it will be for new users to find available nicks. But the lower the expiry time the more difficult it is to keep them. The nickexpire should probably allow for moderate vacations or temporary loss of internet access without causing the user to lose a nick, but still be small enough to clean out unused nicks. Especially since some people will register nicks and either forget they had them or become bored with chat and stop altogether. A limit between 20 and 35 is probably good.
Makes services act in PASSIVE mode -- nobody will get opped/voiced by ChanServ unless they explicitly ask services to do so using the OP command.
Example:
/as services set passive enable
An Enterprise only feature.
This command will configure how services will allow users to register channels. You can disallow all users, let all users or only allow server operators:
Disable: Channel registration is not enabled.
Open: All users can register channels.
Opers: Only Server Operators can register channels.
Example:
/as services set regchan open
/as services set regchan opers
/as services set regchan disable
You could, in theory, only allow the registration of rooms. But since having a registered room requires a registered nickname, this is not a generally useful configuration. You can disallow both, allow both, or allow only registration of nicknames. The advantage of only allowing nick registration is that you can set up all the rooms you want in advance and then close registration.
This command will configure how services will allow users to register nicknames. You can disallow all users, require email verification, let all users without verification or only allow server operators:
Disable: Channel registration is not enabled.
Open: All users can register channels.
Opers: Only Server Operators can register channels.
Verified: Used when you want to have email verification for nicknames.
Example:
/as services set regnick disable
/as services set regnick open
/as services set regnick verified
/as services set regnick opers
If verified is set then you must have an SMTP server configured otherwise this will default to open.
This allows users to get operator status via a password that is set inside services. This allows for a single point of management for network operators.
Example:
/as services set remote-oper enable
OperServ is only configured on multiple Enterprise Edition installations.
This command sets the name of the server that the services' clients run on. This will show up when people /whois any of the nicks services use or in a /link command. The default setting is services.net.
Example:
/as services set servername services.net
The server name is another aesthetic detail that allows you to customize your network. You can make it look more professional or more personal as you see fit. For other commands that customize the appearance of services see SET USER and SET HOST.
This will define the SMTP server that services will use for nickname registration.
Example:
/as services set smtp 127.0.0.1
Make sure that the smtp server you select will allow this server to use it as a relay. If no SMTP server is set services will not use registration verification.
The type can be one of the following:
register, verify, drop, email-change, passwd-change, passwd-request
Example:
/as services set template verify verify.tem
The filename is optional. It is relative to the root of the CR install, so if you have your file in db/mail/templates you should use "db/mail/templates/mymailtext.txt" as the filename used. If it is not specified, services will use a default mail template.
If the same host keeps setting off clone alerts, then services will send a message saying it is stopping alerts concerning that address. It will then stop sending alerts for a number of seconds equal to the throttle setting. This is designed to prevent network operators from being flooded with redundant information.
Example:
/as services set throttle 30
A good throttle should probable be between 15 and 45. That gives the network operators a chance to deal with the clones, but allows for new warnings if necessary.
This command sets the ident for services. It will show up whenever a user does a /whois on one of the services' nicknames or when services sends a kill.
Example:
/as services set user chatservices
This ident is another aesthetic detail that you can customize. This command along with SET HOST and SET SERVERNAME allow you to control exactly what your services look like.