view dccd.html.in @ 6:c7785b85f2d2 default tip

Init scripts try to conform LSB header
author Peter Gervai <grin@grin.hu>
date Tue, 10 Mar 2009 15:15:36 +0100
parents c7f6b056b673
children
line wrap: on
line source

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
<HEAD>
    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
    <TITLE>dccd.0.8</TITLE>
    <META http-equiv="Content-Style-Type" content="text/css">
    <STYLE type="text/css">
	BODY {background-color:white; color:black}
	ADDRESS {font-size:smaller}
        IMG.logo {width:6em; vertical-align:middle}
    </STYLE>
</HEAD>
<BODY>
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->
<B><A HREF="dccd.html">dccd(8)</A></B>               Distributed Checksum Clearinghouse               <B><A HREF="dccd.html">dccd(8)</A></B>


</PRE>
<H2><A NAME="NAME">NAME</A></H2><PRE>
     <B>dccd</B> -- Distributed Checksum Clearinghouse Daemon


</PRE>
<H2><A NAME="SYNOPSIS">SYNOPSIS</A></H2><PRE>
     <B>dccd</B> [<B>-64dVbfFQ</B>] <B>-i</B> <I>server-ID</I> [<B>-n</B> <I>brand</I>] [<B>-h</B> <I>homedir</I>] <B>-I</B> [<I>host-ID</I>][<I>,user</I>]
          [<B>-a</B> [<I>server-addr</I>][<I>,server-port</I>]] [<B>-q</B> <I>qsize</I>]
          [<B>-G</B> [<I>on,</I>][<I>weak-body,</I>][<I>weak-IP,</I>][<I>embargo</I>][<I>,window</I>][<I>,white</I>]]
          [<B>-W</B> [<I>rate</I>][<I>,chg</I>][<I>,dbsize</I>]] [<B>-K</B> [<I>no-</I>]<I>type</I>] [<B>-T</B> <I>tracemode</I>]
          [<B>-u</B> <I>anon-delay</I>[<I>*inflate</I>]] [<B>-C</B> <I>dbclean</I>] [<B>-L</B> <I>ltype,facility.level</I>]
          [<B>-R</B> [<I>RL</I><B>_</B><I>SUB</I>],[<I>RL</I><B>_</B><I>ANON</I>],[<I>RL</I><B>_</B><I>ALL</I><B>_</B><I>ANON</I>],[<I>RL</I><B>_</B><I>BUGS</I>]]


</PRE>
<H2><A NAME="DESCRIPTION">DESCRIPTION</A></H2><PRE>
     <B>Dccd</B> receives reports of checksums related to mail received by DCC
     clients and queries about the total number of reports of particular
     checksums.  A DCC server never receives mail, address, headers, or other
     information from clients, but only cryptographically secure checksums of
     such information.  A DCC server cannot determine the text or other infor-
     mation that corresponds to the checksums it receives.  It only acts as a
     clearinghouse of total counts of checksums computed by clients.

     Each DCC server or close cluster of DCC servers is identified by a
     numeric <I>server-ID</I>.  Each DCC client is identified by a <I>client-ID</I>, either
     explicitly listed in the <I>ids</I> file or the special anonymous client-ID.
     Many computers are expected to share a single <I>client-ID</I>.  A <I>server-ID</I> is
     less than 32768 while a <I>client-ID</I> is between 32768 and 16777215.  DCC
     server-IDs need be known only to DCC servers and the people running them.
     The passwords associated with DCC server-IDs should be protected, because
     DCC servers listen to commands authenticated with server-IDs and their
     associated passwords.  Each client that does not use the anonymous ID
     must know the client-ID and password used by each of its servers.  A sin-
     gle client computer can use different passwords with different server
     computers.  See the <I>ids</I> file.

     A whitelist of known good (or bad) sources of email prevents legitimate
     mailing lists from being seen as unsolicited bulk email by DCC clients.
     The whitelist used by a DCC server is built into the database when old
     entries are removed by <B><A HREF="dbclean.html">dbclean(8)</A></B>.  Each DCC client has its own, local
     whitelist, and in general, whitelists work better in DCC clients than
     servers.

     The effectiveness of a Distributed Checksum Clearinghouse increases as
     the number of subscribers increases.  Flooding reports of checksums among
     DCC servers increases the effective number of subscribers to each server.
     Each <B>dccd</B> daemon tries to maintain TCP/IP connections to the other
     servers listed in the <I>flod</I> file, and send them reports containing check-
     sums with total counts exceeding thresholds.  Changes in the <I>flod</I> file
     are noticed automatically within minutes.

     Controls on report flooding are specified in the <I>flod</I> file.  Each line
     specifies a hostname and port number to which reports should be flooded,
     a server-ID to identify and authenticate the output stream, a server-ID
     to identify and authenticate an input stream from the same server, and
     flags with each ID.  The ability to delete reports of checksums is handy,
     but could be abused.  If <I>del</I> is not present among the <I>in-opts</I> options for
     the incoming ID, incoming delete requests are logged and then ignored.
     Floods from DCC "brands" that count only mail to spam traps and whose
     servers use the <B>-Q</B> option to count extremely bulk mail should be marked
     with <I>traps</I>.  They can be seen as counting millions of targets, so the
     <I>traps</I> flag on their <I>flod</I> file entry changes their incoming flooded
     reports counts to <I>many.</I>

     <B>Dccd</B> automatically checks its <I>flod</I> and <I>ids</I> files periodically.  <B><A HREF="cdcc.html">Cdcc(8)</A></B>
     has the commands <B>new ids</B> and <B>flood check</B> to tell <B>dccd</B> to check those two
     files immediately.  Both files are also checked for changes after the
     SIGHUP signal.

   <A NAME="OPTIONS"><B>OPTIONS</B></A>
     The following options are available:

     <A NAME="OPTION-6"><B>-6</B></A>   enable IPv6.  The default is equivalent to <B>-4</B>.  See also the IPv4
          and IPv6 options in the <I>flod</I> file description below and the <I>IPv6</I> <I>on</I>
          <B><A HREF="cdcc.html">cdcc(8)</A></B> command.

     <A NAME="OPTION-4"><B>-4</B></A>   disable IPv6.  See also <B>-6</B>.

     <A NAME="OPTION-d"><B>-d</B></A>   enables debugging output.  Additional <B>-d</B> options increase the number
          of messages.

     <A NAME="OPTION-V"><B>-V</B></A>   displays the version of the DCC server daemon.

     <A NAME="OPTION-b"><B>-b</B></A>   causes the server to not detach itself from the controlling tty or
          put itself into the background.

     <A NAME="OPTION-F"><B>-F</B></A>   uses write() instead of mmap() in some cases to modify the DCC data-
          base.  It is the default on Solaris.

     <A NAME="OPTION-f"><B>-f</B></A>   turns off <B>-F</B>.

     <A NAME="OPTION-Q"><B>-Q</B></A>   causes the server to treat reports of checksums as queries except
          from DCC clients marked trusted in the <I>ids</I> file with <I>rpt-ok</I>.  See <B>-u</B>
          to turn off access by anonymous or unauthenticated clients

     <A NAME="OPTION-i"><B>-i</B></A> <I>server-ID</I>
          specifies the ID of this DCC server.  Each server identifies itself
          as responsible for checksums that it forwards to other servers.

     <A NAME="OPTION-n"><B>-n</B></A> <I>brand</I>
          is an arbitrary string of letters and numbers that identifies the
          organization running the DCC server.  The brand is required, and
          appears in the SMTP <I>X-DCC</I> headers generated by the DCC.

     <A NAME="OPTION-h"><B>-h</B></A> <I>homedir</I>
          overrides the default DCC home directory, <I>@prefix@</I>.

     <A NAME="OPTION-I"><B>-I</B></A> [<I>host-ID</I>][<I>,user</I>]
          changes the server's globally unique identity for flooding from the
          default value consisting of the first 16 characters of the host
          name.  or changes the UID and GID of the process <I>Host-ID</I> is a string
          of up to 16 characters that replaces the first 16 characters of the
          system's hostname in assertions of the server-ID that are flooded to
          peers.  <I>User</I> must be valid user name.

     <A NAME="OPTION-a"><B>-a</B></A> [<I>server-addr</I>][<I>,server-port</I>]
          adds an hostname or IP address to the list of local IP addresses
          that the server answers.  Multiple <B>-a</B> options can be used to specify
          a subset of the available network interfaces or to use more than one
          port number.  The default without any <B>-a</B> options is to listen on all
          local IP addresses.  It can be useful to list some of the IP
          addresses of multi-homed hosts to deal with firewalls.  By default
          <I>server-port</I> is 6277 for DCC servers and 6276 for Greylist servers.
          It is the UDP port at which DCC requests are received and the TCP
          port for incoming floods of reports.

          If <I>server-addr</I> is absent and if the <B>getifaddrs(8)</B> function is sup-
          ported, separate UDP sockets are bound to each configured network
          interface so that each DCC clients receives replies from the IP
          addresses to which corresponding request are sent.  If <B>dccd</B> is
          started before all network interfaces are turned on or there are
          interfaces that are turned on and off or change their addresses such
          as PPP interfaces, then the special string <I>@</I> should be used to tell
          <B>dccd</B> to bind to an IN_ADDRANY UDP socket.

          Outgoing TCP connections to flood checksum reports to other DCC
          servers used the IP address of a single <B>-a</B> option, but only if there
          is single option that is not localhost.  See also the <I>flod</I> file.

     <A NAME="OPTION-q"><B>-q</B></A> <I>qsize</I>
          specifies the maximum size of the queue of requests from anonymous
          or unauthenticated clients.  The default value is the maximum DCC
          RTT in seconds times 200 or 1000.

     <A NAME="OPTION-G"><B>-G</B></A> [<I>on,</I>][<I>weak-body,</I>][<I>weak-IP,</I>][<I>embargo</I>][<I>,window</I>][<I>,white</I>]
          changes <B>dccd</B> to a Greylist server for <B><A HREF="dccm.html">dccm(8)</A></B> or <B><A HREF="dccifd.html">dccifd(8)</A></B>.
          Greylisting consists of temporarily rejecting or embargoing mail
          from unfamiliar combinations of SMTP client IP address, SMTP enve-
          lope sender, and SMTP envelope recipient.  If the SMTP client per-
          sists for <I>embargo</I> <I>seconds</I> and so is probably not an open proxy,
          worm-infected personal computer, or other transient source of spam,
          the triple of <I>(IP</I> <I>address,sender,recipient)</I> is added to a database
          similar to the usual DCC database.  If the SMTP client does not try
          again after <I>embargo</I> seconds and before <I>window</I> seconds after the
          first attempt, the triple is forgotten.  If the SMTP client persists
          past the embargo, the triple is added to the database and becomes
          familiar and the message is accepted.  Familiar triples are remem-
          bered for <I>white</I> seconds after the last accepted mail message.  The
          triple is forgotten if it is ever associated with unsolicited bulk
          email.

          All three durations can be a number of minutes, hours, days, or
          weeks followed by <I>MINUTES</I>, <I>M</I>, <I>HOURS</I>, <I>H</I>, <I>DAYS</I>, <I>D</I>, <I>WEEKS</I> or <I>W</I>.  The
          default is <B>-G</B> <I>270seconds,7days,63days</I>.  The first duration or the
          <I>embargo</I> should be longer than open proxies can linger retransmit-
          ting.  The second <I>window</I> time should be as long as legitimate mail
          servers persist in retransmitting to recognize embargoed messages
          whose retransmissions were not received because of network or other
          problems.  The <I>white</I> time should be long enough to recognize and not
          embargo messages from regular senders.

          Usually the DCC greylist system requires that an almost identical
          copy of the message be retransmitted during the <I>embargo</I>.  If
          <I>weak-body</I> is present, any message with the same triple of sender IP
          address, sender mail address, and target mail address ends the
          embargo, even if the body of the message differs.

          If <I>weak-IP</I> is present, all mail from an SMTP client at an IP address
          is accept after any message from the same IP address has been
          accepted.

          Unlike DCC checksums, the contents of greylist databases are private
          and do not benefit from broad sharing.  However, large installations
          can use more two or more greylist servers flooding triples among
          themselves.  Flooding among greylist servers is controlled by the
          <I>grey</I><B>_</B><I>flod</I> file.

          All greylist cooperating or flooding greylist servers <I>must</I> use the
          same <B>-G</B> values.

          Clients of greylist servers cannot be anonymous and must have
          client-IDs and passwords assigned in the <I>ids</I> file.  This implies
          that cdcc commands directed to greylist servers must specify the
          server-ID.

          White- and blacklists are honored by the DCC clients.  whitelisted
          messages are embargoed or checked with a greylist server.  The
          greylist triples of blacklisted messages, messages whose DCC counts
          make them spam, and other messages known to be spam are sent to a
          greylist server to be removed from the greylist database and cause
          an embargo on the next messages with those triples.

          Messages whose checksums match greylist server whitelists are not
          embargoed and the checksums of their triples are not added to the
          greylist database.

          The target counts of embargoed messages are reported to the DCC net-
          work to improve the detection of bulk mail.

     <A NAME="OPTION-W"><B>-W</B></A> [<I>rate</I>][<I>,chg</I>][<I>,dbsize</I>]
          controls quick database cleaning.  If the database is larger than
          <I>dbsize</I>, it seems that the database has not recently and is not about
          to be cleaned, <B>dccd</B> is receiving fewer than <I>rate</I> requests per sec-
          ond, and if telling DCC clients that the database is about to be
          cleaned reduces that rate by <I>chg</I>%, then <B>dccd</B> starts <B><A HREF="dbclean.html">dbclean(8)</A></B> for a
          quick database cleaning.  The cleaning is abandoned if it takes too
          long.  The default values are equivalent to <B>-W</B> <I>1.0,40.0,RSS</I> where
          <I>RSS</I> is the maximum dccd resident set displayed the system log by <B>-d</B>
          when <B>starts</B>.

     <A NAME="OPTION-K"><B>-K</B></A> [<I>no-</I>]<I>type</I>
          marks checksums of <I>type</I> (not) be kept or counted in the database
          unless they appear in the whitelist.  Explicit settings add to or
          remove from the initial contents of the list, which is equivalent to
          <B>-K</B> <I>Body</I> <B>-K</B> <I>Fuz1</I> <B>-K</B> <I>Fuz2</I>.

     <A NAME="OPTION-T"><B>-T</B></A> <I>tracemode</I>
          causes the server to trace or record some operations.  <I>tracemode</I>
          must be one of the following:
            <I>ADMN</I>    administrative requests from the control program, <B><A HREF="cdcc.html">cdcc(8)</A></B>
            <I>ANON</I>    errors by anonymous clients
            <I>CLNT</I>    errors by authenticated clients
            <I>RLIM</I>    rate-limited messages
            <I>QUERY</I>   all queries and reports
            <I>RIDC</I>    some messages concerning the report-ID cache that is used
                    to detect duplicate reports from clients
            <I>FLOOD</I>   messages about inter-server flooding connections
            <I>FLOOD2</I>  messages about flooded reports
            <I>IDS</I>     unknown server-IDs in flooded reports
            <I>BL</I>      requests from clients in the <I>blacklist</I> file.
            <I>DB</I>      odd database events including long chains of duplicate
                    checksums
            <I>WLIST</I>   reports of whitelisted checksums from authenticated, not
                    anonymous DCC clients
          The default is <I>ANON</I> <I>CLNT</I>.

     <A NAME="OPTION-u"><B>-u</B></A> <I>anon-delay</I>[<I>*inflate</I>]
          changes the number of milliseconds anonymous or unauthenticated
          clients must wait for answers to their queries and reports.  The
          purpose of this delay is to discourage large anonymous clients.  The
          <I>anon-delay</I> is multiplied by 1 plus the number of recent anonymous
          requests from an IP address divided by the <I>inflate</I> value.

          The string <I>FOREVER</I> turns off all anonymous or unauthenticated access
          not only for checksum queries and reports but also <B><A HREF="cdcc.html">cdcc(8)</A> stats</B>
          requests.  A missing value for <I>inflate</I> turns off inflation.

          The default value is <I>50,none</I>, except when <B>-G</B> is used in which case
          <I>FOREVER</I> is assumed and required.

     <A NAME="OPTION-C"><B>-C</B></A> <I>dbclean</I>
          changes the default name or path of the program used to rebuild the
          hash table when it becomes too full.  The default value is
          <I>@libexecdir@/dbclean</I> in the <I>@libexecdir@</I> directory.  The
          value can include arguments as in <I>-C</I> <I>'$DCC</I><B>_</B><I>LIBEXEC/dbclean</I> <I>-F'</I>.

           Dbclean <I>should</I> <I>not</I> be run by <B>dccd</B> except in emergencies such as
          database corruption or hash table overflow.  <B><A HREF="dbclean.html">Dbclean(8)</A></B> should be
          run daily with the @libexecdir@/cron-dccd cron script

     <A NAME="OPTION-L"><B>-L</B></A> <I>ltype,facility.level</I>
          specifies how messages should be logged.  <I>Ltype</I> must be <I>error</I>, <I>info</I>,
          or <I>off</I> to indicate which of the two types of messages are being con-
          trolled or to turn off all <B>syslog(3)</B> messages from <B>dccd</B>.  <I>Level</I> must
          be a <B>syslog(3)</B> level among <I>EMERG</I>, <I>ALERT</I>, <I>CRIT</I>, <I>ERR</I>, <I>WARNING</I>, <I>NOTICE</I>,
          <I>INFO</I>, and <I>DEBUG</I>.  <I>Facility</I> must be among <I>AUTH</I>, <I>AUTHPRIV</I>, <I>CRON</I>,
          <I>DAEMON</I>, <I>FTP</I>, <I>KERN</I>, <I>LPR</I>, <I>MAIL</I>, <I>NEWS</I>, <I>USER</I>, <I>UUCP</I>, and <I>LOCAL0</I> through
          <I>LOCAL7</I>.  The default is equivalent to
                <B>-L</B> <I>info,MAIL.NOTICE</I> <B>-L</B> <I>error,MAIL.ERR</I>

     <A NAME="OPTION-R"><B>-R</B></A> [<I>RL</I><B>_</B><I>SUB</I>],[<I>RL</I><B>_</B><I>ANON</I>],[<I>RL</I><B>_</B><I>ALL</I><B>_</B><I>ANON</I>],[<I>RL</I><B>_</B><I>BUGS</I>]
          sets one or more of the four rate-limits.  <I>RL</I><B>_</B><I>SUB</I> limits the number
          of DCC transactions per second from subscribers or DCC clients with
          known client-IDs and passwords.  This limit applies to each IP
          address independently.

          <I>RL</I><B>_</B><I>ANON</I> limits the number of DCC transactions per second from anony-
          mous DCC clients.  This limit applies to each IP address indepen-
          dently.  It is better to use <B>-u</B> than to change this value to exclude
          anonymous clients.

          <I>RL</I><B>_</B><I>ALL</I><B>_</B><I>ANON</I> limits the number of DCC transactions per second from
          all anonymous DCC clients.  This limit applies to all anonymous
          clients as a group, regardless of their IP addresses.

          <I>RL</I><B>_</B><I>BUGS</I> limits the number of complaints or error messages per second
          for all anonymous DCC clients as a group as well as for each DCC
          client by IP address.

          The default is equivalent to <B>-R</B> <I>400,50,600,0.1</I>


</PRE>
<H2><A NAME="FILES">FILES</A></H2><PRE>
     <A NAME="FILE-@prefix@">@prefix@</A>  is the DCC home directory containing data and control files.
     <A NAME="FILE-dcc_db">dcc_db</A>    is the database of mail checksums.
     <A NAME="FILE-dcc_db.hash">dcc_db.hash</A> is the mail checksum database hash table.
     <A NAME="FILE-grey_db">grey_db</A>   is the database of greylist checksums.
     <A NAME="FILE-grey_db.hash">grey_db.hash</A> is the greylist database hash table.
     <A NAME="FILE-flod">flod</A>      contains lines controlling DCC flooding of the form:
               <I>host</I>[<I>,rport</I>][<I>;src</I>[<I>,lport</I>]] <I>rem-ID</I> [<I>passwd-ID</I> [<I>o-opt</I> [<I>i-opt</I>]]]
               where absent optional values are signaled with "-" and
                <I>host</I> is the IP address or name of a DCC server and <I>rport</I> is
                    the name or number of the TCP port used by the remote
                    server.
                <I>src</I> and <I>lport</I> are the IP address or host name and TCP port
                    from which the outgoing flooding connection should come.
                    Incoming flooding connections must arrive at an address
                    and port specified with <B>-a</B>.
                <I>rem-id</I> is the server-ID of the remote DCC server.
                <I>passwd-ID</I> is a server-ID that is not assigned to a server, but
                    whose first password is used to sign checksum reports sent
                    to the remote system.  Either of its passwords are
                    required with incoming reports.  If it is absent or "-",
                    outgoing floods are signed with the first password of the
                    local server in the <I>ids</I> file and incoming floods must be
                    signed with either password of the remote server-ID.
                <I>i-opt</I> and <I>o-opt</I> are comma separated lists of
                     <I>off</I> turns off flooding to the remote or local system.
                     <I>traps</I> indicates that the remote sending or local receiv-
                         ing system has only spam traps.
                     <I>no-del</I> says checksum delete requests are refused by the
                         remote or local server and so turns off sending or
                         accepting delete requests, respectively.  By default,
                         delete requests are sent to remote servers and
                         accepted in incoming floods if and only if the peers
                         are exchanging DCC reputations.
                     <I>del</I> says delete requests are accepted by the remote or
                         local server.
                     <I>no-log-del</I> turns off logging of incoming requests to
                         delete checksums.
                     <I>passive</I> is used to tell a server outside a firewall to
                         expect a peer inside to create both of the pair of
                         input and output TCP connections used for flooding.
                         The peer inside the firewall should use <I>SOCKS</I> or <I>NAT</I>
                         on its <I>flod</I> file entry for this system.
                     <I>SOCKS</I> is used to tell a server inside a firewall that it
                         should create both of the TCP connections used for
                         flooding and that SOCKS protocol should be used.  The
                         peer outside the firewall should use <I>passive</I> on its
                         <I>flod</I> file entry for this system.
                     <I>NAT</I> differs from <I>SOCKS</I> only by not using the SOCKS proto-
                         col.
                     <I>ID1-&gt;ID2</I> converts server-ID <I>ID1</I> in flooded reports to
                         server-ID <I>ID2</I>.  Either <I>ID1</I> or <I>ID2</I> may be the string
                         `self' to specify the server's own ID.  <I>ID1</I> can be
                         the string `all' to specify all server-IDs or a pair
                         of server-IDs separated by a dash to specify an
                         inclusive range.  <I>ID2</I> can be the string `ok' to send
                         or receive reports without translation or the string
                         `reject' to not send outgoing or refuse incoming
                         reports.  Only the first matching conversion is
                         applied.  For example, when `self-&gt;ok,all-&gt;reject' is
                         applied to a locally generated report, the first con-
                         version is applied and the second is ignored.
                     <I>leaf=path-len</I> does not send reports with paths longer
                         than <I>path-len</I> server-IDs.
                     <I>IPv4</I> overrides a <B>-6</B> setting for this flooding peer.
                     <I>IPv6</I> overrides the default or an explicit <B>-4</B> setting.
                     <I>vers</I> specifies the version of the DCC flooding protocol
                         used by the remote DCC server with a string such as
                         `version2'.
                     <I>trace</I> sends information about a single peer like the
                         <B><A HREF="cdcc.html">cdcc(8)</A></B> command <B>trace FLOOD on</B> does for all peers.
                     <I>trace2</I> sends information about individual flooded reports
                         like the <B><A HREF="cdcc.html">cdcc(8)</A></B> command <B>trace FLOOD2 on</B> does for all
                         peers.
     <A NAME="FILE-grey_flod">grey_flod</A> is the equivalent of <I>flod</I> used by <B>dccd</B> when it is a greylist
               server.
     <A NAME="FILE-flod.map">flod.map</A>  is an automatically generated file in which <B>dccd</B> records its
               progress sending or flooding reports to DCC peers.
     <A NAME="FILE-grey_flod.map">grey_flod.map</A> is the equivalent of <I>flod.map</I> <I>used</I> <I>by</I> <B>dccd</B> when it is a
               greylist server.
     <A NAME="FILE-ids">ids</A>       contains the IDs and passwords known by the DCC server.  An <I>ids</I>
               file that can be read by others cannot be used.  It contains
               blank lines, comments starting with "#" and lines of the form:
                     <I>id</I>[<I>,rpt-ok</I>][<I>,delay=ms</I>[<I>*inflate</I>]] <I>passwd1</I> [<I>passwd2</I>]
               where
                <I>id</I>  is a DCC <I>client-ID</I> or <I>server-ID</I>.
                <I>Rpt-ok</I> if present overrides <B>-Q</B> by saying that this client is
                    trusted to report only checksums for unsolicited bulk
                    mail.
                <I>delay=ms</I>[<I>*inflate</I>] delays answers to systems using the client
                    <I>id</I>.  The <I>delay</I> in milliseconds is multiplied by 1 plus the
                    number of recent requests from an IP address using <I>id</I>
                    divided by the <I>inflate</I> value.  See <B>-u</B>.
                <I>passwd1</I> is the password currently used by clients with identi-
                    fier <I>id</I>.  It is a 1 to 32 character string that does not
                    contain blank, tab, newline or carriage return characters.

                <I>passwd2</I> is the optional next password that those clients will
                    use.  A DCC server accepts either password if both are
                    present in the file.
               Both passwords can be absent if the entry not used except to
               tell <B>dccd</B> that server-IDs in the flooded reports are valid.
               The string <I>unknown</I> is equivalent to the null string.
     <A NAME="FILE-whitelist">whitelist</A> contains the DCC server whitelist.  It is not used directly but
               is loaded into the database when <B><A HREF="dbclean.html">dbclean(8)</A></B> is run.
     <A NAME="FILE-grey_whitelist">grey_whitelist</A> contains the greylist server whitelist.  It is not used
               directly but is loaded into the database when <B><A HREF="dbclean.html">dbclean(8)</A></B> is run
               with <B>-G</B>.
     <A NAME="FILE-blacklist">blacklist</A> if present, contains a list of IP addresses and blocks of IP
               addresses DCC clients that are ignored.  Each line in the file
               should be blank, a comment starting with '#', or an IP address
               or block of IP addresses in the form
                     [<I>trace,</I>] [<I>ok,</I>] [<I>bad</I>] xxx.xxx.xxx.xxx[/yy]
               Changes to the file are automatically noticed and acted upon
               within a few minutes.  Addresses or blocks of addresses can be
               preceded with <I>ok</I> to "punch holes" in blacklisted blocks or with
               <I>trace</I> to log activity.  This mechanism is intended for no more
               than a few dozen blocks of addresses.
     <A NAME="FILE-dccd_clients">dccd_clients</A> contains client IP addresses and activity counts.
     <A NAME="FILE-grey_clients">grey_clients</A> contains greylist client IP addresses and activity counts.


</PRE>
<H2><A NAME="EXAMPLES">EXAMPLES</A></H2><PRE>
     <B>dccd</B> is usually started with other system daemons with something like the
     script <I>@libexecdir@/rcDCC</I>.  That scripts uses values in
     @prefix@/dcc_conf to start the server.  With the argument <I>stop</I>,
     <I>@libexecdir@/rcDCC</I> can be used to stop the daemon.

     The database grows too large unless old reports are removed.  <B><A HREF="dbclean.html">dbclean(8)</A></B>
     should be run daily with the @libexecdir@/cron-dccd cron script


</PRE>
<H2><A NAME="SEE-ALSO">SEE ALSO</A></H2><PRE>
     <B><A HREF="cdcc.html">cdcc(8)</A></B>, <B><A HREF="dcc.html">dcc(8)</A></B>, <B><A HREF="dbclean.html">dbclean(8)</A></B>, <B><A HREF="dblist.html">dblist(8)</A></B>, <B><A HREF="dccifd.html">dccifd(8)</A></B>, <B><A HREF="dccm.html">dccm(8)</A></B>, <B><A HREF="dccproc.html">dccproc(8)</A></B>.
     <B><A HREF="dccsight.html">dccsight(8)</A></B>,


</PRE>
<H2><A NAME="HISTORY">HISTORY</A></H2><PRE>
     <B>dccd</B> is based on an idea from Paul Vixie.  It was designed and written at
     Rhyolite Software, starting in 2000.  This document describes version
     1.3.103.

                               February 26, 2009
</PRE>
<HR>
<ADDRESS>
Man(1) output converted with
<a href="http://www.oac.uci.edu/indiv/ehood/man2html.html">man2html</a>
modified for the DCC $Date 2001/04/29 03:22:18 $
<BR>
<A HREF="http://www.dcc-servers.net/dcc/">
    <IMG SRC="http://logos.dcc-servers.net/border.png"
            class=logo ALT="DCC logo">
    </A>
<A HREF="http://validator.w3.org/check?uri=referer">
    <IMG class=logo ALT="Valid HTML 4.01 Strict"
        SRC="http://www.w3.org/Icons/valid-html401">
    </A>
</ADDRESS>
</BODY>
</HTML>