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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>dccd.8</TITLE>
<META http-equiv="Content-Style-Type" content="text/css">
<STYLE type="text/css">
BODY {background-color:white; color:black}
</STYLE>
</HEAD>
<BODY>
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->
dccd(SMM) LOCAL dccd(SMM)
</PRE>
<H2><A NAME="NAME">NAME</A></H2><PRE>
<B>dccd</B> -- Distributed Checksum Clearinghouse Daemon
</PRE>
<H2><A NAME="SYNOPSIS">SYNOPSIS</A></H2><PRE>
<B>dccd</B> [<B>-64dVbfFQ</B>] <B>-i</B> <I>server-ID</I> [<B>-n</B> <I>brand</I>] [<B>-h</B> <I>homedir</I>]
[<B>-a</B> [<I>server-addr</I>][<I>,server-port</I>]] [<B>-I</B> <I>host-ID</I>] [<B>-q</B> <I>qsize</I>]
[<B>-G</B> [<I>on,</I>][<I>weak-body,</I>][<I>weak-IP,</I>][<I>embargo</I>][<I>,wait</I>][<I>,white</I>]]
[<B>-t</B> [<I>type</I>]<I>,threshold</I>] [<B>-K</B> [<I>no-</I>]<I>type</I>] [<B>-T</B> <I>tracemode</I>]
[<B>-u</B> <I>anon-delay</I>[<I>*inflate</I>]] [<B>-C</B> <I>dbclean</I>] [<B>-L</B> <I>ltype,facility.level</I>]
[<B>-R</B> [<I>RL</I><B>_</B><I>SUB</I>],[<I>RL</I><B>_</B><I>ANON</I>],[<I>RL</I><B>_</B><I>ALL</I><B>_</B><I>ANON</I>],[<I>RL</I><B>_</B><I>BUGS</I>]]
</PRE>
<H2><A NAME="DESCRIPTION">DESCRIPTION</A></H2><PRE>
<B>Dccd</B> receives reports of checksums related to mail received by DCC
clients and queries about the total number of reports of particular
checksums. A DCC server never receives mail, address, headers, or other
information from clients, but only cryptographically secure checksums of
such information. A DCC server cannot determine the text or other infor-
mation that corresponds to the checksums it receives. It only acts as a
clearinghouse of total counts of checksums computed by clients.
Each DCC server or close cluster of DCC servers is identified by a
numeric <I>server-ID</I>. Each DCC client is identified by a <I>client-ID</I>, either
explicitly listed in the <I>ids</I> file or the special anonymous client-ID.
Many computers are expected to share a single <I>client-ID</I>. A <I>server-ID</I> is
less than 32768 while a <I>client-ID</I> is between 32768 and 16777215. DCC
server-IDs need be known only to DCC servers and the people running them.
The passwords associated with DCC server-IDs should be protected, because
DCC servers listen to commands authenticated with server-IDs and their
associated passwords. Each client that does not use the anonymous ID
must know the client-ID and password used by each of its servers. A sin-
gle client computer can use different passwords with different server
computers. See the <I>ids</I> file.
A whitelist of known good (or bad) sources of email prevents legitimate
mailing lists from being seen as unsolicited bulk email by DCC clients.
The whitelist used by a DCC server is built into the database when old
entries are removed by <B><A HREF="dbclean.html">dbclean(8)</A></B>. Each DCC client has its own, local
whitelist, and in general, whitelists work better in DCC clients than
servers.
The effectiveness of a Distributed Checksum Clearinghouse increases as
the number of subscribers increases. Flooding reports of checksums among
DCC servers increases the effective number of subscribers to each server.
Each <B>dccd</B> daemon tries to maintain TCP/IP connections to the other
servers listed in the <I>flod</I> file, and send them reports containing check-
sums with total counts exceeding thresholds. Changes in the <I>flod</I> file
are noticed automatically within minutes.
Controls on report flooding are specified in the <I>flod</I> file. Each line
specifies a hostname and port number to which reports should be flooded,
a server-ID to identify and authenticate the output stream, a server-ID
to identify and authenticate an input stream from the same server, and
flags with each ID. The ability to delete reports of checksums is handy,
but could be abused. If <I>del</I> is not present among the <I>in-opts</I> options for
the incoming ID, incoming delete requests are logged and then ignored.
Floods from DCC "brands" that count only mail to "spam traps" and whose
servers use the <B>-Q</B> option to count extremely "bulk" mail should be marked
with <I>traps</I>. They can be seen as counting millions of targets, so the
<I>traps</I> flag on their <I>flod</I> file entry changes their incoming flooded
reports counts to "many."
<B>Dccd</B> automatically checks its <I>flod</I> and <I>ids</I> files periodically. <B><A HREF="cdcc.html">Cdcc(8)</A></B>
has the server commands <B>new ids</B> and <B>flood check</B> to tell <B>dccd</B> to check
those two files immediately. Both files are also checked for changes in
response to the SIGHUP signal.
<A NAME="OPTIONS"><B>OPTIONS</B></A>
The following options are available:
<A NAME="OPTION-6"><B>-6</B></A> enable IPv6. The default is equivalent to <B>-4</B>. See also the IPv4
and IPv6 options in the <I>flod</I> file.
<A NAME="OPTION-4"><B>-4</B></A> disable IPv6. See also <B>-6</B>.
<A NAME="OPTION-d"><B>-d</B></A> enables debugging output. Additional <B>-d</B> options increase the number
of messages.
<A NAME="OPTION-V"><B>-V</B></A> displays the version of the DCC server daemon.
<A NAME="OPTION-b"><B>-b</B></A> causes the server to not detach itself from the controlling tty or
put itself into the background.
<A NAME="OPTION-F"><B>-F</B></A> uses read() and write() instead of mmap() in some cases to access
the DCC database. It is never the default.
<A NAME="OPTION-f"><B>-f</B></A> turns off <B>-F</B>.
<A NAME="OPTION-Q"><B>-Q</B></A> causes the server to treat reports of checksums as queries except
from DCC clients marked trusted in the <I>ids</I> file with <I>rpt-ok</I>. See <B>-u</B>
to turn off access by anonymous or unauthenticated clients
<A NAME="OPTION-i"><B>-i</B></A> <I>server-ID</I>
specifies the ID of this DCC server. Each server identifies itself
as responsible for checksums that it forwards to other servers.
<A NAME="OPTION-n"><B>-n</B></A> <I>brand</I>
is an arbitrary string of letters and numbers that identifies the
organization running the DCC server. The brand is required, and
appears in the SMTP <I>X-DCC</I> headers generated by the DCC.
<A NAME="OPTION-h"><B>-h</B></A> <I>homedir</I>
overrides the default DCC home directory, which is often <I>/var/dcc</I>.
<A NAME="OPTION-a"><B>-a</B></A> [<I>server-addr</I>][<I>,server-port</I>]
adds an hostname or IP address to the list of local IP addresses
that the server answers. Multiple <B>-a</B> options can be used to specify
a subset of the available network interfaces or to use more than one
port number. The default is to listen on all local IP addresses.
It can be useful to list some or all of the IP addresses of multi-
homed hosts to deal with local or remote firewalls. By default
<I>server-port</I> is 6277 for DCC servers and 6276 for Greylist servers.
It is the UDP port at which DCC requests are received and the TCP
port for incoming floods of reports.
If <I>server-addr</I> is absent and if the <B>getifaddrs(8)</B> function is sup-
ported, separate UDP sockets are bound to each configured network
interface so that each DCC clients receives replies from the IP
addresses to which corresponding request are sent. If <B>dccd</B> is
started before all network interfaces are turned on or there are
interfaces that are turned on and off or change their addresses such
as PPP interfaces, then the special string <I>@</I> should be used to tell
<B>dccd</B> to bind to an IN_ADDRANY UDP socket.
Outgoing TCP connections to flood checksum reports to other DCC
servers used the IP address of a single <B>-a</B> option, but only if there
is single option. Note that this means that <B>-a -127.0.0.1</B> breaks
flooding, often with "Invalid argument" messages. See also the <I>flod</I>
file.
<A NAME="OPTION-I"><B>-I</B></A> <I>host-ID</I>
changes the server's globally unique identity from the default value
consisting of the first 16 characters of the host name. <I>Host-ID</I> is
a string of up to 16 characters to be used instead of the first 16
characters of the system's hostname.
<A NAME="OPTION-q"><B>-q</B></A> <I>qsize</I>
specifies the maximum size of the queue of requests from anonymous
or unauthenticated clients. The default value is the maximum DCC
RTT in seconds times 200 or 1000.
<A NAME="OPTION-t"><B>-t</B></A> [<I>type</I>]<I>,threshold</I>
sets the threshold below which checksum reports are not sent or
flooded to peer DCC servers. Checksums whose total counts are less
than to the number <I>threshold</I> are not flooded. If <I>threshold</I> is the
string "many," a value of millions is understood. It must be at
least 10. If <I>type</I> is absent, only the thresholds for the body
checksums are set. The thresholds built into <B>dccd</B> for the body
checksums, <I>Body</I>, <I>Fuz1</I>, and <I>Fuz2</I> are 20. The thresholds for the
other checksums are so high by default that by themselves they can
never cause reports to be flooded. The script commonly used to
start <B>dccd</B> sets the body thresholds to one third of <I>DCCM</I><B>_</B><I>REJECT</I><B>_</B><I>AT</I>
in the dcc_conf file but no less than 10 or more than 20. That is
the rejection threshold for <B><A HREF="dccm.html">dccm(8)</A></B>,
This threshold has no direct effect on which checksums are marked
"bulk" by DCC clients. Instead, it allows cooperating DCC servers
to share only the checksums of bulk mail and reduce inter-server
communications. The thresholds should be larger than the number of
addressees of typical private email but not much larger, because
reports of checksums that total less than their thresholds can be
flooded as many extra times as there are other thresholds.
Reports containing any checksums marked "OK or "OK2" are not sent to
other servers. This reduces the bandwidth needed for the inter-
server flooding, the sizes of DCC database files, and helps protect
the privacy of email of clients of a DCC server.
<A NAME="OPTION-G"><B>-G</B></A> [<I>on,</I>][<I>weak-body,</I>][<I>weak-IP,</I>][<I>embargo</I>][<I>,wait</I>][<I>,white</I>]
changes <B>dccd</B> to a Greylist server for <B><A HREF="dccm.html">dccm(8)</A></B> or <B><A HREF="dccifd.html">dccifd(8)</A></B>.
Greylisting consists of temporarily rejecting or embargoing mail
from unfamiliar combinations of SMTP client IP address, SMTP enve-
lope sender, and SMTP envelope recipient. If the SMTP client per-
sists for <I>embargo</I> <I>seconds</I> and so is probably not an "open proxy,"
worm-infected personal computer, or other transient source of spam,
the triple of <I>(IP</I> <I>address,sender,recipient)</I> is added to a database
similar to the usual DCC database. If the SMTP client does not try
again after <I>embargo</I> seconds and before <I>wait</I> seconds after the first
attempt, the triple is forgotten. If the SMTP client persists past
the embargo, the triple is added to the database and becomes famil-
iar and the message is accepted. Familiar triples are remembered
for <I>white</I> seconds after the last accepted mail message. The triple
is forgotten if it is ever associated with unsolicited bulk email.
All three durations can be a number of minutes, hours, days, or
weeks followed by <I>MINUTES</I>, <I>M</I>, <I>HOURS</I>, <I>H</I>, <I>DAYS</I>, <I>D</I>, <I>WEEKS</I> or <I>W</I>. The
default is <B>-G</B> <I>270seconds,7days,63days</I>. The first duration or the
<I>embargo</I> should be longer than open proxies can linger retransmit-
ting. The second <I>wait</I> time should be as long as legitimate mail
servers persist in retransmitting to recognize embargoed messages
whose retransmissions were not received because of network or other
problems. The <I>white</I> time should be long enough to recognize and not
embargo messages from regular senders.
Usually the DCC greylist system requires that an almost identical
copy of the message be retransmitted during the <I>embargo</I>. If
<I>weak-body</I> is present, any message with the same triple of sender IP
address, sender mail address, and target mail address ends the
embargo.
If <I>weak-IP</I> is present, all mail from an SMTP client at an IP address
is accept after any message from the same IP address has been
accepted.
Unlike DCC checksums, the contents of greylist databases are private
and do not benefit from broad sharing. However, large installations
can use more two or more greylist servers flooding triples among
themselves. Flooding among greylist servers is controlled by the
<I>grey</I><B>_</B><I>flod</I> file.
<I>Note:</I> All greylist cooperating or flooding greylist servers must use
the same <B>-G</B> values.
Clients of greylist servers cannot be anonymous and must have
client-IDs and passwords assigned in the <I>ids</I> file.
White- and blacklists are honored by the DCC clients. White-listed
messages are embargoed or checked with a greylist server. The
greylist triples of blacklisted messages, messages whose DCC counts
make them spam, and other messages known to be spam are sent to a
greylist server to be removed from the greylist database and cause
an embargo on the next messages with those triples.
Messages whose checksums match greylist server whitelists are not
embargoed and the checksums of their triples are not added to the
greylist database.
The target counts of embargoed messages are reported to the DCC net-
work to improve the detection of bulk mail.
<A NAME="OPTION-K"><B>-K</B></A> [<I>no-</I>]<I>type</I>
marks checksums of <I>type</I> (not) be "kept" or counted in the database
unless they appear in the whitelist. The default is equivalent to
<B>-K</B> <I>no-all</I> <B>-K</B> <I>Body</I> <B>-K</B> <I>Fuz1</I> <B>-K</B> <I>Fuz2</I> to count only the body checksums.
<A NAME="OPTION-T"><B>-T</B></A> <I>tracemode</I>
causes the server to trace or record some operations. <I>tracemode</I>
must be one of the following:
<I>ALL</I> all tracing
<I>ADMN</I> administrative requests from the control program, <B><A HREF="cdcc.html">cdcc(8)</A></B>
<I>ANON</I> errors by anonymous clients
<I>CLNT</I> errors by authenticated clients
<I>RLIM</I> rate-limited messages
<I>QUERY</I> all queries and reports
<I>RIDC</I> some messages concerning the report-ID cache that is used
to detect duplicate reports from clients
<I>FLOOD</I> messages about inter-server flooding
<I>IDS</I> unknown server-IDs in flooded reports
<I>BL</I> requests from clients with IP addresses in the <I>blacklist</I>
file.
The default is <I>ANON</I> <I>CLNT</I>.
<A NAME="OPTION-u"><B>-u</B></A> <I>anon-delay</I>[<I>*inflate</I>]
changes the number of milliseconds anonymous or unauthenticated
clients must wait for answers to their queries and reports. The
purpose of this delay is to discourage anonymous clients.. The
<I>anon-delay</I> is multiplied by 1 plus the number of recent anonymous
requests from an IP address divided by the <I>inflate</I> value.
The string <I>FOREVER</I> turns off all anonymous or unauthenticated access
not only for checksum queries and reports but also <B><A HREF="cdcc.html">cdcc(8)</A> stats</B>
requests. A missing value for <I>inflate</I> turns off inflation.
The default value is <I>50,none</I>, except when <B>-G</B> is used in which case
<I>FOREVER</I> is assumed and required.
<A NAME="OPTION-C"><B>-C</B></A> <I>dbclean</I>
changes the default name or path of the program used to rebuild the
hash table when it becomes too full. The default value is
<I>libexec/dbclean</I> in the DCC home directory. The value can include
arguments as in <I>-C</I> <I>'$DCC</I><B>_</B><I>LIBEXEC/dbclean</I> <I>-F'</I>.
<A NAME="OPTION-L"><B>-L</B></A> <I>ltype,facility.level</I>
specifies how messages should be logged. <I>Ltype</I> must be <I>error</I> or
<I>info</I> to indicate which of the two types of messages are being con-
trolled. <I>Level</I> must be a <B>syslog(3)</B> level among <I>EMERG</I>, <I>ALERT</I>, <I>CRIT</I>,
<I>ERR</I>, <I>WARNING</I>, <I>NOTICE</I>, <I>INFO</I>, and <I>DEBUG</I>. <I>Facility</I> must be among <I>AUTH</I>,
<I>AUTHPRIV</I>, <I>CRON</I>, <I>DAEMON</I>, <I>FTP</I>, <I>KERN</I>, <I>LPR</I>, <I>MAIL</I>, <I>NEWS</I>, <I>USER</I>, <I>UUCP</I>, and
<I>LOCAL0</I> through <I>LOCAL7</I>. The default is equivalent to
-L info,MAIL.NOTICE -L error,MAIL.ERR
<A NAME="OPTION-R"><B>-R</B></A> [<I>RL</I><B>_</B><I>SUB</I>],[<I>RL</I><B>_</B><I>ANON</I>],[<I>RL</I><B>_</B><I>ALL</I><B>_</B><I>ANON</I>],[<I>RL</I><B>_</B><I>BUGS</I>]
sets the four categories of rate-limits. <I>RL</I><B>_</B><I>SUB</I> limits the number
of DCC transactions per second from subscribers or DCC clients with
known client-IDs and passwords. This limit applies to each IP
address independently.
<I>RL</I><B>_</B><I>ANON</I> limits the number of DCC transactions per second from anony-
mous DCC clients. This limit applies to each IP address indepen-
dently. It is better to use <B>-u</B> than to change this value to exclude
anonymous clients.
<I>RL</I><B>_</B><I>ALL</I><B>_</B><I>ANON</I> limits the number of DCC transactions per second from
all anonymous DCC clients. Its default value is set by the compile-
time value of DCCD_RL_ALL_ANON. This limit applies to all anonymous
clients as a group, regardless of their IP addresses.
<I>RL</I><B>_</B><I>BUGS</I> limits the number of complaints or error messages per second
for all anonymous DCC clients as a group as well as for each DCC
client by IP address.
The default is equivalent to <B>-R</B> <I>200,50,200,0.1</I>
</PRE>
<H2><A NAME="FILES">FILES</A></H2><PRE>
<A NAME="FILE-/var/dcc">/var/dcc</A> is the DCC home directory containing data and control files.
<A NAME="FILE-dcc_db">dcc_db</A> is the database of mail checksums.
<A NAME="FILE-dcc_db.hash">dcc_db.hash</A> is the mail checksum database hash table.
<A NAME="FILE-grey_db">grey_db</A> is the database of greylist checksums.
<A NAME="FILE-grey_db.hash">grey_db.hash</A> is the greylist database hash table.
<A NAME="FILE-flod">flod</A> contains lines controlling DCC flooding of the form:
<I>host</I>[<I>,port</I>][<I>;src</I>] <I>rem-ID</I> [<I>passwd-ID</I> [<I>o-opts</I> [<I>i-opts</I>]]]
where absent optional values are signaled with "-" and
<I>host</I> is the IP address or name of a DCC server.
<I>port</I> is the name or number of the UDP port used by the server.
<I>src</I> is the IP address or host name from which the outgoing
connection should come.
<I>rem-id</I> is the server-ID of the remote DCC server.
<I>passwd-ID</I> is a server-ID that is not assigned to a server, but
whose first password is used to sign checksum reports sent
to the remote system. Either of its passwords are
required with incoming reports. If it is absent or "-",
outgoing floods are signed with the first password of the
local server in the <I>ids</I> file and incoming floods must be
signed with either password of the remote server-ID.
<I>i-opts</I> and <I>o-opts</I> are comma-separated lists of
<I>off</I> turns off flooding to the remote or local system.
<I>traps</I> indicates that the remote sending or local receiv-
ing system has only "spam traps."
<I>no-del</I> says checksum delete requests are refused by the
remote or local server and so turns off sending or
accepting delete requests, respectively. By default,
delete requests are not sent to remote servers and
refused in incoming floods.
<I>del</I> says delete requests are accepted by the remote or
local server.
<I>no-log-del</I> turns off logging of incoming requests to
delete checksums.
<I>passive</I> is used to tell a server outside a firewall to
expect a peer inside to create both of the pair of
input and output TCP connections used for flooding.
The peer inside the firewall should use <I>SOCKS</I> on its
<I>flod</I> file entry for this system.
<I>SOCKS</I> is used to tell a server inside a firewall that it
should create both of the TCP connections used for
flooding and that SOCKS protocol should be used. The
peer outside the firewall should use <I>passive</I> on its
<I>flod</I> file entry for this system.
<I>ID1->ID2</I> converts server-ID <I>ID1</I> in flooded reports to
server-ID <I>ID2</I>. Either <I>ID1</I> or <I>ID2</I> may be the string
`self' to specify the server's own ID. <I>ID1</I> can be
the string `all' to specify all server-IDs or a pair
of server-IDs separated by a dash to specify an
inclusive range. <I>ID2</I> can be the string `ok' to send
or receive reports without translation or the string
`reject' to not send outgoing or refuse incoming
reports. Only the first matching conversion is
applied. For example, when `self->ok,all->reject' is
applied to a locally generated report, the first con-
version is applied and the second is ignored.
<I>leaf=path-len</I> does not send reports with paths longer
than <I>path-len</I> server-IDs.
<I>IPv4</I> overrides a <B>-6</B> setting for this flooding peer.
<I>IPv6</I> overrides the default or an explicit <B>-4</B> setting.
<I>vers</I> specifies the version of the DCC flooding protocol
used by the remote DCC server with a string such as
`version2'.
<A NAME="FILE-grey_flod">grey_flod</A> is the equivalent of <I>flod</I> <I>used</I> <I>by</I> <B>dccd</B> when it is a greylist
server.
<A NAME="FILE-flod.map">flod.map</A> is an automatically generated file in which <B>dccd</B> records its
progress sending or flooding reports to DCC peers.
<A NAME="FILE-grey_flod.map">grey_flod.map</A> is the equivalent of <I>flod.map</I> <I>used</I> <I>by</I> <B>dccd</B> when it is a
greylist server.
<A NAME="FILE-ids">ids</A> contains the IDs and passwords known by the DCC server. An <I>ids</I>
file that can be read by others cannot be used. It contains
blank lines, comments starting with "#" and lines of the form:
<I>id</I>[<I>,rpt-ok</I>][<I>,delay=ms</I>[<I>*inflate</I>]] <I>passwd1</I> [<I>passwd2</I>]
where
<I>id</I> is a DCC <I>client-ID</I> or <I>server-ID</I>.
<I>Rpt-ok</I> if present overrides <B>-Q</B> by saying that this client is
trusted to report only checksums for unsolicited bulk
mail.
<I>delay=ms</I>[<I>*inflate</I>] delays answers to systems using the client
<I>id</I>. The <I>delay</I> in milliseconds is multiplied by 1 plus the
number of recent requests from an IP address using <I>id</I>
divided by the <I>inflate</I> value. See <B>-U</B>.
<I>passwd1</I> is the password currently used by clients with identi-
fier <I>id</I>. It is a 1 to 32 character string that does not
contain blank, tab, newline or carriage return characters.
<I>passwd2</I> is the optional next password that those clients will
use. A DCC server accepts either password if both are
present in the file.
Both passwords can be absent if the entry not used except to
tell <B>dccd</B> that server-IDs in the flooded reports are valid.
The string <I>unknown</I> is equivalent to the null string.
<A NAME="FILE-whitelist">whitelist</A> contains the DCC server whitelist. It is not used directly but
is loaded into the database when <B><A HREF="dbclean.html">dbclean(8)</A></B> is run.
<A NAME="FILE-grey_whitelist">grey_whitelist</A> contains the greylist server whitelist. It is not used
directly but is loaded into the database when <B><A HREF="dbclean.html">dbclean(8)</A></B> is run
with <B>-G</B>.
<A NAME="FILE-blacklist">blacklist</A> if present, contains a list of IP addresses and blocks of IP
addresses DCC clients that are ignored. Each line in the file
should be blank, a comment starting with '#', an IP address, or
a block of IP addresses in the xxx.xxx.xxx.xxx/yy form.
Changes to the file are automatically noticed and acted upon
within a few minutes. Addresses can be followed with comments
starting with '#'. This mechanism is intended for no more than
a few dozen blocks of addresses.
</PRE>
<H2><A NAME="EXAMPLES">EXAMPLES</A></H2><PRE>
<B>dccd</B> is usually started with other system daemons with something like the
<A NAME="FILE-script">script</A> misc/start-dccd. It uses values in the file dcc_conf in the DCC
<A NAME="FILE-home">home</A> directory to start the server.
<A NAME="FILE-The">The</A> following is useful for cleanly stopping the daemon:
cdcc 'id 100; stop'
<A NAME="FILE-Again">Again</A>, the ID of the local server must be used instead of "100."
<A NAME="FILE-Unless">Unless</A> old reports are removed from the database, it grows too large.
<B><A HREF="dbclean.html">dbclean(8)</A></B> should be run daily with script like /var/dcc/libexec/cron-
<A NAME="FILE-dccd.">dccd.</A>
</PRE>
<H2><A NAME="SEE-ALSO">SEE ALSO</A></H2><PRE>
<B><A HREF="cdcc.html">cdcc(8)</A></B>, <B><A HREF="dcc.html">dcc(8)</A></B>, <B><A HREF="dbclean.html">dbclean(8)</A></B>, <B><A HREF="dblist.html">dblist(8)</A></B>, <B><A HREF="dccifd.html">dccifd(8)</A></B>, <B><A HREF="dccm.html">dccm(8)</A></B>, <B><A HREF="dccproc.html">dccproc(8)</A></B>.
<B><A HREF="dccsight.html">dccsight(8)</A></B>,
</PRE>
<H2><A NAME="HISTORY">HISTORY</A></H2><PRE>
<B>dccd</B> is based on an idea from Paul Vixie. It was designed and written at
<A NAME="FILE-Rhyolite">Rhyolite</A> Software starting in 2000. This document describes version
<A NAME="FILE-1.2.74.">1.2.74.</A>
FreeBSD 4.9 March 20, 2005 FreeBSD 4.9
</PRE>
<HR>
<ADDRESS>
Man(1) output converted with
<a href="http://www.oac.uci.edu/indiv/ehood/man2html.html">man2html</a>
modified for the DCC $Date 2001/04/29 03:22:18 $
</ADDRESS>
</BODY>
</HTML>
|
