0
+ − 1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+ − 2 < HTML >
+ − 3 < HEAD >
+ − 4 < META HTTP-EQUIV = "Content-Type" CONTENT = "text/html; charset=iso-8859-1" >
+ − 5 < TITLE > dcc.0.8</ TITLE >
+ − 6 < META http-equiv = "Content-Style-Type" content = "text/css" >
+ − 7 < STYLE type = "text/css" >
+ − 8 BODY { background-color : white ; color : black }
+ − 9 ADDRESS { font-size : smaller }
+ − 10 IMG . logo { width : 6 em ; vertical-align : middle }
+ − 11 </ STYLE >
+ − 12 </ HEAD >
+ − 13 < BODY >
+ − 14 < PRE >
+ − 15 <!-- Manpage converted by man2html 3.0.1 -->
+ − 16 < B >< A HREF = "dcc.html" > DCC(8)</ A ></ B > Distributed Checksum Clearinghouse < B >< A HREF = "dcc.html" > DCC(8)</ A ></ B >
+ − 17
+ − 18
+ − 19 </ PRE >
+ − 20 < H2 >< A NAME = "NAME" > NAME</ A ></ H2 >< PRE >
+ − 21 < B > DCC</ B > -- Distributed Checksum Clearinghouse
+ − 22
+ − 23
+ − 24 </ PRE >
+ − 25 < H2 >< A NAME = "DESCRIPTION" > DESCRIPTION</ A ></ H2 >< PRE >
+ − 26 The Distributed Checksum Clearinghouse or < B > DCC</ B > is a cooperative, distrib-
+ − 27 uted system intended to detect "bulk" mail or mail sent to many people.
+ − 28 It allows individuals receiving a single mail message to determine that
+ − 29 many other people have received essentially identical copies of the mes-
+ − 30 sage and so reject or discard the message.
+ − 31
+ − 32 Source for the server, client, and utilities is available at Rhyolite
+ − 33 Software, LLC, http://www.rhyolite.com/dcc/ It is free for organizations
+ − 34 that do not sell spam or virus filtering services.
+ − 35
+ − 36 < A NAME = "How-the-DCC-Is-Used" >< B > How the DCC Is Used</ B ></ A >
+ − 37 The DCC can be viewed as a tool for end users to enforce their right to
+ − 38 "opt-in" to streams of bulk mail by refusing bulk mail except from
+ − 39 sources in a "whitelist." Whitelists are the responsibility of DCC
+ − 40 clients, since only they know which bulk mail they solicited.
+ − 41
+ − 42 False positives or mail marked as bulk by a DCC server that is not bulk
+ − 43 occur only when a recipient of a message reports it to a DCC server as
+ − 44 having been received many times or when the "fuzzy" checksums of differ-
+ − 45 ing messages are the same. The fuzzy checksums ignore aspects of mes-
+ − 46 sages in order to compute identical checksums for substantially identical
+ − 47 messages. The fuzzy checksums are designed to ignore only differences
+ − 48 that do not affect meanings. So in practice, you do not need to worry
+ − 49 about DCC false positive indications of "bulk," but not all bulk mail is
+ − 50 unsolicited bulk mail or spam. You must either use whitelists to distin-
+ − 51 guish solicited from unsolicited bulk mail or only use DCC indications of
+ − 52 "bulk" as part of a scoring system such as SpamAssassin. Besides unso-
+ − 53 licited bulk email or spam, bulk messages include legitimate mail such as
+ − 54 order confirmations from merchants, legitimate mailing lists, and empty
+ − 55 or test messages.
+ − 56
+ − 57 A DCC server estimates the number copies of a message by counting check-
+ − 58 sums reported by DCC clients. Each client must decide which bulk mes-
+ − 59 sages are unsolicited and what degree of "bulkiness" is objectionable.
+ − 60 Client DCC software marks, rejects, or discards mail that is bulk accord-
+ − 61 ing to local thresholds on target addresses from DCC servers and unso-
+ − 62 licited according to local whitelists.
+ − 63
+ − 64 DCC servers are usually configured to receive reports from as many tar-
+ − 65 gets as possible, including sources that cannot be trusted to not exag-
+ − 66 gerate the number of copies of a message they see. A user of a DCC
+ − 67 client angry about receiving a message could report it with 1,000,000
+ − 68 separate DCC reports or with a single report claiming 1,000,000 targets.
+ − 69 An unprincipled user could subscribe a "spam trap" to mailing lists such
+ − 70 as those of the IETF or CERT. Such abuses of the system area not prob-
+ − 71 lems, because much legitimate mail is "bulk." You cannot reject bulk
+ − 72 mail unless you have a whitelist of sources of legitimate bulk mail.
+ − 73
+ − 74 DCC can also be used by an Internet service provider to detect bulk mail
+ − 75 coming from its own customers. In such circumstances, the DCC client
+ − 76 might be configured to only log bulk mail from unexpected (not
+ − 77 whitelisted) customers.
+ − 78
+ − 79 < A NAME = "What-the-DCC-Is" >< B > What the DCC Is</ B ></ A >
+ − 80 A DCC server accumulates counts of cryptographic checksums of messages
+ − 81 but not the messages themselves. It exchanges reports of frequently seen
+ − 82 checksums with other servers. DCC clients send reports of checksums
+ − 83 related to incoming mail to a nearby DCC server running < B >< A HREF = "dccd.html" > dccd(8)</ A ></ B > . Each
+ − 84 report from a client includes the number of recipients for the message.
+ − 85 A DCC server accumulates the reports and responds to clients the the cur-
+ − 86 rent total number of recipients for each checksum. The client adds an
+ − 87 SMTP header to incoming mail containing the total counts. It then dis-
+ − 88 cards or rejects mail that is not whitelisted and has counts that exceed
+ − 89 local thresholds.
+ − 90
+ − 91 A special value of the number of addressees is "MANY" and means it is
+ − 92 certain that this message was bulk and might be unsolicited, perhaps
+ − 93 because it came from a locally blacklisted source or was addressed to an
+ − 94 invalid address or "spam trap." The special value "MANY" is merely the
+ − 95 largest value that fits in the fixed sized field containing the count of
+ − 96 addressees. That "infinity" accumulated total can be reached with mil-
+ − 97 lions of independent reports as well as with one or two.
+ − 98
+ − 99 DCC servers < I > flood</ I > or send reports of checksums of bulk mail to neighbor-
+ − 100 ing servers.
+ − 101
+ − 102 To keep a server's database of checksums from growing without bound,
+ − 103 checksums are forgotten when they become old. Checksums of bulk mail are
+ − 104 kept longer. See < B >< A HREF = "dbclean.html" > dbclean(8)</ A ></ B > .
+ − 105
+ − 106 DCC clients pick the nearest working DCC server using a small shared or
+ − 107 memory mapped file, < I > @prefix@/map</ I > . It contains server names, port num-
+ − 108 bers, passwords, recent performance measures, and so forth. This file
+ − 109 allows clients to use quick retransmission timeouts and to waste little
+ − 110 time on servers that have temporarily stopped working or become unreach-
+ − 111 able. The utility program < B >< A HREF = "cdcc.html" > cdcc(8)</ A ></ B > is used to maintain this file as well
+ − 112 as to check the health of servers.
+ − 113
+ − 114 < A NAME = "X-DCC-Headers" >< B > X-DCC Headers</ B ></ A >
+ − 115 The DCC software includes several programs used by clients. < B >< A HREF = "dccm.html" > Dccm(8)</ A ></ B > uses
+ − 116 the sendmail "milter" interface to query a DCC server, add header lines
+ − 117 to incoming mail, and reject mail whose total checksum counts are high.
+ − 118 Dccm is intended to be run with SMTP servers using sendmail.
+ − 119
+ − 120 < B >< A HREF = "dccproc.html" > Dccproc(8)</ A ></ B > adds header lines to mail presented by file name or < I > stdin</ I > , but
+ − 121 relies on other programs such as procmail to deal with mail with large
+ − 122 counts. < B >< A HREF = "dccsight.html" > Dccsight(8)</ A ></ B > is similar but deals with previously computed check-
+ − 123 sums.
+ − 124
+ − 125 < B >< A HREF = "dccifd.html" > Dccifd(8)</ A ></ B > is similar to dccproc but is not run separately for each mail
+ − 126 message and so is far more efficient. It receives mail messages via a
+ − 127 socket somewhat like dccm, but with a simpler protocol that can be used
+ − 128 by Perl scripts or other programs.
+ − 129
+ − 130 DCC SMTP header lines are of one of the forms:
+ − 131
+ − 132 X-DCC-brand-Metrics: client server-ID; bulk cknm1=count cknm2=count ...
+ − 133 X-DCC-brand-Metrics: client; whitelist
+ − 134 where
+ − 135 < I > whitelist</ I > appears if the global or per-user < I > whiteclnt</ I > file marks the
+ − 136 message as good.
+ − 137 < I > brand</ I > is the "brand name" of the DCC server, such as "RHYOLITE".
+ − 138 < I > client</ I > is the name or IP address of the DCC client that added the
+ − 139 header line to the SMTP message.
+ − 140 < I > server-ID</ I > is the numeric ID of the DCC server that the DCC client con-
+ − 141 tacted.
+ − 142 < I > bulk</ I > is present if one or more checksum counts exceeded the DCC
+ − 143 client's thresholds to make the message "bulky."
+ − 144 < I > bulk</ I > < I > rep</ I > is present if the DCC reputation of the IP address of the
+ − 145 sender is bad.
+ − 146 < I > cknm1</ I > ,< I > cknm2</ I > ,... are types of checksums:
+ − 147 < I > IP</ I > address of SMTP client
+ − 148 < I > env</ I >< B > _</ B >< I > From</ I > SMTP envelope value
+ − 149 < I > From</ I > SMTP header line
+ − 150 < I > Message-ID</ I > SMTP header line
+ − 151 < I > Received</ I > last Received: header line in the SMTP message
+ − 152 < I > substitute</ I > SMTP header line chosen by the DCC client, pre-
+ − 153 fixed with the name of the header
+ − 154 < I > Body</ I > SMTP body ignoring white-space
+ − 155 < I > Fuz1</ I > filtered or "fuzzy" body checksum
+ − 156 < I > Fuz2</ I > another filtered or "fuzzy" body checksum
+ − 157 < I > rep</ I > DCC reputation of the mail sender or the esti-
+ − 158 mated probability that the message is bulk.
+ − 159 Counts for < I > IP</ I > , < I > env</ I >< B > _</ B >< I > From</ I > , < I > From</ I > , < I > Message-Id</ I > , < I > Received</ I > , and
+ − 160 < I > substitute</ I > checksums are omitted by the DCC client if the
+ − 161 server says it has no information. Counts for < I > Fuz1</ I > and < I > Fuz2</ I >
+ − 162 are omitted if the message body is empty or contains too lit-
+ − 163 tle of the right kind of information for the checksum to be
+ − 164 computed.
+ − 165 < I > count</ I > is the total number of recipients of messages with that check-
+ − 166 sum reported directly or indirectly to the DCC server. The
+ − 167 special count "MANY" means that DCC client have claimed that
+ − 168 the message is directed at millions of recipients. "MANY"
+ − 169 imples the message is definitely bulk, but not necessarily
+ − 170 unsolicited. The special counts "OK" and "OK2" mean the
+ − 171 checksum has been marked "good" or "half-good" by DCC servers.
+ − 172
+ − 173 < A NAME = "Mailing-lists" >< B > Mailing lists</ B ></ A >
+ − 174 Legitimate mailing list traffic differs from spam only in being solicited
+ − 175 by recipients. Each client should have a private whitelist.
+ − 176
+ − 177 DCC whitelists can also mark mail as unsolicited bulk using blacklist
+ − 178 entries for commonly forged values such as "From: user@public.com".
+ − 179
+ − 180 < A NAME = "White-and-Blacklists" >< B > White and Blacklists</ B ></ A >
+ − 181 DCC server and client whitelist files share a common format. Server
+ − 182 files are always named < I > whitelist</ I > and one is required to be in the DCC
+ − 183 home directory with the other server files. Client whitelist files are
+ − 184 named < I > whiteclnt</ I > in the DCC home directory or a subdirectory specified
+ − 185 with the < B > -U</ B > option for < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > . They specify mail that should not be
+ − 186 reported to a DCC server or that is always unsolicited and almost cer-
+ − 187 tainly bulk.
+ − 188
+ − 189 A DCC whitelist file contains blank lines, comments starting with "#",
+ − 190 and lines of the following forms:
+ − 191 < I > include</ I > < I > file</ I >
+ − 192 Copies the contents of < I > file</ I > into the whitelist. It can occur
+ − 193 only in the main whitelist or whiteclnt file and not in an
+ − 194 included file. The file name should be absolute or relative to
+ − 195 the DCC home directory.
+ − 196
+ − 197 < I > count</ I > < I > value</ I >
+ − 198 lines specify checksums that should be white- or blacklisted.
+ − 199 < I > count</ I > < I > env</ I >< B > _</ B >< I > From</ I > < I > 821-path</ I >
+ − 200 < I > count</ I > < I > env</ I >< B > _</ B >< I > To</ I > < I > dest-mailbox</ I >
+ − 201 < I > count</ I > < I > From</ I > < I > 822-mailbox</ I >
+ − 202 < I > count</ I > < I > Message-ID</ I > < I > < string> </ I >
+ − 203 < I > count</ I > < I > Received</ I > < I > string</ I >
+ − 204 < I > count</ I > < I > Substitute</ I > < I > header</ I > < I > string</ I >
+ − 205 < I > count</ I > < I > Hex</ I > < I > ctype</ I > < I > cksum</ I >
+ − 206 < I > count</ I > < I > ip</ I > < I > IP-address</ I >
+ − 207
+ − 208 < I > MANY</ I > < I > value</ I >
+ − 209 indicates that millions of targets have received messages
+ − 210 with the header, IP address, or checksum < I > value</ I > .
+ − 211 < I > OK</ I > < I > value</ I >
+ − 212 < I > OK2</ I > < I > value</ I >
+ − 213 say that messages with the header, IP address, or check-
+ − 214 sum < I > value</ I > are OK and should not reported to DCC servers
+ − 215 or be greylisted. < I > OK2</ I > says that the message is "half
+ − 216 OK." Two < I > OK2</ I > checksums associated with a message are
+ − 217 equivalent to one < I > OK</ I > .
+ − 218 A DCC server never shares or < I > floods</ I > reports containing
+ − 219 checksums marked in its whitelist with OK or OK2 to other
+ − 220 servers. A DCC client does not report or ask its server
+ − 221 about messages with a checksum marked OK or OK2 in the
+ − 222 client whitelist. This is intended to allow a DCC client
+ − 223 to keep private mail so private that even its checksums
+ − 224 are not disclosed.
+ − 225 < I > MX</ I > < I > IP-address-or-hostname</ I >
+ − 226 < I > MXDCC</ I > < I > IP-address-or-hostname</ I >
+ − 227 mark an address or block of addresses of trust mail
+ − 228 relays including MX servers, smart hosts, and bastion or
+ − 229 DMZ relays. The DCC clients < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > , < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > , and
+ − 230 < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > parse and skip initial Received: headers added
+ − 231 by listed MX servers to determine the external sources of
+ − 232 mail messages. Unsolicited bulk mail that has been for-
+ − 233 warded through listed addresses is discarded by < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B >
+ − 234 and < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > as if with < B > -a</ B > < I > DISCARD</ I > instead of rejected.
+ − 235 < I > MXDCC</ I > marks addresses that are MX servers that run DCC
+ − 236 clients. The checksums for a mail message that has been
+ − 237 forwarded through an address listed as MXDCC queried
+ − 238 instead of reported.
+ − 239 < I > SUBMIT</ I > < I > IP-address-or-hostname</ I >
+ − 240 marks an IP address or block addresses of SMTP submission
+ − 241 clients such as web browsers that cannot tolerate 4yz
+ − 242 temporary rejections but that cannot be trusted to not
+ − 243 send spam. Since they are local addresses, DCC Reputa-
+ − 244 tions are not computed for them.
+ − 245
+ − 246 < I > value</ I > in < I > count</ I > < I > value</ I > lines can be
+ − 247 < I > dest-mailbox</ I >
+ − 248 is an RFC 821 address or a local user name.
+ − 249 < I > 821-path</ I >
+ − 250 is an RFC 821 address.
+ − 251 < I > 822-mailbox</ I >
+ − 252 is an RFC 822 address with optional name.
+ − 253 < I > Substitute</ I > < I > header</ I >
+ − 254 is the name of an SMTP header such as "Sender" or the
+ − 255 name of one of two SMTP envlope values, "HELO," or
+ − 256 "Mail_Host" for the resolved host name from the < I > 821-path</ I >
+ − 257 in the message.
+ − 258 < I > Hex</ I > < I > ctype</ I > < I > cksum</ I >
+ − 259 starts with the string < I > Hex</ I > followed a checksum type, and
+ − 260 a string of four hexadecimal numbers obtained from a DCC
+ − 261 log file or the < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > command using < B > -CQ</ B > . The check-
+ − 262 sum type is < I > body</ I > , < I > Fuz1</ I > , or < I > Fuz2</ I > or one of the preceding
+ − 263 checksum types such as < I > env</ I >< B > _</ B >< I > From</ I > .
+ − 264 < I > IP-address</ I >
+ − 265 is a host name, IPv4 or IPv6 address, or a block of IP
+ − 266 addresses in the standard xxx/mm from with mm limited for
+ − 267 server whitelists to 16 for IPv4 or 112 for IPv6. There
+ − 268 can be at most 64 CIDR blocks in a client < I > whiteclnt</ I > file.
+ − 269 A host name is converted to IP addresses with DNS,
+ − 270 < I > /etc/hosts</ I > or other mechanisms and one checksum for each
+ − 271 addresses added to the whitelist.
+ − 272
+ − 273 < I > option</ I > < I > setting</ I >
+ − 274 can only be in a DCC client < I > whiteclnt</ I > file used by < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > ,
+ − 275 < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > or < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > . Settings in per-user whiteclnt files
+ − 276 override settings in the global file. < I > Setting</ I > can be any of the
+ − 277 following:
+ − 278 < I > option</ I > < I > log-all</ I >
+ − 279 to log all mail messages.
+ − 280 < I > option</ I > < I > log-normal</ I >
+ − 281 to log only messages that meet the logging thresholds.
+ − 282 < I > option</ I > < I > log-subdirectory-day</ I >
+ − 283 < I > option</ I > < I > log-subdirectory-hour</ I >
+ − 284 < I > option</ I > < I > log-subdirectory-minute</ I >
+ − 285 creates log files containing mail messages in subdirecto-
+ − 286 ries of the form < I > JJJ</ I > , < I > JJJ/HH</ I > , or < I > JJJ/HH/MM</ I > where < I > JJJ</ I > is the
+ − 287 current julian day, < I > HH</ I > is the current hour, and < I > MM</ I > is the
+ − 288 current minute. See also the < B > -l</ B > < I > logdir</ I > option for < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > ,
+ − 289 < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > , and < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > .
+ − 290 < I > option</ I > < I > dcc-on</ I >
+ − 291 < I > option</ I > < I > dcc-off</ I >
+ − 292 Control DCC filtering. See the discussion of < B > -W</ B > for
+ − 293 < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > and < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > .
+ − 294 < I > option</ I > < I > greylist-on</ I >
+ − 295 < I > option</ I > < I > greylist-off</ I >
+ − 296 to control greylisting. Greylisting for other recipients
+ − 297 in the same SMTP transaction can still cause greylist tem-
+ − 298 porary rejections. < I > greylist-off</ I > in the main whiteclnt
+ − 299 file.
+ − 300 < I > option</ I > < I > greylist-log-on</ I >
+ − 301 < I > option</ I > < I > greylist-log-off</ I >
+ − 302 to control logging of greylisted mail messages.
+ − 303 < I > option</ I > < I > DCC-rep-off</ I >
+ − 304 < I > option</ I > < I > DCC-rep-on</ I >
+ − 305 to honor or ignore DCC Reputations computed by the DCC
+ − 306 server.
+ − 307 < I > option</ I > < I > DNSBL1-off</ I >
+ − 308 < I > option</ I > < I > DNSBL1-on</ I >
+ − 309 < I > option</ I > < I > DNSBL2-off</ I >
+ − 310 < I > option</ I > < I > DNSBL2-on</ I >
+ − 311 < I > option</ I > < I > DNSBL3-off</ I >
+ − 312 < I > option</ I > < I > DNSBL3-on</ I >
+ − 313 honor or ignore results of DNS blacklist checks configured
+ − 314 with < B > -B</ B > for < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > , < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > , and < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > .
+ − 315 < I > option</ I > < I > MTA-first</ I >
+ − 316 < I > option</ I > < I > MTA-last</ I >
+ − 317 consider MTA determinations of spam or not-spam first so
+ − 318 they can be overridden by < I > whiteclnt</ I > files, or last so that
+ − 319 they can override < I > whiteclnt</ I > < I > files.</ I >
+ − 320 < I > option</ I > < I > forced-discard-ok</ I >
+ − 321 < I > option</ I > < I > no-forced-discard</ I >
+ − 322 control whether < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > and < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > are allowed to dis-
+ − 323 card a message for one mailbox for which it is spam when it
+ − 324 is not spam and must be delivered to another mailbox. This
+ − 325 can happen if a mail message is addressed to two or more
+ − 326 mailboxes with differing whitelists. Discarding can be
+ − 327 undesirable because false positives are not communicated to
+ − 328 mail senders. To avoid discarding, < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > and < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B >
+ − 329 running in proxy mode temporarily reject SMTP envelope < I > Rcpt</ I >
+ − 330 < I > To</ I > values that involve differing < I > whiteclnt</ I > files.
+ − 331 < I > option</ I > < I > threshold</ I > < I > type,rej-thold</ I >
+ − 332 has the same effects as < B > -c</ B > < I > type,rej-thold</ I > for < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > or
+ − 333 < B > -t</ B > < I > type,rej-thold</ I > for < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > and < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > . It is useful
+ − 334 only in per-user whiteclnt files to override the global DCC
+ − 335 checksum thresholds.
+ − 336 < I > option</ I > < I > spam-trap-accept</ I >
+ − 337 < I > option</ I > < I > spam-trap-reject</ I >
+ − 338 say that mail should be reported to the DCC server as
+ − 339 extremely bulk or with target counts of < I > MANY</ I > . Greylisting,
+ − 340 DNS blacklist (DNSBL), and other checks are turned off.
+ − 341 < I > Spam-trap-accept</ I > tells the MTA to accept the message while
+ − 342 < I > spam-trap-reject</ I > tells the MTA to reject the message. Use
+ − 343 < I > Spam-trap-accept</ I > for spam traps that should not be dis-
+ − 344 closed. < I > Spam-trap-reject</ I > can be used on < I > catch-all</ I > mail-
+ − 345 boxes that might receive legitimate mail by typographical
+ − 346 errors and that senders should be told about.
+ − 347
+ − 348 In the absence of explicit settings, the default in the main
+ − 349 whiteclnt file is equivalent to
+ − 350 < I > option</ I > < I > log-normal</ I >
+ − 351 < I > option</ I > < I > dcc-on</ I >
+ − 352 < I > option</ I > < I > greylist-on</ I >
+ − 353 < I > option</ I > < I > greylist-log-on</ I >
+ − 354 < I > option</ I > < I > DCC-rep-off</ I >
+ − 355 < I > option</ I > < I > DNSBL1-off</ I >
+ − 356 < I > option</ I > < I > DNSBL2-off</ I >
+ − 357 < I > option</ I > < I > DNSBL3-off</ I >
+ − 358 < I > MTA-last</ I >
+ − 359 < I > option</ I > < I > no-forced-discard</ I >
+ − 360 The defaults for individual recipient < I > whiteclnt</ I > files are the
+ − 361 same except as change by explicit settings in the main file.
+ − 362
+ − 363 Checksums of the IP address of the SMTP client sending a mail message are
+ − 364 practically unforgeable, because it is impractical for an SMTP client to
+ − 365 "spoof" its address or pretend to use some other IP address. That would
+ − 366 make the IP address of the sender useful for whitelisting, except that
+ − 367 the IP address of the SMTP client is often not available to users of
+ − 368 < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > . In addition, legitimate mail relays make whitelist entries
+ − 369 for IP addresses of little use. For example, the IP address from which a
+ − 370 message arrived might be that of a local relay instead of the home
+ − 371 address of a whitelisted mailing list.
+ − 372
+ − 373 Envelope and header < I > From</ I > values can be forged, so whitelist entries for
+ − 374 their checksums are not entirely reliable.
+ − 375
+ − 376 Checksums of < I > env</ I >< B > _</ B >< I > To</ I > values are never sent to DCC servers. They are valid
+ − 377 in only < I > whiteclnt</ I > files and used only by < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > , < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > , and
+ − 378 < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > when the envelope < I > Rcpt</ I > < I > To</ I > value is known.
+ − 379
+ − 380 < A NAME = "Greylists" >< B > Greylists</ B ></ A >
+ − 381 The DCC server, < B >< A HREF = "dccd.html" > dccd(8)</ A ></ B > , can be used to maintain a greylist database for
+ − 382 some DCC clients including < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > and < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > . Greylisting involves
+ − 383 temporarily refusing mail from unfamiliar SMTP clients and is unrelated
+ − 384 to filtering with a Distributed Checksum Clearinghouse.
+ − 385 See http://projects.puremagic.com/greylisting/
+ − 386
+ − 387 < A NAME = "Privacy" >< B > Privacy</ B ></ A >
+ − 388 Because sending mail is a less private act than receiving it, and because
+ − 389 sending bulk mail is usually not private at all and cannot be very pri-
+ − 390 vate, the DCC tries first to protect the privacy of mail recipients, and
+ − 391 second the privacy of senders of mail that is not bulk.
+ − 392
+ − 393 DCC clients necessarily disclose some information about mail they have
+ − 394 received. The DCC database contains checksums of mail bodies, header
+ − 395 lines, and source addresses. While it contains significantly less infor-
+ − 396 mation than is available by "snooping" on Internet links, it is important
+ − 397 that the DCC database be treated as containing sensitive information and
+ − 398 to not put the most private information in the DCC database. Given the
+ − 399 contents of a message, one might determine whether that message has been
+ − 400 received by a system that subscribes to the DCC. Guesses about the
+ − 401 sender and addressee of a message can also be validated if the checksums
+ − 402 of the message have been sent to a DCC server.
+ − 403
+ − 404 Because the DCC is distributed, organizations can operate their own DCC
+ − 405 servers, and configure them to share or "flood" only the checksums of
+ − 406 bulk mail that is not in local whitelists.
+ − 407
+ − 408 DCC clients should not report the checksums of messages known to be pri-
+ − 409 vate to a DCC server. For example, checksums of messages local to a sys-
+ − 410 tem or that are otherwise known a priori to not be unsolicited bulk
+ − 411 should not be sent to a remote DCC server. This can accomplished by
+ − 412 adding entries for the sender to the client's local whitelist file.
+ − 413 Client whitelist files can also include entries for email recipients
+ − 414 whose mail should not be reported to a DCC server.
+ − 415
+ − 416 < A NAME = "Security" >< B > Security</ B ></ A >
+ − 417 Whenever considering security, one must first consider the risks. The
+ − 418 worst DCC security problems are unauthorized commands to a DCC service,
+ − 419 denial of the DCC service, and corruption of DCC data. The worst that
+ − 420 can be done with remote commands to a DCC server is to turn it off or
+ − 421 otherwise cause it to stop responding. The DCC is designed to fail
+ − 422 gracefully, so that a denial of service attack would at worst allow
+ − 423 delivery of mail that would otherwise be rejected. Corruption of DCC
+ − 424 data might at worst cause mail that is already somewhat "bulk" by virtue
+ − 425 of being received by two or more people to appear have higher recipient
+ − 426 numbers. Since DCC users < I > must</ I > whitelist all sources of legitimate bulk
+ − 427 mail, this is also not a concern. Such security risks should be
+ − 428 addressed, but only with defenses that don't cost more than the possible
+ − 429 damage from an attack.
+ − 430
+ − 431 The DCC must contend with senders of unsolicited bulk mail who resort to
+ − 432 unlawful actions to express their displeasure at having their advertising
+ − 433 blocked. Because the DCC protocol is based on UDP, an unhappy advertiser
+ − 434 could try to flood a DCC server with packets supposedly from subscribers
+ − 435 or non-subscribers. DCC servers defend against that attack by rate-lim-
+ − 436 iting requests from anonymous users.
+ − 437
+ − 438 Also because of the use of UDP, clients must be protected against forged
+ − 439 answers to their queries. Otherwise an unsolicited bulk mail advertiser
+ − 440 could send a stream of "not spam" answers to an SMTP client while simul-
+ − 441 taneously sending mail that would otherwise be rejected. This is not a
+ − 442 problem for authenticated clients of the DCC because they share a secret
+ − 443 with the DCC. Unauthenticated, anonymous DCC clients do not share any
+ − 444 secrets with the DCC, except for unique and unpredictable bits in each
+ − 445 query or report sent to the DCC. Therefore, DCC servers cryptographi-
+ − 446 cally sign answers to unauthenticated clients with bits from the corre-
+ − 447 sponding queries. This protects against attackers that do not have
+ − 448 access to the stream of packets from the DCC client.
+ − 449
+ − 450 The passwords or shared secrets used in the DCC client and server pro-
+ − 451 grams are "cleartext" for several reasons. In any shared secret authen-
+ − 452 tication system, at least one party must know the secret or keep the
+ − 453 secret in cleartext. You could encrypt the secrets in a file, but
+ − 454 because they are used by programs, you would need a cleartext copy of the
+ − 455 key to decrypt the file somewhere in the system, making such a scheme
+ − 456 more expensive but no more secure than a file of cleartext passwords.
+ − 457 Asymmetric systems such as that used in UNIX allow one party to not know
+ − 458 the secrets, but they must be and are designed to be computationally
+ − 459 expensive when used in applications like the DCC that involve thousands
+ − 460 or more authentication checks per second. Moreover, because of "dictio-
+ − 461 nary attacks," asymmetric systems are now little more secure than keeping
+ − 462 passwords in cleartext. An adversary can compare the hash values of com-
+ − 463 binations of common words with /etc/passwd hash values to look for bad
+ − 464 passwords. Worse, by the nature of a client/server protocol like that
+ − 465 used in the DCC, clients must have the cleartext password. Since it is
+ − 466 among the more numerous and much less secure clients that adversaries
+ − 467 would seek files of DCC passwords, it would be a waste to complicate the
+ − 468 DCC server with an asymmetric system.
+ − 469
+ − 470 The DCC protocol is vulnerable to dictionary attacks to recover pass-
+ − 471 words. An adversary could capture some DCC packets, and then check to
+ − 472 see if any of the 100,000 to 1,000,000 passwords in so called "cracker
+ − 473 dictionaries" applied to a packet generated the same signature. This is
+ − 474 a concern only if DCC passwords are poorly chosen, such as any combina-
+ − 475 tion of words in an English dictionary. There are ways to prevent this
+ − 476 vulnerability regardless of how badly passwords are chosen, but they are
+ − 477 computationally expensive and require additional network round trips.
+ − 478 Since DCC passwords are created and typed into files once and do not need
+ − 479 to be remembered by people, it is cheaper and quite easy to simply choose
+ − 480 good passwords that are not in dictionaries.
+ − 481
+ − 482 < A NAME = "Reliability" >< B > Reliability</ B ></ A >
+ − 483 It is better to fail to filter unsolicited bulk mail than to fail to
+ − 484 deliver legitimate mail, so DCC clients fail in the direction of assuming
+ − 485 that mail is legitimate or even whitelisted.
+ − 486
+ − 487 A DCC client sends a report or other request and waits for an answer. If
+ − 488 no answer arrives within a reasonable time, the client retransmits.
+ − 489 There are many things that might result in the client not receiving an
+ − 490 answer, but the most important is packet loss. If the client's request
+ − 491 does not reach the server, it is easy and harmless for the client to
+ − 492 retransmit. If the client's request reached the server but the server's
+ − 493 response was lost, a retransmission to the same server would be misunder-
+ − 494 stood as a new report of another copy of the same message unless it is
+ − 495 detected as a retransmission by the server. The DCC protocol includes
+ − 496 transactions identifiers for this purpose. If the client retransmitted
+ − 497 to a second server, the retransmission would be misunderstood by the sec-
+ − 498 ond server as a new report of the same message.
+ − 499
+ − 500 Each request from a client includes a timestamp to aid the client in mea-
+ − 501 suring the round trip time to the server and to let the client pick the
+ − 502 closest server. Clients monitor the speed of all of the servers they
+ − 503 know including those they are not currently using, and use the quickest.
+ − 504
+ − 505 < A NAME = "Client-and-Server-IDs" >< B > Client and Server-IDs</ B ></ A >
+ − 506 Servers and clients use numbers or IDs to identify themselves. ID 1 is
+ − 507 reserved for anonymous, unauthenticated clients. All other IDs are asso-
+ − 508 ciated with a pair of passwords in the < I > ids</ I > file, the current and next or
+ − 509 previous and current passwords. Clients included their client IDs in
+ − 510 their messages. When they are not using the anonymous ID, they sign
+ − 511 their messages to servers with the first password associated with their
+ − 512 client-ID. Servers treat messages with signatures that match neither of
+ − 513 the passwords for the client-ID in their own < I > ids</ I > file as if the client
+ − 514 had used the anonymous ID.
+ − 515
+ − 516 Each server has a unique < I > server-ID</ I > less than 32768. Servers use their
+ − 517 IDs to identify checksums that they < I > flood</ I > to other servers. Each server
+ − 518 expects local clients sending administrative commands to use the server's
+ − 519 ID and sign administrative commands with the associated password.
+ − 520
+ − 521 Server-IDs must be unique among all systems that share reports by "flood-
+ − 522 ing." All servers must be told of the IDs all other servers whose
+ − 523 reports can be received in the local < I > @prefix@/flod</ I > file described in
+ − 524 < B >< A HREF = "dccd.html" > dccd(8)</ A ></ B > . However, server-IDs can be mapped during flooding between inde-
+ − 525 pendent DCC organizations.
+ − 526
+ − 527 < I > Passwd-IDs</ I > are server-IDs that should not be assigned to servers. They
+ − 528 appear in the often publicly readable < I > @prefix@/flod</ I > and specify passwords
+ − 529 in the private < I > @prefix@/ids</ I > file for the inter-server flooding protocol
+ − 530
+ − 531 The client identified by a < I > client-ID</ I > might be a single computer with a
+ − 532 single IP address, a single but multi-homed computer, or many computers.
+ − 533 Client-IDs are not used to identify checksum reports, but the organiza-
+ − 534 tion operating the client. A client-ID need only be unique among clients
+ − 535 using a single server. A single client can use different client-IDs for
+ − 536 different servers, each client-ID authenticated with a separate password.
+ − 537
+ − 538 An obscure but important part of all of this is that the inter-server
+ − 539 flooding algorithm depends on server-IDs and timestamps attached to
+ − 540 reports of checksums. The inter-server flooding mechanism requires coop-
+ − 541 erating DCC servers to maintain reasonable clocks ticking in UTC.
+ − 542 Clients include timestamps in their requests, but as long as their time-
+ − 543 stamps are unlikely to be repeated, they need not be very accurate.
+ − 544
+ − 545 < A NAME = "Installation-Considerations" >< B > Installation Considerations</ B ></ A >
+ − 546 DCC clients on a computer share information about which servers are cur-
+ − 547 rently working and their speeds in a shared memory segment. This segment
+ − 548 also contains server host names, IP addresses, and the passwords needed
+ − 549 to authenticate known clients to servers. That generally requires that
+ − 550 < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > , < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > , < B >< A HREF = "dccifd.html" > dccifd(8)</ A ></ B > , and < B >< A HREF = "cdcc.html" > cdcc(8)</ A ></ B > execute with an UID that can
+ − 551 write to the DCC home directory and its files. The sendmail interface,
+ − 552 dccm, is a daemon that can be started by an "rc" or other script already
+ − 553 running with the correct UID. The other two, dccproc and cdcc need to be
+ − 554 set-UID because they are used by end users. They relinquish set-UID
+ − 555 privileges when not needed.
+ − 556
+ − 557 Files that contain cleartext passwords including the shared file used by
+ − 558 clients must be readable only by "owner."
+ − 559
+ − 560 The data files required by a DCC can be in a single "home" directory,
+ − 561 < I > @prefix@</ I > . Distinct DCC servers can run on a single computer, provided
+ − 562 they use distinct UDP port numbers and home directories. It is possible
+ − 563 and convenient for the DCC clients using a server on the same computer to
+ − 564 use the same home directory as the server.
+ − 565
+ − 566 The DCC source distribution includes sample control files. They should
+ − 567 be modified appropriately and then copied to the DCC home directory.
+ − 568 Files that contain cleartext passwords must not be publicly readable.
+ − 569
+ − 570 The DCC source includes "feature" m4 files to configure sendmail to use
+ − 571 < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > to check a DCC server about incoming mail.
+ − 572
+ − 573 See also the < A HREF = "INSTALL.html" > INSTALL.html</ A > file.
+ − 574
+ − 575 < A NAME = "Client-Installation" >< B > Client Installation</ B ></ A >
+ − 576 Installing a DCC client starts with obtaining or compiling program bina-
+ − 577 ries for the client server data control tool, < B >< A HREF = "cdcc.html" > cdcc(8)</ A ></ B > . Installing the
+ − 578 sendmail DCC interface, < B >< A HREF = "dccm.html" > dccm(8)</ A ></ B > , or < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > , the general or
+ − 579 < B > procmail(1)</ B > interface is the main part of the client installation. Con-
+ − 580 necting the DCC to sendmail with dccm is most powerful, but requires
+ − 581 administrative control of the system running sendmail.
+ − 582
+ − 583 As noted above, cdcc and dccproc should be set-UID to a suitable UID.
+ − 584 Root or 0 is thought to be safe for both, because they are careful to
+ − 585 release privileges except when they need them to read or write files in
+ − 586 the DCC home directory. A DCC home directory, < I > @prefix@</ I > should be cre-
+ − 587 ated. It must be owned and writable by the UID to which cdcc is set.
+ − 588
+ − 589 After the DCC client programs have been obtained, contact the operator(s)
+ − 590 of the chosen DCC server(s) to obtain each server's hostname, port num-
+ − 591 ber, and a < I > client-ID</ I > and corresponding password. No client-IDs or pass-
+ − 592 words are needed touse DCC servers that allow anonymous clients. Use the
+ − 593 < I > load</ I > or < I > add</ I > commands of cdcc to create a < I > map</ I > file in the DCC home direc-
+ − 594 tory. It is usually necessary to create a client whitelist file of the
+ − 595 format described above. To accommodate users sharing a computer but not
+ − 596 ideas about what is solicited bulk mail, the client whitelist file can be
+ − 597 any valid path name and need not be in the DCC home directory.
+ − 598
+ − 599 If dccm is chosen, arrange to start it with suitable arguments before
+ − 600 sendmail is started. See the < I > homedir/dcc</ I >< B > _</ B >< I > conf</ I > file and the < I > misc/rcDCC</ I >
+ − 601 script in the DCC source. The procmail DCCM interface, < B >< A HREF = "dccproc.html" > dccproc(8)</ A ></ B > , can
+ − 602 be run manually or by a < B > procmailrc(5)</ B > rule.
+ − 603
+ − 604 < A NAME = "Server-Installation" >< B > Server Installation</ B ></ A >
+ − 605 The DCC server, < B >< A HREF = "dccd.html" > dccd(8)</ A ></ B > , also requires that the DCC home directory exist.
+ − 606 It does not use the client shared or memory mapped file of server
+ − 607 addresses, but it requires other files. One is the < I > @prefix@/ids</ I > file of
+ − 608 client-IDs, server-IDs, and corresponding passwords. Another is a < I > flod</ I >
+ − 609 file of peers that send and receive floods of reports of checksums with
+ − 610 large counts. Both files are described in < B >< A HREF = "dccd.html" > dccd(8)</ A ></ B > .
+ − 611
+ − 612 The server daemon should be started when the system is rebooted, probably
+ − 613 before sendmail. See the < I > misc/rcDCC</ I > and < I > misc/start-dccd</ I > files in the DCC
+ − 614 source.
+ − 615
+ − 616 The database should be cleaned regularly with < B >< A HREF = "dbclean.html" > dbclean(8)</ A ></ B > such as by run-
+ − 617 ning the crontab job that is in the misc directory.
+ − 618
+ − 619
+ − 620 </ PRE >
+ − 621 < H2 >< A NAME = "SEE-ALSO" > SEE ALSO</ A ></ H2 >< PRE >
+ − 622 < B >< A HREF = "cdcc.html" > cdcc(8)</ A ></ B > , < B >< A HREF = "dbclean.html" > dbclean(8)</ A ></ B > , < B >< A HREF = "dcc.html" > dcc(8)</ A ></ B > , < B >< A HREF = "dccd.html" > dccd(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 > ,
+ − 623 < B >< A HREF = "dblist.html" > dblist(8)</ A ></ B > , < B >< A HREF = "dccsight.html" > dccsight(8)</ A ></ B > , < B > sendmail(8)</ B > .
+ − 624
+ − 625
+ − 626 </ PRE >
+ − 627 < H2 >< A NAME = "HISTORY" > HISTORY</ A ></ H2 >< PRE >
+ − 628 Distributed Checksum Clearinghouses are based on an idea of Paul Vixie
+ − 629 with code designed and written at Rhyolite Software starting in 2000.
+ − 630 This document describes version 1.3.103.
+ − 631
+ − 632 February 26, 2009
+ − 633 </ PRE >
+ − 634 < HR >
+ − 635 < ADDRESS >
+ − 636 Man(1) output converted with
+ − 637 < a href = "http://www.oac.uci.edu/indiv/ehood/man2html.html" > man2html</ a >
+ − 638 modified for the DCC $Date 2001/04/29 03:22:18 $
+ − 639 < BR >
+ − 640 < A HREF = "http://www.dcc-servers.net/dcc/" >
+ − 641 < IMG SRC = "http://logos.dcc-servers.net/border.png"
+ − 642 class = logo ALT = "DCC logo" >
+ − 643 </ A >
+ − 644 < A HREF = "http://validator.w3.org/check?uri=referer" >
+ − 645 < IMG class = logo ALT = "Valid HTML 4.01 Strict"
+ − 646 SRC = "http://www.w3.org/Icons/valid-html401" >
+ − 647 </ A >
+ − 648 </ ADDRESS >
+ − 649 </ BODY >
+ − 650 </ HTML >