1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
|
DCC(8) Distributed Checksum Clearinghouse DCC(8)
NNAAMMEE
DDCCCC -- Distributed Checksum Clearinghouse
DDEESSCCRRIIPPTTIIOONN
The Distributed Checksum Clearinghouse or DDCCCC 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.
Freely redistributable source for the server, client, and utilities is
available at Rhyolite Software, http://www.rhyolite.com/dcc/
HHooww tthhee DDCCCC IIss UUsseedd
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.
The only false positives (mail marked as "bulk" by a DCC server that is
not) occur when one of the recipients of a message report it to a DCC
server as having been received many times or when the "fuzzy" checksums
of differing messages are the same. The fuzzy checksums ignore aspects
of messages in order to compute identical checksums for substantially
identical messages. The fuzzy checksums are designed to ignore only dif-
ferences that do not affect meanings.
It is not reasonable to worry about third parties reporting your incoming
or outgoing mail to a DCC server as bulk unless you give them copies. If
you trust yourself and your correspondents to not report your mutual mail
as bulk, then false positives are not a concern.
A DCC server computes a lower bound on the total number of addresses to
which a message has been sent by counting checksums reported by DCC
clients. Each client must decide which bulk messages are unsolicited and
what degree of "bulkiness" is objectionable. Client DCC software marks,
rejects, or discards mail that is bulk according to local thresholds on
target addresses from DCC servers and unsolicited according to local
whitelists. DCC servers are usually configured to receive reports from
as many targets as possible, including sources that cannot be trusted to
not exaggerate the number of copies of a message they see. An end user
of a DCC client angry about receiving a message could report it with
10,000,000 separate DCC packets or with a single report claiming as many
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 problems, because much legitimate mail is "bulk." You cannot reject
bulk mail unless you have a whitelist of sources of legitimate bulk mail.
The 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
white-listed) sources. See the --NN option for dccm(8) or dccifd(8).
WWhhaatt tthhee DDCCCC IIss
A DCC server accumulates counts of cryptographically secure checksums of
messages but not the messages themselves. It exchanges reports of fre-
quently seen checksums with other servers. DCC clients send reports of
checksums related to incoming mail to a nearby DCC server running
dccd(8). Each report from a client includes the number of recipients for
the message. A DCC server accumulates the reports and responds to
clients the the current total number of recipients for each checksum.
The client adds an SMTP header to incoming mail containing the total
counts. It then discards or rejects mail that is not "white-listed" and
has counts that exceed local thresholds.
A special value of the number of addressees is "MANY" and means it is
certain that this message was 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 fixed sized field containing the count of
addressees. That "infinity" accumulated total can be reached with mil-
lions of independent reports as well as with one or two.
DCC servers share or _f_l_o_o_d reports of checksums that are seen frequently.
Each server has its own threshold for determining "frequently," because a
message sent to 50 addressees in a domain with 60 mailboxes is more
likely to be unsolicited bulk advertising than a message sent to 100
addressees in a domain with 600,000 mailboxes.
To keep a server's database of checksums from growing without bound,
checksums are forgotten when they become old. Checksums with large
totals are kept longer. See dbclean(8).
DCC clients pick the nearest working DCC server using a small shared or
memory mapped file, _/_v_a_r_/_d_c_c_/_m_a_p. 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.
XX--DDCCCC HHeeaaddeerrss
The DCC 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 _s_t_d_i_n, 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 so is far 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.
DCC SMTP header lines are of the form:
X-DCC-brand-Metrics: chost server-ID; bulk cknm1=count cknm2=count ...
where
_b_r_a_n_d is the "brand name" of the DCC server, such as "RHYOLITE".
_c_h_o_s_t is the name or IP address of the DCC client that added the
header line to the SMTP message.
_s_e_r_v_e_r_-_I_D is the numeric ID of the DCC server that the DCC client con-
tacted.
_b_u_l_k is present if one or more checksum counts exceeded the DCC
client's thresholds to make the message "bulky."
_c_k_n_m_1,_c_k_n_m_2,... are types of checksums, and one of
_I_P address of SMTP client
_e_n_v___F_r_o_m SMTP envelope value
_F_r_o_m SMTP header line
_M_e_s_s_a_g_e_-_I_D SMTP header line
_R_e_c_e_i_v_e_d last Received: header line in the SMTP message
_s_u_b_s_t_i_t_u_t_e SMTP header line chosen by the DCC client, pre-
fixed with the name of the header
_B_o_d_y SMTP body ignoring white-space
_F_u_z_1 filtered or "fuzzy" body checksum
_F_u_z_2 another filtered or "fuzzy" body checksum
Counts for _I_P, _e_n_v___F_r_o_m, _F_r_o_m, _M_e_s_s_a_g_e_-_I_d, _R_e_c_e_i_v_e_d, and
_s_u_b_s_t_i_t_u_t_e checksums are omitted by the DCC client if the
server says it has no information. Counts for _B_o_d_y, _F_u_z_1, and
_F_u_z_2 are omitted if the message body is empty or contains too
little of the right kind of information for the checksum to be
computed.
_c_o_u_n_t 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"
imples the message 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.
An example header line is:
X-DCC-RHYOLITE-Metrics: calcite.rhyolite.com 101; Body=16 Fuz1=16 Fuz2=16
DCC clients commonly accept any mail regardless of other checksum counts
with at least one "OK" or at least two "OK2" counts among IP, env_from,
and From checksum counts. It is common to reject other mail with large
(including "MANY") counts among Received, Body, Fuz1, and Fuz2 counts.
It is generally not wise to reject mail based on the other counts. For
example, "MAILER-DAEMON" appears to send vast quantities of mail.
MMaaiilliinngg lliissttss
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
entries for commonly forged marks such as "From: user@public.com".
Systems that send many essentially identical copies of solicited mail
such as "auto-responders," should be in the DCC servers whitelists
because their messages are often substantially identical and so "bulk."
WWhhiittee aanndd BBllaacckklliissttss
DCC server and client whitelist files share a common format. Server
files are always named _w_h_i_t_e_l_i_s_t and one is required to be in the DCC
home directory with the other server files. Client whitelist files are
commonly named _w_h_i_t_e_c_l_n_t in the DCC home directory or a subdirectory
specified with the --UU option for dccm(8). They specify mail that should
not be reported to a DCC server or that is unsolicited bulk.
A DCC whitelist file contains blank lines, comments starting with "#",
and lines of the forms:
_i_n_c_l_u_d_e _p_a_t_h_n_a_m_e
_o_p_t_i_o_n _s_e_t_t_i_n_g
_c_o_u_n_t _i_p _h_o_s_t_n_a_m_e
_c_o_u_n_t _e_n_v___F_r_o_m _8_2_1_-_p_a_t_h
_c_o_u_n_t _e_n_v___T_o _d_e_s_t_-_m_a_i_l_b_o_x
_c_o_u_n_t _F_r_o_m _8_2_2_-_m_a_i_l_b_o_x
_c_o_u_n_t _s_u_b_s_t_i_t_u_t_e _h_e_a_d_e_r _s_t_r_i_n_g
_c_o_u_n_t _M_e_s_s_a_g_e_-_I_D _<_s_t_r_i_n_g_>
_c_o_u_n_t _R_e_c_e_i_v_e_d _s_t_r_i_n_g
_c_o_u_n_t _h_e_x___t_y_p_e _h_e_x___c_k_s_u_m
where
_i_n_c_l_u_d_e can occur only in the main whitelist file.
_p_a_t_h_n_a_m_e should be absolute or relative to the DCC home directory.
_o_p_t_i_o_n _s_e_t_t_i_n_g can only be in a DCC client whitelist or whiteclnt
file and affect only dccifd(8) and dccm(8). Settings in per-
user whiteclnt files override settings in the global file.
_S_e_t_t_i_n_g can be
_l_o_g_-_a_l_l to log all mail messages.
_l_o_g_-_n_o_r_m_a_l
to log only messages that meet the logging thresh-
olds.
_d_c_c_-_o_n
_d_c_c_-_o_f_f Control DCC filtering. See the discussion of --WW
for dccm(8) and dccifd(8).
_g_r_e_y_l_i_s_t_-_o_f_f
_g_r_e_y_l_i_s_t_-_o_n
to control greylisting. Greylisting for other
recipients in the same SMTP transaction can still
cause greylist temporary rejections. _g_r_e_y_l_i_s_t_-_o_f_f
in the main whiteclnt file.
_g_r_e_y_l_i_s_t_-_l_o_g_-_o_n
_g_r_e_y_l_i_s_t_-_l_o_g_-_o_f_f
to control logging of greylisted mail messages.
_D_N_S_B_L_-_o_n
_D_N_S_B_L_-_o_f_f
honor or ignore results of DNS blacklist checks
configured with --BB for dccm(8) and dccifd(8).
The default in the main whiteclnt file is equivalent to
_o_p_t_i_o_n _l_o_g_-_n_o_r_m_a_l
_o_p_t_i_o_n _d_c_c_-_o_n
_o_p_t_i_o_n _g_r_e_y_l_i_s_t_-_o_n
_o_p_t_i_o_n _g_r_e_y_l_i_s_t_-_l_o_g_-_o_n
_o_p_t_i_o_n _D_N_S_B_L_-_o_f_f
_c_o_u_n_t is null and assumed to be the same as on the previous line or
one of
_M_A_N_Y indicating millions of targets have received messages
with that checksum.
_O_K if the message is OK.
_O_K_2 if it is "half OK." Two _O_K_2 checksums associated
with a message are generally equivalent to an _O_K.
_h_o_s_t_n_a_m_e is an
address IPv4 or IPv6.
block of 2 to 1024 IPv4 or IPv6 addresses in the stan-
dard form xxx.yyy.zzz.www/mm with mm limited for
server whitelists to 16 for IPv4 or 112 for IPv6.
name that will be converted to one or more IP
addresses.
_d_e_s_t_-_m_a_i_l_b_o_x is an RFC 821 address or a local user name.
_8_2_1_-_p_a_t_h is an RFC 821 address.
_8_2_2_-_m_a_i_l_b_o_x is an RFC 822 address with optional name.
_h_e_a_d_e_r 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 sendmail resolved host name from the _8_2_1_-_p_a_t_h in the mes-
sage's _8_2_1_-_p_a_t_h.
_h_e_x___t_y_p_e is the string _h_e_x followed by a blank and one of the pre-
ceding checksum types or _b_o_d_y, _F_u_z_1, or _F_u_z_2.
_h_e_x___c_k_s_u_m is a string of four hexadecimal numbers obtained from a
DCC log file.
A DCC server never shares or _f_l_o_o_d_s 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.
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 white-listing, 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
address of a white-listed mailing list.
Envelope and header _F_r_o_m values can be forged, so whitelist entries for
their checksums are not completely reliable.
Checksums of _e_n_v___T_o values are never sent to DCC servers. They are valid
in only _w_h_i_t_e_c_l_n_t files and used only by dccm(8), dccifd(8), and other
DCC clients with access to the envelope _R_c_p_t _T_o value. They are another
mechanism used by DCC clients to protect the privacy of some mail.
GGrreeyylliissttss
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 Distributed Checksum Clearinghouses.
See http://projects.puremagic.com/greylisting/
PPrriivvaaccyy
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.
Additional privacy protections are provided by the thresholds at which
DCC servers exchange or _f_l_o_o_d reports. These thresholds are primarily
intended to reduce the traffic among DCC servers using the observation
that the vast majority of messages are sent to a handful of addressees
and so are useless to other DCC servers. A DCC server's peer reporting
thresholds also ensure that checksums shared with peer DCC servers are
"bulk" and so intrinsically not private.
SSeeccuurriittyy
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
delivery 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
numbers. Since all DCC users _m_u_s_t "white-list" all sources of legitimate
bulk mail, this is also not a concern. Such security risks should be
addressed, 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 clearinghouse server with packets supposedly from
subscribers or non-subscribers. DCC servers defend against that attack
by rate-limit requests from non-subscribers.
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 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 cryptographically sign answers
to unauthenticated clients with bits from the corresponding queries.
This protects against attackers that do not have access 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
secret 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 expensive but no more secure than a file of cleartext passwords.
Asymmetric systems such as that used in UNIX allow one party to not know
the secrets, but they must be and are designed to be computationally
expensive when used in applications like the DCC that involve thousands
or more authentication checks per second. Moreover, because of "dictio-
nary attacks," asymmetric systems are now little more secure than keeping
passwords in cleartext. An adversary can compare the hash values of com-
binations of common words with /etc/passwd hash values to look for bad
passwords. Worse, by the nature of a client/server protocol like that
used in the DCC or a UNIX shell login, 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 like that
used by UNIX.
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.
RReelliiaabbiilliittyy
It is better to fail to filter unsolicited bulk mail than to fail to
deliver legitimate mail, so DCC clients fail in the direction of assuming
that mail is legitimate or even white-listed.
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
retransmit. 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.
CClliieenntt aanndd SSeerrvveerr--IIDDss
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 _i_d_s 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 digitally
sign their messages to servers with the first password associated with
their client-ID. Servers treat messages with signatures that match nei-
ther of the passwords for the client-ID in their own _i_d_s file as if the
client had used the anonymous ID.
Each server has a unique _s_e_r_v_e_r_-_I_D less than 32768. Servers use their
IDs to identify checksums that they _f_l_o_o_d 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
reports can be received in the local _/_v_a_r_/_d_c_c_/_f_l_o_d file described in
dccd(8). However, server-IDs can be mapped during flooding between inde-
pendent DCC organizations.
_P_a_s_s_w_d_-_I_D_s are server-IDs that should not be assigned to servers but used
to specify passwords used in the inter-server flooding protocol. They
are used in publicly readable configuration files to specify passwords in
private files.
The client identified by a _c_l_i_e_n_t_-_I_D 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
reports of checksums. The inter-server flooding mechanism requires coop-
erating DCC servers to maintain reasonable clocks ticking in UTC.
Clients include timestamps in their requests, but as long as their time-
stamps are unlikely to be repeated, they need not be very accurate.
IInnssttaallllaattiioonn CCoonnssiiddeerraattiioonnss
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,
often _/_v_a_r_/_d_c_c. Distinct DCC servers can run on a single computer, pro-
vided 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.txt or INSTALL.html file.
CClliieenntt IInnssttaallllaattiioonn
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
administrative 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
release privileges except when they need them to read or write files in
the DCC home directory. A DCC home directory should be created, often in
_/_v_a_r_/_d_c_c. 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 hostname, port num-
ber, and a _c_l_i_e_n_t_-_I_D and corresponding password. No client-IDs or pass-
words are needed touse DCC servers that allow anonymous clients. Use the
_l_o_a_d or _a_d_d commands of cdcc to create a _m_a_p 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 _h_o_m_e_d_i_r_/_d_c_c___c_o_n_f file and the _m_i_s_c_/_r_c_D_C_C
script in the DCC source. The procmail DCCM interface, dccproc(8), can
be run manually or by a procmailrc(5) rule.
SSeerrvveerr IInnssttaallllaattiioonn
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
addresses, but it requires other files. One is the _i_d_s file of client-
IDs, server-IDs, and corresponding passwords. Another is a _f_l_o_d 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 _m_i_s_c_/_r_c_D_C_C and _m_i_s_c_/_s_t_a_r_t_-_d_c_c_d 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.
SSEEEE AALLSSOO
cdcc(8), dbclean(8), dcc(8), dccd(8), dccifd(8), dccm(8), dccproc(8),
dblist(8), dccsight(8), sendmail(8).
HHIISSTTOORRYY
The Distributed Checksum Clearinghouse is based on an idea of Paul Vixie
with code designed and written at Rhyolite Software starting in 2000.
This describes version 1.2.74.
FreeBSD 4.9 March 20, 2005 FreeBSD 4.9
|
