    DCC(8)                  FreeBSD System Manager's Manual                 DCC(8)

## NAME

         DCC -- Distributed Checksum Clearinghouse

## DESCRIPTION

         The Distributed Checksum Clearinghouse or DCC is a cooperative, distrib-
         uted system intended to detect "bulk" mail or mail sent to many people.
         It allows individuals receiving a single mail message to determine that
         many other people have received essentially identical copies of the mes-
         sage and so reject or discard the message.

         Source is available at https://www.dcc-servers.net/dcc/ free for organi-
         zations that do not sell spam or virus filtering services.

       How the DCC Is Used
         The DCC can be viewed as a tool for end users to enforce their right to
         "opt-in" to streams of bulk mail by refusing bulk mail except from
         sources in a "whitelist."  Whitelists are the responsibility of DCC
         clients, since only they know which bulk mail they solicited.

         False positives or mail marked as bulk by a DCC server that is not bulk
         occur only when a recipient of a message reports it to a DCC server as
         having been received many times or when the "fuzzy" checksums of differ-
         ing messages are the same.  The fuzzy checksums ignore aspects of mes-
         sages in order to compute identical checksums for substantially identical
         messages.  The fuzzy checksums are designed to ignore only differences
         that do not affect meanings.  So in practice, you do not need to worry
         about DCC false positive indications of "bulk," but not all bulk mail is
         unsolicited bulk mail or spam.  You must either use whitelists to distin-
         guish solicited from unsolicited bulk mail or only use DCC indications of
         "bulk" as part of a scoring system such as SpamAssassin.  Besides unso-
         licited bulk email or spam, bulk messages include legitimate mail such as
         order confirmations from merchants, legitimate mailing lists, and empty
         or test messages.

         A DCC server estimates the number copies of a message by counting check-
         sums reported by DCC clients.  Each client must decide which bulk mes-
         sages are unsolicited and what degree of "bulkiness" is objectionable.
         Client DCC software marks, rejects, or discards mail that is bulk accord-
         ing to local thresholds on target addresses from DCC servers and unso-
         licited according to local whitelists.

         DCC servers are usually configured to receive reports from as many tar-
         gets as possible, including sources that cannot be trusted to not exag-
         gerate the number of copies of a message they see.  A user of a DCC
         client angry about receiving a message could report it with 1,000,000
         separate DCC reports or with a single report claiming 1,000,000 targets.
         An unprincipled user could subscribe a "spam trap" to mailing lists such
         as those of the IETF or CERT.  Such abuses of the system area not prob-
         lems, because much legitimate mail is "bulk."  You cannot reject bulk
         mail unless you have a whitelist of sources of legitimate bulk mail.

         DCC can also be used by an Internet service provider to detect bulk mail
         coming from its own customers.  In such circumstances, the DCC client
         might be configured to only log bulk mail from unexpected (not
         whitelisted) customers.

       What the DCC Is
         A DCC server accumulates counts of cryptographic checksums of messages
         but not the messages themselves.  It exchanges reports of frequently seen
         checksums with other servers.  DCC clients send reports of checksums re-
         lated to incoming mail to a nearby DCC server running dccd(8).  Each re-
         port from a client includes the number of recipients for the message.  A
         DCC server accumulates the reports and responds to clients the the cur-
         rent total number of recipients for each checksum.  The client adds an
         SMTP header to incoming mail containing the total counts.  It then dis-
         cards or rejects mail that is not whitelisted and has counts that exceed
         local thresholds.

         A special value of the number of addressees is "MANY" and means this mes-
         sage was certainly bulk and might be unsolicited, perhaps because it came
         from a locally blacklisted source or was addressed to an invalid address
         or "spam trap."  The special value "MANY" is merely the largest value
         that fits in the database field containing the count of addressees.  That
         "infinite" accumulated total can be reached with millions of independent
         reports as well as with one or two.

         DCC servers flood or send reports of checksums of bulk mail to neighbor-
         ing servers.

         To keep a server's database of checksums from growing without bound,
         checksums are forgotten when they become old.  Checksums of bulk mail are
         kept longer.  See dbclean(8).

         DCC clients pick the nearest working DCC server using a small shared or
         memory mapped file, /var/dcc/map.  It contains server names, port num-
         bers, passwords, recent performance measures, and so forth.  This file
         allows clients to use quick retransmission timeouts and to waste little
         time on servers that have temporarily stopped working or become unreach-
         able.  The utility program cdcc(8) is used to maintain this file as well
         as to check the health of servers.

       X-DCC Headers
         The DCC software includes several programs used by clients.  Dccm(8) uses
         the sendmail "milter" interface to query a DCC server, add header lines
         to incoming mail, and reject mail whose total checksum counts are high.
         Dccm is intended to be run with SMTP servers using sendmail.

         Dccproc(8) adds header lines to mail presented by file name or stdin, but
         relies on other programs such as procmail to deal with mail with large
         counts.  Dccsight(8) is similar but deals with previously computed check-
         sums.

         Dccifd(8) is similar to dccproc but is not run separately for each mail
         message and is more efficient.  It receives mail messages via a socket
         somewhat like dccm, but with a simpler protocol that can be used by Perl
         scripts or other programs.  Dccifd can also be used as a postfix "Before-
         Queue Content Filter."

         DCC SMTP header lines are of one of the forms:

           X-DCC-brand-Metrics: client server-ID; bulk cknm1=count cknm2=count ...
           X-DCC-brand-Metrics: client; whitelist
         where
            whitelist appears if the global /var/dcc/whiteclnt or per-user file
                    marks the message as good.
            brand   is the "brand name" of the DCC server, such as "RHYOLITE".
            client  is the name or IP address of the DCC client that added the
                    header line to the SMTP message.
            server-ID is the numeric ID of the DCC server that the DCC client con-
                    tacted.
            bulk    is present if one or more checksum counts exceeded the DCC
                    client's thresholds to make the message "bulky."
            bulk rep is present if the DCC reputation of the IP address of the
                    sender is bad.
            cknm1,cknm2,... are types of checksums:
                      IP           address of SMTP client
                      env_From     SMTP envelope value
                      From         SMTP header line
                      Message-ID   SMTP header line
                      Received     last Received: header line in the SMTP message
                      substitute   SMTP header line chosen by the DCC client, pre-
                                   fixed with the name of the header
                      Body         SMTP body ignoring white-space
                      Fuz1         filtered or "fuzzy" body checksum
                      Fuz2         another filtered or "fuzzy" body checksum
                      rep          DCC reputation of the mail sender or the esti-
                                   mated probability that the message is bulk.
                    Counts for IP, env_From, From, Message-Id, Received, and
                    substitute checksums are omitted by the DCC client if the
                    server says it has no information.  Counts for Fuz1 and Fuz2
                    are omitted if the message body is empty or contains too lit-
                    tle of the right kind of information for the checksum to be
                    computed.
            count   is the total number of recipients of messages with that check-
                    sum reported directly or indirectly to the DCC server.  The
                    special count "MANY" means that DCC client have claimed that
                    the message is directed at millions of recipients.  "MANY" im-
                    ples the message is definitely bulk, but not necessarily unso-
                    licited.  The special counts "OK" and "OK2" mean the checksum
                    has been marked "good" or "half-good" by DCC servers.

       Mailing lists
         Legitimate mailing list traffic differs from spam only in being solicited
         by recipients.  Each client should have a private whitelist.

         DCC whitelists can also mark mail as unsolicited bulk using blacklist en-
         tries for commonly forged values such as "From: user@public.com".

       White and Blacklists
         DCC server and client whitelist files share a common format.  Server
         files are always named whitelist and one is required to be in the DCC
         home directory with the other server files.  Client whitelist files are
         named /var/dcc/whiteclnt in the DCC home directory or a per-user subdi-
         rectory of the directory specified with the -U option for dccm(8) or
         dccifd(8).  They specify mail that should not be reported to a DCC server
         or that is always unsolicited and almost certainly bulk.

         A DCC whitelist file contains blank lines, comments starting with "#",
         and lines of the following forms:
           include file
                 Copies the contents of file into the whitelist.  It cannot occur
                 in an included file.  The file name is relative to the DCC home
                 directory if not absolute.

           count value
                 lines specify checksums that should be white- or blacklisted.
                   count env_From 821-path
                   count env_To dest-mailbox
                   count From 822-mailbox
                   count Message-ID <string>
                   count Received string
                   count Substitute header string
                   count Hex ctype cksum
                   count IP hosts

                   MANY value
                         indicates that millions of targets have received messages
                         with the header, IP address, or checksum value.
                   OK value
                   OK2 value
                         say that messages with the header, IP address, or check-
                         sum value are OK and should not reported to DCC servers
                         or be greylisted.  OK2 says that the message is "half
                         OK."  Two OK2 checksums associated with a message are
                         equivalent to one OK.
                         A DCC server never shares or floods reports containing
                         checksums marked in its whitelist with OK or OK2 to other
                         servers.  A DCC client does not report or ask its server
                         about messages with a checksum marked OK or OK2 in the
                         client whitelist.  This is intended to allow a DCC client
                         to keep private mail so private that even its checksums
                         are not disclosed.
                   MX IP hosts
                   MXDCC IP hosts
                         mark an IP address or block of addresses of trusted mail
                         relays including MX servers, smart hosts, and bastion or
                         DMZ relays.  The DCC clients dccm(8), dccifd(8), and
                         dccproc(8) parse and skip initial Received: headers added
                         by listed MX servers to determine the external sources of
                         mail messages.  Unsolicited bulk mail that has been for-
                         warded through listed addresses is discarded by dccm(8)
                         and dccifd(8) as if with -a DISCARD instead of rejected.
                         MXDCC marks addresses that are MX servers that run DCC
                         clients.  The checksums for a mail message that has been
                         forwarded through an address listed as MXDCC are queried
                         instead of reported by a DCC client.
                         dccd(8) treats MXDCC and MX lines in the
                         /var/dcc/whitelist file as if they were OK lines.
                   SUBMIT IP hosts
                         marks an IP address or block of addresses of SMTP submis-
                         sion clients such as web browsers that cannot tolerate
                         4yz temporary rejections but that cannot be trusted to
                         not send spam.  Since they are local addresses, DCC Repu-
                         tations are not computed for them.
                         dccd(8) ignores SUBMIT lines in the /var/dcc/whitelist
                         file.

                 value in count value lines can be
                   dest-mailbox
                         is an RFC 821 address or a local user name.
                   821-path
                         is an RFC 821 address.
                   822-mailbox
                         is an RFC 822 address with optional name.
                   Substitute header
                         is the name of an SMTP header such as "Sender" or the
                         name of one of two SMTP envlope values, "HELO," or
                         "Mail_Host" for the resolved host name from the 821-path
                         in the message.
                   Hex ctype cksum
                         starts with the string Hex followed a checksum type, and
                         a string of four hexadecimal numbers obtained from a DCC
                         log file or the dccproc(8) command using -CQ.  The check-
                         sum type is body, Fuz1, or Fuz2 or one of the preceding
                         checksum types such as env_From.
                   hosts
                         is a host name, an IPv4 or IPv6 address, a block of IP
                         addresses specified as starting and ending addresses sep-
                         arated by a dash (-), or a block in the standard xxx/mm
                         form.  A host name is converted to IP addresses with DNS,
                         the /etc/hosts file, or other mechanisms.
                         The /var/dcc/whitelist file used by the DCC server.
                         dccd(8), treats all host names, IP addresses, and address
                         blocks the same.  Each IP address must be added to the
                         DCC database as its checksum.  DCC servers only hear
                         about checksums and so could not use a list of IP ad-
                         dresses.  To prevent accidentally adding billions of
                         records to the database (contemplate a line like "OK IP
                         fe80::0/120), server whitelist entries cannot specify
                         blocks larger than 65,536 or /16.
                         The DCC clients, dccifd(8), dccm(8) or dccproc(8), know
                         about IP addresses and so their whitelists can contain IP
                         addresses.  The global /var/dcc/whiteclnt file or a per-
                         user whiteclnt file can contain up to 64 ranges of 256 or
                         more IP addresses.  Smaller ranges are added as individ-
                         ual entries.

           option setting
                 can only be in a DCC client whiteclnt file used by dccifd(8),
                 dccm(8) or dccproc(8).  Settings in per-user whiteclnt files
                 override settings in the global /var/dcc/whiteclnt file.  Setting
                 can be any of the following:
                   option log-all
                       to log all mail messages.
                   option log-normal
                       to log only messages that meet the logging thresholds.
                   option log-subdirectory-day
                   option log-subdirectory-hour
                   option log-subdirectory-minute
                       puts log files for mail messages in subdirectories of the
                       userdirs/addr/log directory specified with -U userdirs for
                       dccm(8) or dccifd(8).  The subsdirectories are of the form
                       JJJ, JJJ/HH, or JJJ/HH/MM where JJJ is the current julian
                       day, HH is the current hour, and MM is the current minute.
                       See also -l logdir for dccm(8), dccifd(8), and dccproc(8).
                   option DCC-on
                   option DCC-off
                       to control DCC filtering.
                   option greylist-on
                   option greylist-off
                       to control greylisting if enabled in dccm(8) or dccifd(8)
                       with -G.  Greylisting for other recipients in the same SMTP
                       transaction can still cause greylist temporary rejections.
                   option greylist-ignore-spam-on
                   option greylist-ignore-spam-off
                       causes greylisting to ignore the results of other filters.
                       If off, spam is rejected regardless of greylist embargoes
                       and future embargoes for the sending IP address are re-
                       stored or reset.  If this option is on, greylist delays or
                       embargoes are required before spam is rejected and future
                       embargoes on spam sending IP addresses are not reset.
                   option greylist-log-on
                   option greylist-log-off
                       to control per-user logging of greylisted mail messages.
                       Logging of greylisted messages in the main log directory is
                       not affected.
                   option DCC-rep-off
                   option DCC-rep-on
                       to honor or ignore DCC Reputations computed by the DCC
                       server.
                   option DNSBL1-off
                   option DNSBL1-on
                   option DNSBL2-off
                   option DNSBL2-on
                   option DNSBL3-off
                   option DNSBL3-on
                   option DNSBL4-off
                   option DNSBL4-on
                       honor or ignore results of DNS blacklist checks configured
                       with -B for dccm(8), dccifd(8), and dccproc(8).
                   option MTA-first
                   option MTA-last
                       consider MTA determinations of spam or not-spam first so
                       they can be overridden by whiteclnt files, or last so that
                       they can override whiteclnt files.
                   option forced-discard-ok
                   option no-forced-discard
                       control whether dccm(8) and dccifd(8) are allowed to dis-
                       card a message for one mailbox for which it is spam when it
                       is not spam and must be delivered to another mailbox.  This
                       can happen if a mail message is addressed to two or more
                       mailboxes with differing whitelists.  Discarding can be un-
                       desirable because false positives are not communicated to
                       mail senders.  To avoid discarding, dccm(8) and dccifd(8)
                       running in proxy mode temporarily reject SMTP envelope Rcpt
                       To values that involve differing whiteclnt files.
                   option threshold type,rej-thold
                       has the same effects as -c type,rej-thold for dccproc(8) or
                       -t type,rej-thold for dccm(8) and dccifd(8).  It is useful
                       only in per-user whiteclnt files to override the global DCC
                       checksum thresholds.
                   option spam-trap-discard
                   option spam-trap-reject
                       say that mail should be reported to the DCC server as ex-
                       tremely bulk or with target counts of MANY.  Greylisting,
                       DNS blacklist (DNSBL), and other checks are turned off.
                       Spam-trap-discard tells the MTA to accept the message while
                       spam-trap-reject tells the MTA to reject the message.  Use
                       Spam-trap-discard for spam traps that should not be dis-
                       closed.  Spam-trap-reject can be used  on catch-all mail-
                       boxes that might receive legitimate mail by typographical
                       errors and that senders should be told about.
                   option not-spam-trap
                       turns off spam-trap-discard and spam-trap-reject.

                 In the absence of explicit settings, the default in the main
                 whiteclnt file is equivalent to
                     option log-normal
                     option DCC-on
                     option greylist-on
                     option greylist-ignore-spam-off
                     option greylist-log-on
                     option DCC-rep-off
                     option DNSBL1-off
                     option DNSBL2-off
                     option DNSBL3-off
                     option DNSBL4-off
                     option MTA-last
                     option no-forced-discard
                 The defaults for individual recipient whiteclnt files are the
                 same except as change by explicit settings in the main file.

         Checksums of the IP address of the SMTP client sending a mail message are
         practically unforgeable, because it is impractical for an SMTP client to
         "spoof" its address or pretend to use some other IP address.  That would
         make the IP address of the sender useful for whitelisting, except that
         the IP address of the SMTP client is often not available to users of
         dccproc(8).  In addition, legitimate mail relays make whitelist entries
         for IP addresses of little use.  For example, the IP address from which a
         message arrived might be that of a local relay instead of the home ad-
         dress of a whitelisted mailing list.

         Envelope and header From values can be forged, so whitelist entries for
         their checksums are not entirely reliable.

         Checksums of env_To values are never sent to DCC servers.  They are valid
         in only whiteclnt files and used only by dccm(8), dccifd(8), and
         dccproc(8) when the envelope Rcpt To value is known.

       Greylists
         The DCC server, dccd(8), can be used to maintain a greylist database for
         some DCC clients including dccm(8) and dccifd(8).  Greylisting involves
         temporarily refusing mail from unfamiliar SMTP clients and is unrelated
         to filtering with a Distributed Checksum Clearinghouse.
         See http://projects.puremagic.com/greylisting/

       Privacy
         Because sending mail is a less private act than receiving it, and because
         sending bulk mail is usually not private at all and cannot be very pri-
         vate, the DCC tries first to protect the privacy of mail recipients, and
         second the privacy of senders of mail that is not bulk.

         DCC clients necessarily disclose some information about mail they have
         received.  The DCC database contains checksums of mail bodies, header
         lines, and source addresses.  While it contains significantly less infor-
         mation than is available by "snooping" on Internet links, it is important
         that the DCC database be treated as containing sensitive information and
         to not put the most private information in the DCC database.  Given the
         contents of a message, one might determine whether that message has been
         received by a system that subscribes to the DCC.  Guesses about the
         sender and addressee of a message can also be validated if the checksums
         of the message have been sent to a DCC server.

         Because the DCC is distributed, organizations can operate their own DCC
         servers, and configure them to share or "flood" only the checksums of
         bulk mail that is not in local whitelists.

         DCC clients should not report the checksums of messages known to be pri-
         vate to a DCC server.  For example, checksums of messages local to a sys-
         tem or that are otherwise known a priori to not be unsolicited bulk
         should not be sent to a remote DCC server.  This can accomplished by
         adding entries for the sender to the client's local whitelist file.
         Client whitelist files can also include entries for email recipients
         whose mail should not be reported to a DCC server.

       Security
         Whenever considering security, one must first consider the risks.  The
         worst DCC security problems are unauthorized commands to a DCC service,
         denial of the DCC service, and corruption of DCC data.  The worst that
         can be done with remote commands to a DCC server is to turn it off or
         otherwise cause it to stop responding.  The DCC is designed to fail
         gracefully, so that a denial of service attack would at worst allow de-
         livery of mail that would otherwise be rejected.  Corruption of DCC data
         might at worst cause mail that is already somewhat "bulk" by virtue of
         being received by two or more people to appear have higher recipient num-
         bers.  Since DCC users must whitelist all sources of legitimate bulk
         mail, this is also not a concern.  Such security risks should be ad-
         dressed, but only with defenses that don't cost more than the possible
         damage from an attack.

         The DCC must contend with senders of unsolicited bulk mail who resort to
         unlawful actions to express their displeasure at having their advertising
         blocked.  Because the DCC protocol is based on UDP, an unhappy advertiser
         could try to flood a DCC server with packets supposedly from subscribers
         or non-subscribers.  DCC servers defend against that attack by rate-lim-
         iting requests from anonymous users.

         Also because of the use of UDP, clients must be protected against forged
         answers to their queries.  Otherwise an unsolicited bulk mail advertiser
         could send a stream of "not spam" answers to an SMTP client while simul-
         taneously sending mail that would otherwise be rejected.  This is not a
         problem for authenticated clients of the DCC because they share a secret
         with the DCC.  Unauthenticated, anonymous DCC clients do not share any
         secrets with the DCC, except for unique and unpredictable bits in each
         query or report sent to the DCC.  Therefore, DCC servers cryptographi-
         cally sign answers to unauthenticated clients with bits from the corre-
         sponding queries.  This protects against attackers that do not have ac-
         cess to the stream of packets from the DCC client.

         The passwords or shared secrets used in the DCC client and server pro-
         grams are "cleartext" for several reasons.  In any shared secret authen-
         tication system, at least one party must know the secret or keep the se-
         cret in cleartext.  You could encrypt the secrets in a file, but because
         they are used by programs, you would need a cleartext copy of the key to
         decrypt the file somewhere in the system, making such a scheme more ex-
         pensive but no more secure than a file of cleartext passwords.  Asymmet-
         ric systems such as that used in UNIX allow one party to not know the se-
         crets, but they must be and are designed to be computationally expensive
         when used in applications like the DCC that involve thousands or more au-
         thentication checks per second.  Moreover, because of "dictionary at-
         tacks," asymmetric systems are now little more secure than keeping pass-
         words in cleartext.  An adversary can compare the hash values of combina-
         tions of common words with /etc/passwd hash values to look for bad pass-
         words.  Worse, by the nature of a client/server protocol like that used
         in the DCC, clients must have the cleartext password.  Since it is among
         the more numerous and much less secure clients that adversaries would
         seek files of DCC passwords, it would be a waste to complicate the DCC
         server with an asymmetric system.

         The DCC protocol is vulnerable to dictionary attacks to recover pass-
         words.  An adversary could capture some DCC packets, and then check to
         see if any of the 100,000 to 1,000,000 passwords in so called "cracker
         dictionaries" applied to a packet generated the same signature.  This is
         a concern only if DCC passwords are poorly chosen, such as any combina-
         tion of words in an English dictionary.  There are ways to prevent this
         vulnerability regardless of how badly passwords are chosen, but they are
         computationally expensive and require additional network round trips.
         Since DCC passwords are created and typed into files once and do not need
         to be remembered by people, it is cheaper and quite easy to simply choose
         good passwords that are not in dictionaries.

       Reliability
         It is better to fail to filter unsolicited bulk mail than to fail to de-
         liver legitimate mail, so DCC clients fail in the direction of assuming
         that mail is legitimate or even whitelisted.

         A DCC client sends a report or other request and waits for an answer.  If
         no answer arrives within a reasonable time, the client retransmits.
         There are many things that might result in the client not receiving an
         answer, but the most important is packet loss.  If the client's request
         does not reach the server, it is easy and harmless for the client to re-
         transmit.  If the client's request reached the server but the server's
         response was lost, a retransmission to the same server would be misunder-
         stood as a new report of another copy of the same message unless it is
         detected as a retransmission by the server.  The DCC protocol includes
         transactions identifiers for this purpose.  If the client retransmitted
         to a second server, the retransmission would be misunderstood by the sec-
         ond server as a new report of the same message.

         Each request from a client includes a timestamp to aid the client in mea-
         suring the round trip time to the server and to let the client pick the
         closest server.  Clients monitor the speed of all of the servers they
         know including those they are not currently using, and use the quickest.

       Client and Server-IDs
         Servers and clients use numbers or IDs to identify themselves.  ID 1 is
         reserved for anonymous, unauthenticated clients.  All other IDs are asso-
         ciated with a pair of passwords in the ids file, the current and next or
         previous and current passwords.  Clients included their client IDs in
         their messages.  When they are not using the anonymous ID, they sign
         their messages to servers with the first password associated with their
         client-ID.  Servers treat messages with signatures that match neither of
         the passwords for the client-ID in their own ids file as if the client
         had used the anonymous ID.

         Each server has a unique server-ID less than 32768.  Servers use their
         IDs to identify checksums that they flood to other servers.  Each server
         expects local clients sending administrative commands to use the server's
         ID and sign administrative commands with the associated password.

         Server-IDs must be unique among all systems that share reports by "flood-
         ing."  All servers must be told of the IDs all other servers whose re-
         ports can be received in the local /var/dcc/flod file described in
         dccd(8).  However, server-IDs can be mapped during flooding between inde-
         pendent DCC organizations.

         Passwd-IDs are server-IDs that should not be assigned to servers.  They
         appear in the often publicly readable /var/dcc/flod and specify passwords
         in the private /var/dcc/ids file for the inter-server flooding protocol

         The client identified by a client-ID might be a single computer with a
         single IP address, a single but multi-homed computer, or many computers.
         Client-IDs are not used to identify checksum reports, but the organiza-
         tion operating the client.  A client-ID need only be unique among clients
         using a single server.  A single client can use different client-IDs for
         different servers, each client-ID authenticated with a separate password.

         An obscure but important part of all of this is that the inter-server
         flooding algorithm depends on server-IDs and timestamps attached to re-
         ports of checksums.  The inter-server flooding mechanism requires cooper-
         ating DCC servers to maintain reasonable clocks ticking in UTC.  Clients
         include timestamps in their requests, but as long as their timestamps are
         unlikely to be repeated, they need not be very accurate.

       Installation Considerations
         DCC clients on a computer share information about which servers are cur-
         rently working and their speeds in a shared memory segment.  This segment
         also contains server host names, IP addresses, and the passwords needed
         to authenticate known clients to servers.  That generally requires that
         dccm(8), dccproc(8), dccifd(8), and cdcc(8) execute with an UID that can
         write to the DCC home directory and its files.  The sendmail interface,
         dccm, is a daemon that can be started by an "rc" or other script already
         running with the correct UID.  The other two, dccproc and cdcc need to be
         set-UID because they are used by end users.  They relinquish set-UID
         privileges when not needed.

         Files that contain cleartext passwords including the shared file used by
         clients must be readable only by "owner."

         The data files required by a DCC can be in a single "home" directory,
         /var/dcc.  Distinct DCC servers can run on a single computer, provided
         they use distinct UDP port numbers and home directories.  It is possible
         and convenient for the DCC clients using a server on the same computer to
         use the same home directory as the server.

         The DCC source distribution includes sample control files.  They should
         be modified appropriately and then copied to the DCC home directory.
         Files that contain cleartext passwords must not be publicly readable.

         The DCC source includes "feature" m4 files to configure sendmail to use
         dccm(8) to check a DCC server about incoming mail.

         See also the INSTALL.html file.

       Client Installation
         Installing a DCC client starts with obtaining or compiling program bina-
         ries for the client server data control tool, cdcc(8).  Installing the
         sendmail DCC interface, dccm(8), or dccproc(8), the general or
         procmail(1) interface is the main part of the client installation.  Con-
         necting the DCC to sendmail with dccm is most powerful, but requires ad-
         ministrative control of the system running sendmail.

         As noted above, cdcc and dccproc should be set-UID to a suitable UID.
         Root or 0 is thought to be safe for both, because they are careful to re-
         lease privileges except when they need them to read or write files in the
         DCC home directory.  A DCC home directory, /var/dcc should be created.
         It must be owned and writable by the UID to which cdcc is set.

         After the DCC client programs have been obtained, contact the operator(s)
         of the chosen DCC server(s) to obtain each server's host name, port num-
         ber, and a client-ID and corresponding password.  No client-IDs or pass-
         words are needed touse DCC servers that allow anonymous clients.  Use the
         load or add commands of cdcc to create a map file in the DCC home direc-
         tory.  It is usually necessary to create a client whitelist file of the
         format described above.  To accommodate users sharing a computer but not
         ideas about what is solicited bulk mail, the client whitelist file can be
         any valid path name and need not be in the DCC home directory.

         If dccm is chosen, arrange to start it with suitable arguments before
         sendmail is started.  See the homedir/dcc_conf file and the misc/rcDCC
         script in the DCC source.  The procmail DCCM interface, dccproc(8), can
         be run manually or by a procmailrc(5) rule.

       Server Installation
         The DCC server, dccd(8), also requires that the DCC home directory exist.
         It does not use the client shared or memory mapped file of server ad-
         dresses, but it requires other files.  One is the /var/dcc/ids file of
         client-IDs,  server-IDs, and corresponding passwords.  Another is a flod
         file of peers that send and receive floods of reports of checksums with
         large counts.  Both files are described in dccd(8).

         The server daemon should be started when the system is rebooted, probably
         before sendmail.  See the misc/rcDCC and misc/start-dccd files in the DCC
         source.

         The database should be cleaned regularly with dbclean(8) such as by run-
         ning the crontab job that is in the misc directory.

## SEE ALSO

         cdcc(8), dbclean(8), dcc(8), dccd(8), dccifd(8), dccm(8), dccproc(8),
         dblist(8), dccsight(8), sendmail(8).

## HISTORY

         Distributed Checksum Clearinghouses are based on an idea of Paul Vixie
         with code designed and written at Rhyolite Software starting in 2000.
         This document describes version RHYOLITE_VERSION.

                                    March 22, 2024