Provided by: jabberd14_1.6.1.1-5.1ubuntu1_i386 bug

NAME

       jabber.xml - jabberd daemon configuration file

SYNOPSIS

       The  jabber  daemon jabberd is configured by an XML configuration file.
       By default jabberd will read  /etc/jabber/jabber.xml.  The  -c  command
       line option can be used to specify an alternate configuration file.

FILE FORMAT

       The configuration file has to be a valid XML document preferably in the
       UTF-8 charset (ASCII is valid subset of UTF-8).

       Within  the  following  xpath  expressions,  the  following   namespace
       prefixes are used:

       default  namespace:  "jabber:server",  browse: "jabber:iq:browse", cfg:
       "http://jabberd.org/ns/configfile",   register:   "jabber:iq:register",
       vcard: "vcard-temp",

       <jabber/>
              This is the root element of the configuration file.

       <service/>
              This element is an immediate child element of the <jabber/> root
              element.  It defines a general purpose component in  the  jabber
              daemon.  The  jabber  daemon  will  route  all  stanzas  to this
              component that have a domain part in the  destination  JID  that
              equals  the  id attribute or any defined additional domains this
              component is responsible for using the  <host/>  child  element.
              An  implementation  or  relation  to an other process is defined
              using  one  of  the   following   child   elements:   <accept/>,
              <connect/>,  <dynamic/>,  <exec/>,  <load/>,  <null/>. Any child
              elements in own namespaces are ignored by the core  jabberd  and
              can be used by components to store their own configuration.

       <xdb/> This element is an immediate child element of the <jabber/> root
              element.  It defines a component in the jabber daemon,  that  is
              responsible  for  XML  data  storage.  This  components internal
              address is defined  by  the  id  attribute.  The  <host/>  child
              elements  define  for  which  domains  this storage component is
              managing the data. An empty <host/> element defines, that it  is
              responsible for all components. With the <ns/> child element you
              can limit the responsibility to XML chunks in  a  given  set  of
              namespaces.   You  can  then  for  example  define  one  storage
              component that handles rosters and an other that handles offline
              message  storage.   An  implementation  or  relation to an other
              process is defined using on of  the  following  child  elements:
              <accept/>,  <connect/>,  <dynamic/>,  <exec/>, <load/>, <null/>.
              Any child elements in own namespaces are  ignored  by  the  core
              jabberd  and  can  be  used  by  components  to  store their own
              configuration.

       <log/> This element is an immediate child element of the <jabber/> root
              element.  It defines a component in the jabber daemon, that acts
              as a logging sink.  This components internal address is  defined
              by the id attribute. The <host/> child elements define for which
              domains this logging sink is logging messages.  An empty <host/>
              element  defines,  that  it  is  responsible for all components.
              With the <logtype/> child element you can select  the  types  of
              messages,  that  are  handled by this component.  Where to write
              the logging information is defined with  one  of  the  following
              child  elements: <file/>, <stderr/>, <stdout/>, <to/>.  With the
              <format/> child element you define  the  format  of  the  logged
              message.

       <io/>  This element is an immediate child element of the <jabber/> root
              element.  In this section of  the  configuration  file  you  can
              define  different  settings  that are related to the network I/O
              layer. This includes bandwidth limitations (using  the  <karma/>
              element),  assigning  X.509  certificates  to sockets (using the
              <tls/> element), and to limit access to the server  to  specific
              IP address ranges (using the <allow/> and <deny/> elements).

       <pidfile/>
              This element specifies to which file the server should write its
              process ID.  If this file already  exists  when  the  server  is
              started,  it will fail. You have to remove stale pidfiles before
              starting the server yourself. If  you  omit  this  element,  the
              server will not write nor check any pidfile.

       <debug/>
              This  element  contains  configuration  settings controlling the
              output of debugging messages. These settings can be  changed  at
              server  runtime,  the  server  will  reread  them on receiving a
              SIGHUP signal.

       The following elements are used  inside  the  <service/>,  <xdb/>,  and
       <log/>
              elements, that are defining components. They are used to provide
              the jabberd process with  information  where  it  can  find  the
              component's implementation.

       <load/>
              This  element  can  be  used inside any component definition. It
              specifies, that the implementation of the component can be found
              inside  a  shared  object.  Any  child  element  of this element
              defines a shared object  file  and  a  method  in  this  object.
              jabberd  will  load  the shared object files which locations are
              defined in the cdata elements inside  the  child  elements,  the
              names of the elements are defining the functions that have to be
              called. An optional main attribute in the <load/> element define
              the  main  function  in  a  component,  that  has  to be used to
              initialize it.

       <accept/>
              This element defines, that jabberd will  wait  for  an  incoming
              connection using the jabber:component:accept protocol defined in
              XEP-0114. With this it is possible to run  components  in  their
              own  process, even on different hosts and connect it to the main
              jabberd routing process. On the  other  end  of  the  connection
              there  can  be  an instance of jabberd again that uses a section
              with <connect/>  to  initiate  the  connection,  but  there  are
              libraries   in   many   programming  languages  available,  that
              implement XEP-0114 as well.  Inside this  element  you  have  to
              provide  an <ip/> element, that defines the IPv4 or IPv6 address
              to listen on, a <port/> element that defines on which  port  the
              server  will listen for the connection, and a <secret/> element,
              that defines a shared secret to authenticate the other peer.

       <connect/>
              This element is the opposite of the <accept/>  element.  Jabberd
              will    try   to   connect   to   an   implementation   of   the
              jabber:component:accept protocol defined  in  XEP-0114.   Inside
              this  element you have to provide an <ip/> element, that defines
              the IPv4 or IPv6 address where to connect to, a <port/> element,
              that defines the destination port, and a <secret/> element, that
              defines a shared secret to authenticate to the other peer.

       <file/>
              This element can only be used inside a  <log/>  section.  It  is
              used  to  specify that log messages should be appended to a text
              file.

       <null/>
              This element specifies an empty component.  Everything  that  is
              sent  to  a  JabberID  with the domain part of this component is
              silently discarded. It can be used to drop stanzas  directed  to
              entities  on  the  Jabber  network,  that have disappeared (e.g.
              update.jabber.org).

       <stderr/>
              This element can only be used inside a  <log/>  section.  It  is
              used  to  specify  that  log  messages  should be written to the
              standard error output stream.

       <stdout/>
              This element is used to define,  that  the  jabberd  process  is
              communicating   with  the  process,  that  is  implementing  the
              component. It is the opposite of  <exec/>.  A  process  that  is
              started  by  <exec/>  in  an  other process can use <stdout/> to
              implement the other end of the connecting pipe.

       <syslog/>
              This element can only be used inside a  <log/>  section.  It  is
              used  to  specify  that  log  messages  should be written to the
              syslog.

       <to/>  This element can only be used inside a  <log/>  section.  It  is
              used  to  reformat log packets as messages and resend them to an
              entity with the given JabberID. The JabberID is given  as  cdata
              child element.

       <unsubscribe/>
              This element can only be used inside a <service/> section. It is
              used to bounce messages and iq queries and send unsubscribes  to
              presences,  that  are  received.  It is intended to be used as a
              replacement for transports, that are removed from a  server.  It
              will  remove  the roster items of this transport from the users'
              rosters.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/browse:browse
              List of services, that should be returned as  the  result  of  a
              browsing  or  a service discovery request. The format is as in a
              browse result stanza.

       jsm   setting:   cfg:jabber/cfg:service/jsm:jsm/disco-info:disco/disco-
       info:identity
              Name  of the Jabber server, that should be returned in a service
              discovery reply.  If this is not configured, the FN field of the
              server's                                                   vCard
              (cfg:jabber/cfg:service/jsm:jsm/vcard:vCard/vcard:FN) is used.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:admin/reply
              Message, that should be returned to someone,  that  has  sent  a
              message to the servers address. (These messages are forwarded to
              all users having the 'adminmsg' ACL right.)

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:agents
              This configuration setting can contain a response of  a  iq  get
              query   in   the   jabber:iq:agents  namespace.  Using  this  is
              deprecated. You should not use this configuration  setting.  The
              jabber:iq:agents namespace is superseded by service discovery.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:archive
              Configure the JabberIDs where mod_log should send messages about
              created sessions to. The  JabberIDs  should  be  enclosed  in  a
              <service/>  element.  Multiple <service/> elements can be placed
              inside the <archive/> element.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:auth
              Redirect authentication handling (non-SASL only) to a component.
              The  address  of  the  component  has to be given as the textual
              content of this configuration element. No default setting.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:history
              With this element, the session manager can be configured to send
              copies  of  received  and sent messages to xdb. This can be used
              for logging or to implement  web-based  access  to  the  message
              history.  The  history element contains two child elements: sent
              and recv. The sent element configures how  messages  sent  by  a
              user  are  handled.  The  recv  element  configures how messages
              received by a user are handled.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:maxusers
              The maximum number of users the server should expect per  domain
              (more  users  will  get  handled,  but  it  may have performance
              impacts). A prime number should be configured here. The  default
              setting is 3001.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:mod_auth_crypt/jsm:hash
              The default password hashing algorithm used by mod_auth_crypt is
              crypt().  With this setting you can select other  algorithms  by
              adding their name as the text inside this element. Currently the
              only other algorithm supported by mod_auth_crypt is  "SHA1".  It
              is   not   recommended   to  use  mod_auth_crypt.   With  hashed
              passwords, you get problems when you want  to  migrate  to  SASL
              authentication.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:mod_offline
              With  this  it  can  be  configured  which  messages  are stored
              offline. The default is to only store normal and  chat  messages
              offline  (bouncing  headline  and  groupchat  messages, dropping
              error messages). If the mod_offline  element  is  present,  only
              message  types  present in this element are stored offline.  Use
              the following element  names  inside  this  element:  <normal/>,
              <chat/>, <headline/>, <groupchat/>, and <error/>.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:mod_useridpolicy
              Define  a  policy  for  usernames,  that  should  be enforced on
              account registration (i.e. already registered usernames are  not
              affected).   It   is  possible  to  block  accounts  from  being
              registered based on special names (put  the  username  inside  a
              <forbidden/>   element,  e.g.   <forbidden>root</forbidden>)  or
              enforce length constraints on the username by defining a minimum
              and/or maximum length of the username in unicode characters (put
              the  setting  inside  <minlen/>  and  <maxlen/>  elements,  e.g.
              <minlen>3</minlen>).

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:mod_version
              Modify  the  result  to  a  jabber:iq:version  request. With the
              <name/>  element  inside  this  configuration  option,  you  can
              replace  the  product name, that is returned by the server. With
              the <version/> element, you can  replace  the  returned  product
              version.  With  the <os/> element, you can replace the operating
              system  identification  returned  by   mod_version.   With   the
              <no_os_version/>  element,  you  can  configured  mod_version to
              return the name of the operating system,  but  not  its  version
              number.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:presence
              This  configuration  option  can include two different elements:
              With the <presence2xdb/>  element  you  configure  jabberd14  to
              store  all  presences  of  the local users to xdb. Used together
              with xdb_sql this can be used to have the presence of your users
              in  a  SQL  database,  e.g.  to  use  it  to  display web status
              indicators.  (Please  recognize  the  privacy  issues  with  web
              indicators  if  you  plan to implement this.) The other possible
              element inside this configuration option is <bcc/> which can  be
              used  multiple  times.  Inside  the <bcc/> element you can place
              JabberIDs.  All local  presences  are  send  to  the  configured
              JabberIDs  as a copy.  This can be used to forward presence to a
              component, that needs to know presence of all local users. (E.g.
              another way to implement a web presence indicator.)

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:regtimeout
              This  configures  the  number of seconds an account gets blocked
              against reregistration after it has been unregistered. The value
              is specified as the timeout attribute of this element.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:serialization
              With this setting the session manager can be configured to store
              all necessary state information to restart the  session  manager
              to  a  file.   This  can  be used to restart the session manager
              after a crash (or after it has been killed by a signal)  without
              the  user's  sessions  to  be  dropped.  This  can  be  used  to
              reconfigure the session manager  while  it  is  running.  Please
              note,  that  on  very  big jabberd14 installations you might get
              problems if you serialize the state to often.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:vcard2jud
              If the vCard a users sets  should  be  forwarded  to  the  first
              Jabber     users    directory,    that    is    configured    in
              cfg:jabber/cfg:service/jsm:jsm/browse:browse.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/register:register
              Reply  stanza  to  a  jabber:iq:register   get   request.   This
              configures  what  a client gets asked, if a user tries an inband
              account registration.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/vcard:vCard
              The vCard, that gets returned, if a  Jabber  entity  requests  a
              vCard for the server. No default value.

       jsm setting: cfg:jabber/cfg:service/jsm:jsm/welcome
              A message stanza, that should be sent to a new user. The content
              of the welcome element is used as the content of  the  generated
              message stanza.  Therefore you should have a body element inside
              this one, and a subject element might be good to have  as  well.
              It  is  possible  to  use xml:lang attributes for the content of
              this element. No default setting,  if  element  is  missing,  no
              welcome message is generated.

       TLS settings: cfg:jabber/cfg:io/cfg:tls
              Inside  this  configuration  element you find the settings, that
              configure how TLS is used inside jabberd14. Settings inside this
              element  are  grouped together using the <credentials/> element.
              Every set of settings defined within such an element is used for
              the  set  of  domains,  that  are configured using the <domain/>
              element inside this element. If jabberd14 searches for  settings
              and  does  not  find a set that contains the relevant domain, it
              will search a set that contains the <default/> element. If  even
              no  such  set is found, TLS is disabled for this domain.  (Note:
              This is designed to be used with the STARTTLS mechanism  of  the
              XMPP  protocol.  If  you  are  using  legacy TLS connections for
              clients on port 5223, you have to  configure  the  IP  addresses
              your    are    listening    on   as   domain   as   well.   E.g.
              <domain>192.0.2.34</domain> if you are listening on port 5223 or
              the  IP address 192.0.2.34.)  Beside the <credentials/> element,
              there are three more valid elements, that can be  placed  inside
              the <tls/> element:

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:dhparams
              If   this  setting  is  not  present,  jabberd14  will  generate
              parameters for Diffie  Hellman  keyexchanges  on  the  fly  when
              starting  up.  As this may take some time, you might want to use
              pre-calculated parameters.   Use  this  setting  to  load  them.
              Specify the filename containing the parameters as the content of
              this element. By default the file is expected to by PEM encoded.
              Add the flag type="der" if the file is DER encoded.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:cacertfile
              This  setting  defines a file containing certificates of the CAs
              jabberd14  should  trust   when   authenticating   peers   using
              certificates.  These CA certificates are used as the default CAs
              and can be  overwritten  using  the  <ca/>  element  inside  the
              <credentials/> elements for each set of TLS settings.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:crlfile
              This  setting  allows  you to load a certificate revocation list
              from a file.  Place the filename as the content of this element.
              By default the file is tried to be loaded as a PEM encoded file.
              If the file  is  DER  encoded,  please  specify  the  type="der"
              attribute on this element.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:default
              Define  that  this  set  of  TLS settings should be used when no
              explicit set of settings can be found for a domain.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:domain
              Bind a set of settings to a domain. The domain for which the set
              should  be used has to be placed as the content of this element.
              No whitespace should be present in the content of this  element.
              This   element   can   be   used   multiple   times  inside  the
              <credentials/> element to bind a set  of  settings  to  multiple
              domains.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:pem
              This  setting  is  used  to  load  a  server  certificate  of  a
              certificate chain, that is PEM  encoded.  By  default  jabberd14
              tries  to  read  the  private  key  from  the  same  file as the
              certificate. If you have your private key in a  different  file,
              please  specify  the filename of this file using the private-key
              attribute  on  the  <pem/>  element.   If  you   have   multiple
              certificates  for  the  set  of  domains  (e.g.  a RSA and a DSA
              certificate) you can place multiple  <pem/>  elements  inside  a
              <credentials/>   element.  But  if  your  certificates  are  for
              different  domains,  you  have  to  place  them   in   different
              <credentials/> elements.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:der
              This  is  the  same setting as the <pem/> element, with the only
              difference that the file is expected to be DER  encoded  instead
              of  PEM  encoded.  Please  also  note,  that  with  DER  encoded
              certificates you always have to place  your  private  key  in  a
              different  file,  and  therefore  have  to  use  the private-key
              attribute of the <der/> element.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:ca
              Load one or many certificates of CAs the server should trust  to
              do  certificate  based  authentication  of peers. By default the
              file is expected to be PEM encoded. If the file is DER  encoded,
              you  have  to add the type="der" attribute to this element. This
              element can be used multiple times to load multiple files.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:openpgp
              Load an OpenPGP key as certificate. Specify the file  containing
              the  public  key  as  the  content  of this element and the file
              containing your private key using the private-key  attribute  of
              this element.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:keyring
              Load  an  OpenPGP  keyring  from  the  file  specified using the
              content of this element.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:trustdb
              Load a GnuPG trust database from the file  specified  using  the
              content of this element.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:protocols
              This  setting  is  used  to  specify  which  version  of the TLS
              protocol should be used  and  in  which  order  they  should  be
              prefered.  If  you  omit  this  setting, the protocols and their
              preference are defined by the used TLS library (GnuTLS)  itself.
              Place  the  list  of  protocols in the order of their preference
              separated by whitespace as content of this  element.  Recognized
              values  are: TLS1_2 for TLS version 1.2 (only known if jabberd14
              is compiled with a TLS library supporting this version  of  TLS,
              otherwise  ignored),  TLS1_1 for TLS version 1.1, TLS1_0 for TLS
              version 1.0, and SSL3 for SSL version 3.0  (predecessor  of  TLS
              1_0).  SSL  versions  before  3.0 are not supported by jabberd14
              anymore as they are considered weak.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:kx
              This setting is used to specify which  key  exchange  algorithms
              should  be  used  and in which order they should be prefered. If
              you omit this setting, the algorithms and their  preference  are
              defined  by the used TLS library (GnuTLS) itself. Place the list
              of algorithms in the order  of  their  preference  separated  by
              whitespace  as  content  of this element. Recognized values are:
              RSA for exchanging keys on a RSA encrypted channel, DHE_RSA  for
              using a RSA signed Diffie Hellman keyexchange, DHE_DSS for using
              a DSS signed Diffie Hellman keyexchange. The DHE_* key exchanges
              might need a bit more computing power, but will result in a non-
              compromized key even if your certificate gets compromized.  With
              a  pure  RSA key exchange the encrypted session gets readable if
              your RSA certificate  gets  compromized.  For  RSA  and  DHE_RSA
              keyexchanges  you  need  a RSA certificate when being the server
              side of the connection, for the DHE_DSS key exchange you need  a
              DSS certificate when being the server side of the connection. If
              you are the server (i.e. connected) side of the TLS  connection,
              this  setting will only select which key exchange algorithms you
              support/offer as it is the client's task to select  one  of  the
              offered  algorithms. Therefore the order of this setting is only
              relevant if you are the connecting side  of  a  TLS  connection.
              (Note:  ANON_DH is supported as well and results in an anonymous
              Diffie Hellman keyexchange. Normally you do not want  to  enable
              this  key  exchange, please only enable it, if you know what you
              are doing.)

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:ciphers
              This setting is used to specify which cipher  algorithms  should
              be  used and in which order they should be prefered. If you omit
              this setting, the ciphers and their preference  are  defined  by
              the used TLS library (GnuTLS) itself.  Place the list of ciphers
              in the order of their  preference  separated  by  whitespace  as
              content  of  this element. Recognized values are: AES_256_CBC is
              the AES cipher using a 256 b key in CBC mode, AES_128_CBC is the
              AES  cipher  using a 128 b key in CBC mode, 3DES_CBC is the 3DES
              cipher using 168 b key (effective strength is considered  to  be
              only  112  b)  in  CBC  mode,  ARCFOUR_128 is the ARCFOUR stream
              cipher using a 128 b key.  (The following ciphers are recognized
              as well, but you normally should not configure them: ARCFOUR_40,
              RC2_40_CBC, DES_CBC, NULL. Only allow these additional  ciphers,
              if  you  know exactly what you are doing. They are considered to
              be weak ciphers.)

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:compression
              This setting is used to  specify  which  compression  algorithms
              should  be  used  and in which order they should be prefered. If
              you omit this setting,  the  compression  algorithms  and  their
              preference  are defined by the used TLS library (GnuTLS) itself.
              With  current  versions   of   GnuTLS   this   means   disabling
              compression.   Therefore   if   you   want  to  use  TLS  stream
              compression, you have to define this setting. Place the list  of
              compression   algorithms   in  the  order  of  their  preference
              separated by whitespace as content of this element.   Recognized
              values  are:  LZO  for compression using the LZO algorithm (only
              supported if GnuTLS extra  has  been  found  on  compilation  of
              jabberd14, ignored otherwise), DEFLATE for compression using the
              deflate/gzip  algorithm,  NULL  for  no  compression.  The   LZO
              algorithm  might  have  a  better  performance  than the DEFLATE
              algorithm.

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:mac
              This setting is used to specify which MAC algorithms  should  be
              used  and  in  which  order they should be prefered. If you omit
              this setting, the algorithms and their preference are defined by
              the  used  TLS  library  (GnuTLS) itself.  Place the list of mac
              algorithms  in  the  order  of  their  preference  separated  by
              whitespace  as  content  of this element. Recognized values are:
              NULL  (for  using  no  MAC),  MD5,  SHA1,   RMD160,   MD2   (not
              recommended),  SHA256,  SHA386,  SHA512.   This  setting  is for
              expert users only. Normally you  want  to  leave  the  defaults.
              (SHA256,  SHA386  and  SHA512 are only present if the underlying
              TLS library support them.)

       TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:certtypes
              This setting is used to specify which certificate  types  should
              be  used and in which order they should be prefered. If you omit
              this setting, the types and their preference are defined by  the
              used  TLS  library  (GnuTLS)  itself.  With  current versions of
              GnuTLS this means only supporting X.509 certificates,  which  is
              what you currently normally want to use. Place the list of types
              in the order of their  preference  separated  by  whitespace  as
              content  of this element. Recognized values are: X.509 for X.509
              certificates and OpenPGP for using OpenPGP keys as certificates.

AUTHOR

       jabberd14 project