of normal text messages in the SILC network. The session to SILC server
is secured with session key, channel messages are protected with channel
key and private messages with session keys. It is also possible to use
-private channel keys and private message keys in addition of server
+private channel keys and private message keys in addition to server
generated keys.
bf(Silc) supports em(passphrase) authentication and public key authentication
The SILC public key and private key pair is used to authenticate the user
to the SILC server when connecting a server. This key pair is created
-automatically when the bf(silc) is run for the first time. It also can
+automatically when the bf(silc) is run for the first time. It can also
be created with bf(-C) option.
When connecting for the first time to SILC server, user will be asked to
manpagesection(CONFIGURATION FILE)
The bf(silc) configuration file is bf(~/.silc/silc.conf) and can be used
-to configure the behavriou of the client. The configuration file format
+to configure the behaviour of the client. The configuration file format
is equivalent to Irssi IRC client's configuration file. See the
documentation for the configuration file at bf(http://irssi.org).
quote(The SILC private key of the user)
bf(~/.silc/clientkeys/)
-quote(The directory holding the public keys of other users the user have
+quote(The directory holding the public keys of other users the user has
accepted and trusted in the SILC network. The public keys can be received
with bf(GETKEY) SILC command or during key agreement between two users.)
bf(~/.silc/serverkeys/)
-quote(The directory holding the public keys of servers the user have accepted
+quote(The directory holding the public keys of servers the user has accepted
and trusted when connecting to a server.)
bf(~/.silc/friends/)
be defined before the em(ConnectionParams) section. On the other hand,
the em(ConnectionParams) section must be defined before em(Client),
em(ServerConnection) and/or em(RouterConnection) sections. Other sections
-are be in free order in the configuration file.
+can be in a free order in the configuration file.
nsect(SECTION: General)
the maximum time any channel can have the same key.)
bf(detach_disabled)
-quote(Boolean value controlling, whether clients are denied to use DETACH
+quote(Boolean value controlling, whether clients are denied the use of DETACH
command. Default value is false (DETACH is allowed).)
bf(detach_timeout)
automatically correspond to amount of messages transmitted or accepted.)
bf(qos_bytes_limit)
-quote(Limits incoming SILC data to the specified bytes per second.)
+quote(Limits incoming SILC data to the specified number of bytes per second.)
bf(qos_limit_sec)
-quote(This value defines the timeout, in seconds, the delay for received data
-in case it was left in a QoS queue.)
+quote(This value defines the timeout, in seconds, for the delay of received
+data in case it was left in a QoS queue.)
bf(qos_limit_usec)
-quote(This value defines, in microseconds, the delay received data for received
-data in case it was left in a QoS queue.)
+quote(This value defines the timeout, in microseconds, for the delay of
+received data for received data in case it was left in a QoS queue.)
nsect(SECTION: ServerInfo)
bf(MotdFile)
quote(Full path to MOTD (Message Of The Day) file, a text file that will be
-displayed to each client connection.)
+displayed to each client upon connection.)
bf(PidFile)
quote(Full path to file where silcd will write its PID.)
bf(reconnect_keep_trying)
quote(Boolean value controlling whether server eventually gives up trying
to reconnect. If set to em(false), server will give up once em(reconnect_count)
-is reached or even at maximum interval, no connection is established.)
+is reached or, even at maximum interval no connection is established.)
bf(key_exchange_rekey)
quote(Exactly the same as in em(General) section.)
nsect(SECTION: Client)
This section defines how incoming client connections are handled. There can
-be several em(Client) sections, each with their own requirements. A silcd admin
-could for example require that connections from certain IP-address space must
-supply a connection password.
+be several em(Client) sections, each with their own requirements. A bf(silcd)
+admin could for example require that connections from certain IP-address space
+must supply a connection password.
bf(Host)
quote(An address or wildcarded set of addresses, either in numeric IP-address
incoming connection.)
bf(Reason)
-quote(A string giving the reason for why the connecting party is not allowed
+quote(A string giving the reason as to why the connecting party is not allowed
to connect. Unlike em(Host), this field IS mandatory.)