comparison dccd.0 @ 0:c7f6b056b673

First import of vendor version
author Peter Gervai <grin@grin.hu>
date Tue, 10 Mar 2009 13:49:58 +0100
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:c7f6b056b673
1 dccd(8) Distributed Checksum Clearinghouse dccd(8)
2
3 NNAAMMEE
4 ddccccdd -- Distributed Checksum Clearinghouse Daemon
5
6 SSYYNNOOPPSSIISS
7 ddccccdd [--6644ddVVbbffFFQQ] --ii _s_e_r_v_e_r_-_I_D [--nn _b_r_a_n_d] [--hh _h_o_m_e_d_i_r] --II [_h_o_s_t_-_I_D][_,_u_s_e_r]
8 [--aa [_s_e_r_v_e_r_-_a_d_d_r][_,_s_e_r_v_e_r_-_p_o_r_t]] [--qq _q_s_i_z_e]
9 [--GG [_o_n_,][_w_e_a_k_-_b_o_d_y_,][_w_e_a_k_-_I_P_,][_e_m_b_a_r_g_o][_,_w_i_n_d_o_w][_,_w_h_i_t_e]]
10 [--WW [_r_a_t_e][_,_c_h_g][_,_d_b_s_i_z_e]] [--KK [_n_o_-]_t_y_p_e] [--TT _t_r_a_c_e_m_o_d_e]
11 [--uu _a_n_o_n_-_d_e_l_a_y[_*_i_n_f_l_a_t_e]] [--CC _d_b_c_l_e_a_n] [--LL _l_t_y_p_e_,_f_a_c_i_l_i_t_y_._l_e_v_e_l]
12 [--RR [_R_L___S_U_B],[_R_L___A_N_O_N],[_R_L___A_L_L___A_N_O_N],[_R_L___B_U_G_S]]
13
14 DDEESSCCRRIIPPTTIIOONN
15 DDccccdd receives reports of checksums related to mail received by DCC
16 clients and queries about the total number of reports of particular
17 checksums. A DCC server never receives mail, address, headers, or other
18 information from clients, but only cryptographically secure checksums of
19 such information. A DCC server cannot determine the text or other infor-
20 mation that corresponds to the checksums it receives. It only acts as a
21 clearinghouse of total counts of checksums computed by clients.
22
23 Each DCC server or close cluster of DCC servers is identified by a
24 numeric _s_e_r_v_e_r_-_I_D. Each DCC client is identified by a _c_l_i_e_n_t_-_I_D, either
25 explicitly listed in the _i_d_s file or the special anonymous client-ID.
26 Many computers are expected to share a single _c_l_i_e_n_t_-_I_D. A _s_e_r_v_e_r_-_I_D is
27 less than 32768 while a _c_l_i_e_n_t_-_I_D is between 32768 and 16777215. DCC
28 server-IDs need be known only to DCC servers and the people running them.
29 The passwords associated with DCC server-IDs should be protected, because
30 DCC servers listen to commands authenticated with server-IDs and their
31 associated passwords. Each client that does not use the anonymous ID
32 must know the client-ID and password used by each of its servers. A sin-
33 gle client computer can use different passwords with different server
34 computers. See the _i_d_s file.
35
36 A whitelist of known good (or bad) sources of email prevents legitimate
37 mailing lists from being seen as unsolicited bulk email by DCC clients.
38 The whitelist used by a DCC server is built into the database when old
39 entries are removed by dbclean(8). Each DCC client has its own, local
40 whitelist, and in general, whitelists work better in DCC clients than
41 servers.
42
43 The effectiveness of a Distributed Checksum Clearinghouse increases as
44 the number of subscribers increases. Flooding reports of checksums among
45 DCC servers increases the effective number of subscribers to each server.
46 Each ddccccdd daemon tries to maintain TCP/IP connections to the other
47 servers listed in the _f_l_o_d file, and send them reports containing check-
48 sums with total counts exceeding thresholds. Changes in the _f_l_o_d file
49 are noticed automatically within minutes.
50
51 Controls on report flooding are specified in the _f_l_o_d file. Each line
52 specifies a hostname and port number to which reports should be flooded,
53 a server-ID to identify and authenticate the output stream, a server-ID
54 to identify and authenticate an input stream from the same server, and
55 flags with each ID. The ability to delete reports of checksums is handy,
56 but could be abused. If _d_e_l is not present among the _i_n_-_o_p_t_s options for
57 the incoming ID, incoming delete requests are logged and then ignored.
58 Floods from DCC "brands" that count only mail to spam traps and whose
59 servers use the --QQ option to count extremely bulk mail should be marked
60 with _t_r_a_p_s. They can be seen as counting millions of targets, so the
61 _t_r_a_p_s flag on their _f_l_o_d file entry changes their incoming flooded
62 reports counts to _m_a_n_y_.
63
64 DDccccdd automatically checks its _f_l_o_d and _i_d_s files periodically. Cdcc(8)
65 has the commands nneeww iiddss and fflloooodd cchheecckk to tell ddccccdd to check those two
66 files immediately. Both files are also checked for changes after the
67 SIGHUP signal.
68
69 OOPPTTIIOONNSS
70 The following options are available:
71
72 --66 enable IPv6. The default is equivalent to --44. See also the IPv4
73 and IPv6 options in the _f_l_o_d file description below and the _I_P_v_6 _o_n
74 cdcc(8) command.
75
76 --44 disable IPv6. See also --66.
77
78 --dd enables debugging output. Additional --dd options increase the number
79 of messages.
80
81 --VV displays the version of the DCC server daemon.
82
83 --bb causes the server to not detach itself from the controlling tty or
84 put itself into the background.
85
86 --FF uses write() instead of mmap() in some cases to modify the DCC data-
87 base. It is the default on Solaris.
88
89 --ff turns off --FF.
90
91 --QQ causes the server to treat reports of checksums as queries except
92 from DCC clients marked trusted in the _i_d_s file with _r_p_t_-_o_k. See --uu
93 to turn off access by anonymous or unauthenticated clients
94
95 --ii _s_e_r_v_e_r_-_I_D
96 specifies the ID of this DCC server. Each server identifies itself
97 as responsible for checksums that it forwards to other servers.
98
99 --nn _b_r_a_n_d
100 is an arbitrary string of letters and numbers that identifies the
101 organization running the DCC server. The brand is required, and
102 appears in the SMTP _X_-_D_C_C headers generated by the DCC.
103
104 --hh _h_o_m_e_d_i_r
105 overrides the default DCC home directory, _/_v_a_r_/_d_c_c.
106
107 --II [_h_o_s_t_-_I_D][_,_u_s_e_r]
108 changes the server's globally unique identity for flooding from the
109 default value consisting of the first 16 characters of the host
110 name. or changes the UID and GID of the process _H_o_s_t_-_I_D is a string
111 of up to 16 characters that replaces the first 16 characters of the
112 system's hostname in assertions of the server-ID that are flooded to
113 peers. _U_s_e_r must be valid user name.
114
115 --aa [_s_e_r_v_e_r_-_a_d_d_r][_,_s_e_r_v_e_r_-_p_o_r_t]
116 adds an hostname or IP address to the list of local IP addresses
117 that the server answers. Multiple --aa options can be used to specify
118 a subset of the available network interfaces or to use more than one
119 port number. The default without any --aa options is to listen on all
120 local IP addresses. It can be useful to list some of the IP
121 addresses of multi-homed hosts to deal with firewalls. By default
122 _s_e_r_v_e_r_-_p_o_r_t is 6277 for DCC servers and 6276 for Greylist servers.
123 It is the UDP port at which DCC requests are received and the TCP
124 port for incoming floods of reports.
125
126 If _s_e_r_v_e_r_-_a_d_d_r is absent and if the getifaddrs(8) function is sup-
127 ported, separate UDP sockets are bound to each configured network
128 interface so that each DCC clients receives replies from the IP
129 addresses to which corresponding request are sent. If ddccccdd is
130 started before all network interfaces are turned on or there are
131 interfaces that are turned on and off or change their addresses such
132 as PPP interfaces, then the special string _@ should be used to tell
133 ddccccdd to bind to an IN_ADDRANY UDP socket.
134
135 Outgoing TCP connections to flood checksum reports to other DCC
136 servers used the IP address of a single --aa option, but only if there
137 is single option that is not localhost. See also the _f_l_o_d file.
138
139 --qq _q_s_i_z_e
140 specifies the maximum size of the queue of requests from anonymous
141 or unauthenticated clients. The default value is the maximum DCC
142 RTT in seconds times 200 or 1000.
143
144 --GG [_o_n_,][_w_e_a_k_-_b_o_d_y_,][_w_e_a_k_-_I_P_,][_e_m_b_a_r_g_o][_,_w_i_n_d_o_w][_,_w_h_i_t_e]
145 changes ddccccdd to a Greylist server for dccm(8) or dccifd(8).
146 Greylisting consists of temporarily rejecting or embargoing mail
147 from unfamiliar combinations of SMTP client IP address, SMTP enve-
148 lope sender, and SMTP envelope recipient. If the SMTP client per-
149 sists for _e_m_b_a_r_g_o _s_e_c_o_n_d_s and so is probably not an open proxy,
150 worm-infected personal computer, or other transient source of spam,
151 the triple of _(_I_P _a_d_d_r_e_s_s_,_s_e_n_d_e_r_,_r_e_c_i_p_i_e_n_t_) is added to a database
152 similar to the usual DCC database. If the SMTP client does not try
153 again after _e_m_b_a_r_g_o seconds and before _w_i_n_d_o_w seconds after the
154 first attempt, the triple is forgotten. If the SMTP client persists
155 past the embargo, the triple is added to the database and becomes
156 familiar and the message is accepted. Familiar triples are remem-
157 bered for _w_h_i_t_e seconds after the last accepted mail message. The
158 triple is forgotten if it is ever associated with unsolicited bulk
159 email.
160
161 All three durations can be a number of minutes, hours, days, or
162 weeks followed by _M_I_N_U_T_E_S, _M, _H_O_U_R_S, _H, _D_A_Y_S, _D, _W_E_E_K_S or _W. The
163 default is --GG _2_7_0_s_e_c_o_n_d_s_,_7_d_a_y_s_,_6_3_d_a_y_s. The first duration or the
164 _e_m_b_a_r_g_o should be longer than open proxies can linger retransmit-
165 ting. The second _w_i_n_d_o_w time should be as long as legitimate mail
166 servers persist in retransmitting to recognize embargoed messages
167 whose retransmissions were not received because of network or other
168 problems. The _w_h_i_t_e time should be long enough to recognize and not
169 embargo messages from regular senders.
170
171 Usually the DCC greylist system requires that an almost identical
172 copy of the message be retransmitted during the _e_m_b_a_r_g_o. If
173 _w_e_a_k_-_b_o_d_y is present, any message with the same triple of sender IP
174 address, sender mail address, and target mail address ends the
175 embargo, even if the body of the message differs.
176
177 If _w_e_a_k_-_I_P is present, all mail from an SMTP client at an IP address
178 is accept after any message from the same IP address has been
179 accepted.
180
181 Unlike DCC checksums, the contents of greylist databases are private
182 and do not benefit from broad sharing. However, large installations
183 can use more two or more greylist servers flooding triples among
184 themselves. Flooding among greylist servers is controlled by the
185 _g_r_e_y___f_l_o_d file.
186
187 All greylist cooperating or flooding greylist servers _m_u_s_t use the
188 same --GG values.
189
190 Clients of greylist servers cannot be anonymous and must have
191 client-IDs and passwords assigned in the _i_d_s file. This implies
192 that cdcc commands directed to greylist servers must specify the
193 server-ID.
194
195 White- and blacklists are honored by the DCC clients. whitelisted
196 messages are embargoed or checked with a greylist server. The
197 greylist triples of blacklisted messages, messages whose DCC counts
198 make them spam, and other messages known to be spam are sent to a
199 greylist server to be removed from the greylist database and cause
200 an embargo on the next messages with those triples.
201
202 Messages whose checksums match greylist server whitelists are not
203 embargoed and the checksums of their triples are not added to the
204 greylist database.
205
206 The target counts of embargoed messages are reported to the DCC net-
207 work to improve the detection of bulk mail.
208
209 --WW [_r_a_t_e][_,_c_h_g][_,_d_b_s_i_z_e]
210 controls quick database cleaning. If the database is larger than
211 _d_b_s_i_z_e, it seems that the database has not recently and is not about
212 to be cleaned, ddccccdd is receiving fewer than _r_a_t_e requests per sec-
213 ond, and if telling DCC clients that the database is about to be
214 cleaned reduces that rate by _c_h_g%, then ddccccdd starts dbclean(8) for a
215 quick database cleaning. The cleaning is abandoned if it takes too
216 long. The default values are equivalent to --WW _1_._0_,_4_0_._0_,_R_S_S where
217 _R_S_S is the maximum dccd resident set displayed the system log by --dd
218 when ssttaarrttss.
219
220 --KK [_n_o_-]_t_y_p_e
221 marks checksums of _t_y_p_e (not) be kept or counted in the database
222 unless they appear in the whitelist. Explicit settings add to or
223 remove from the initial contents of the list, which is equivalent to
224 --KK _B_o_d_y --KK _F_u_z_1 --KK _F_u_z_2.
225
226 --TT _t_r_a_c_e_m_o_d_e
227 causes the server to trace or record some operations. _t_r_a_c_e_m_o_d_e
228 must be one of the following:
229 _A_D_M_N administrative requests from the control program, cdcc(8)
230 _A_N_O_N errors by anonymous clients
231 _C_L_N_T errors by authenticated clients
232 _R_L_I_M rate-limited messages
233 _Q_U_E_R_Y all queries and reports
234 _R_I_D_C some messages concerning the report-ID cache that is used
235 to detect duplicate reports from clients
236 _F_L_O_O_D messages about inter-server flooding connections
237 _F_L_O_O_D_2 messages about flooded reports
238 _I_D_S unknown server-IDs in flooded reports
239 _B_L requests from clients in the _b_l_a_c_k_l_i_s_t file.
240 _D_B odd database events including long chains of duplicate
241 checksums
242 _W_L_I_S_T reports of whitelisted checksums from authenticated, not
243 anonymous DCC clients
244 The default is _A_N_O_N _C_L_N_T.
245
246 --uu _a_n_o_n_-_d_e_l_a_y[_*_i_n_f_l_a_t_e]
247 changes the number of milliseconds anonymous or unauthenticated
248 clients must wait for answers to their queries and reports. The
249 purpose of this delay is to discourage large anonymous clients. The
250 _a_n_o_n_-_d_e_l_a_y is multiplied by 1 plus the number of recent anonymous
251 requests from an IP address divided by the _i_n_f_l_a_t_e value.
252
253 The string _F_O_R_E_V_E_R turns off all anonymous or unauthenticated access
254 not only for checksum queries and reports but also cdcc(8) ssttaattss
255 requests. A missing value for _i_n_f_l_a_t_e turns off inflation.
256
257 The default value is _5_0_,_n_o_n_e, except when --GG is used in which case
258 _F_O_R_E_V_E_R is assumed and required.
259
260 --CC _d_b_c_l_e_a_n
261 changes the default name or path of the program used to rebuild the
262 hash table when it becomes too full. The default value is
263 _/_v_a_r_/_d_c_c_/_l_i_b_e_x_e_c_/_d_b_c_l_e_a_n in the _/_v_a_r_/_d_c_c_/_l_i_b_e_x_e_c directory. The
264 value can include arguments as in _-_C _'_$_D_C_C___L_I_B_E_X_E_C_/_d_b_c_l_e_a_n _-_F_'.
265
266 Dbclean _s_h_o_u_l_d _n_o_t be run by ddccccdd except in emergencies such as
267 database corruption or hash table overflow. Dbclean(8) should be
268 run daily with the /var/dcc/libexec/cron-dccd cron script
269
270 --LL _l_t_y_p_e_,_f_a_c_i_l_i_t_y_._l_e_v_e_l
271 specifies how messages should be logged. _L_t_y_p_e must be _e_r_r_o_r, _i_n_f_o,
272 or _o_f_f to indicate which of the two types of messages are being con-
273 trolled or to turn off all syslog(3) messages from ddccccdd. _L_e_v_e_l must
274 be a syslog(3) level among _E_M_E_R_G, _A_L_E_R_T, _C_R_I_T, _E_R_R, _W_A_R_N_I_N_G, _N_O_T_I_C_E,
275 _I_N_F_O, and _D_E_B_U_G. _F_a_c_i_l_i_t_y must be among _A_U_T_H, _A_U_T_H_P_R_I_V, _C_R_O_N,
276 _D_A_E_M_O_N, _F_T_P, _K_E_R_N, _L_P_R, _M_A_I_L, _N_E_W_S, _U_S_E_R, _U_U_C_P, and _L_O_C_A_L_0 through
277 _L_O_C_A_L_7. The default is equivalent to
278 --LL _i_n_f_o_,_M_A_I_L_._N_O_T_I_C_E --LL _e_r_r_o_r_,_M_A_I_L_._E_R_R
279
280 --RR [_R_L___S_U_B],[_R_L___A_N_O_N],[_R_L___A_L_L___A_N_O_N],[_R_L___B_U_G_S]
281 sets one or more of the four rate-limits. _R_L___S_U_B limits the number
282 of DCC transactions per second from subscribers or DCC clients with
283 known client-IDs and passwords. This limit applies to each IP
284 address independently.
285
286 _R_L___A_N_O_N limits the number of DCC transactions per second from anony-
287 mous DCC clients. This limit applies to each IP address indepen-
288 dently. It is better to use --uu than to change this value to exclude
289 anonymous clients.
290
291 _R_L___A_L_L___A_N_O_N limits the number of DCC transactions per second from
292 all anonymous DCC clients. This limit applies to all anonymous
293 clients as a group, regardless of their IP addresses.
294
295 _R_L___B_U_G_S limits the number of complaints or error messages per second
296 for all anonymous DCC clients as a group as well as for each DCC
297 client by IP address.
298
299 The default is equivalent to --RR _4_0_0_,_5_0_,_6_0_0_,_0_._1
300
301 FFIILLEESS
302 /var/dcc is the DCC home directory containing data and control files.
303 dcc_db is the database of mail checksums.
304 dcc_db.hash is the mail checksum database hash table.
305 grey_db is the database of greylist checksums.
306 grey_db.hash is the greylist database hash table.
307 flod contains lines controlling DCC flooding of the form:
308 _h_o_s_t[_,_r_p_o_r_t][_;_s_r_c[_,_l_p_o_r_t]] _r_e_m_-_I_D [_p_a_s_s_w_d_-_I_D [_o_-_o_p_t [_i_-_o_p_t]]]
309 where absent optional values are signaled with "-" and
310 _h_o_s_t is the IP address or name of a DCC server and _r_p_o_r_t is
311 the name or number of the TCP port used by the remote
312 server.
313 _s_r_c and _l_p_o_r_t are the IP address or host name and TCP port
314 from which the outgoing flooding connection should come.
315 Incoming flooding connections must arrive at an address
316 and port specified with --aa.
317 _r_e_m_-_i_d is the server-ID of the remote DCC server.
318 _p_a_s_s_w_d_-_I_D is a server-ID that is not assigned to a server, but
319 whose first password is used to sign checksum reports sent
320 to the remote system. Either of its passwords are
321 required with incoming reports. If it is absent or "-",
322 outgoing floods are signed with the first password of the
323 local server in the _i_d_s file and incoming floods must be
324 signed with either password of the remote server-ID.
325 _i_-_o_p_t and _o_-_o_p_t are comma separated lists of
326 _o_f_f turns off flooding to the remote or local system.
327 _t_r_a_p_s indicates that the remote sending or local receiv-
328 ing system has only spam traps.
329 _n_o_-_d_e_l says checksum delete requests are refused by the
330 remote or local server and so turns off sending or
331 accepting delete requests, respectively. By default,
332 delete requests are sent to remote servers and
333 accepted in incoming floods if and only if the peers
334 are exchanging DCC reputations.
335 _d_e_l says delete requests are accepted by the remote or
336 local server.
337 _n_o_-_l_o_g_-_d_e_l turns off logging of incoming requests to
338 delete checksums.
339 _p_a_s_s_i_v_e is used to tell a server outside a firewall to
340 expect a peer inside to create both of the pair of
341 input and output TCP connections used for flooding.
342 The peer inside the firewall should use _S_O_C_K_S or _N_A_T
343 on its _f_l_o_d file entry for this system.
344 _S_O_C_K_S is used to tell a server inside a firewall that it
345 should create both of the TCP connections used for
346 flooding and that SOCKS protocol should be used. The
347 peer outside the firewall should use _p_a_s_s_i_v_e on its
348 _f_l_o_d file entry for this system.
349 _N_A_T differs from _S_O_C_K_S only by not using the SOCKS proto-
350 col.
351 _I_D_1_-_>_I_D_2 converts server-ID _I_D_1 in flooded reports to
352 server-ID _I_D_2. Either _I_D_1 or _I_D_2 may be the string
353 `self' to specify the server's own ID. _I_D_1 can be
354 the string `all' to specify all server-IDs or a pair
355 of server-IDs separated by a dash to specify an
356 inclusive range. _I_D_2 can be the string `ok' to send
357 or receive reports without translation or the string
358 `reject' to not send outgoing or refuse incoming
359 reports. Only the first matching conversion is
360 applied. For example, when `self->ok,all->reject' is
361 applied to a locally generated report, the first con-
362 version is applied and the second is ignored.
363 _l_e_a_f_=_p_a_t_h_-_l_e_n does not send reports with paths longer
364 than _p_a_t_h_-_l_e_n server-IDs.
365 _I_P_v_4 overrides a --66 setting for this flooding peer.
366 _I_P_v_6 overrides the default or an explicit --44 setting.
367 _v_e_r_s specifies the version of the DCC flooding protocol
368 used by the remote DCC server with a string such as
369 `version2'.
370 _t_r_a_c_e sends information about a single peer like the
371 cdcc(8) command ttrraaccee FFLLOOOODD oonn does for all peers.
372 _t_r_a_c_e_2 sends information about individual flooded reports
373 like the cdcc(8) command ttrraaccee FFLLOOOODD22 oonn does for all
374 peers.
375 grey_flod is the equivalent of _f_l_o_d used by ddccccdd when it is a greylist
376 server.
377 flod.map is an automatically generated file in which ddccccdd records its
378 progress sending or flooding reports to DCC peers.
379 grey_flod.map is the equivalent of _f_l_o_d_._m_a_p _u_s_e_d _b_y ddccccdd when it is a
380 greylist server.
381 ids contains the IDs and passwords known by the DCC server. An _i_d_s
382 file that can be read by others cannot be used. It contains
383 blank lines, comments starting with "#" and lines of the form:
384 _i_d[_,_r_p_t_-_o_k][_,_d_e_l_a_y_=_m_s[_*_i_n_f_l_a_t_e]] _p_a_s_s_w_d_1 [_p_a_s_s_w_d_2]
385 where
386 _i_d is a DCC _c_l_i_e_n_t_-_I_D or _s_e_r_v_e_r_-_I_D.
387 _R_p_t_-_o_k if present overrides --QQ by saying that this client is
388 trusted to report only checksums for unsolicited bulk
389 mail.
390 _d_e_l_a_y_=_m_s[_*_i_n_f_l_a_t_e] delays answers to systems using the client
391 _i_d. The _d_e_l_a_y in milliseconds is multiplied by 1 plus the
392 number of recent requests from an IP address using _i_d
393 divided by the _i_n_f_l_a_t_e value. See --uu.
394 _p_a_s_s_w_d_1 is the password currently used by clients with identi-
395 fier _i_d. It is a 1 to 32 character string that does not
396 contain blank, tab, newline or carriage return characters.
397 _p_a_s_s_w_d_2 is the optional next password that those clients will
398 use. A DCC server accepts either password if both are
399 present in the file.
400 Both passwords can be absent if the entry not used except to
401 tell ddccccdd that server-IDs in the flooded reports are valid.
402 The string _u_n_k_n_o_w_n is equivalent to the null string.
403 whitelist contains the DCC server whitelist. It is not used directly but
404 is loaded into the database when dbclean(8) is run.
405 grey_whitelist contains the greylist server whitelist. It is not used
406 directly but is loaded into the database when dbclean(8) is run
407 with --GG.
408 blacklist if present, contains a list of IP addresses and blocks of IP
409 addresses DCC clients that are ignored. Each line in the file
410 should be blank, a comment starting with '#', or an IP address
411 or block of IP addresses in the form
412 [_t_r_a_c_e_,] [_o_k_,] [_b_a_d] xxx.xxx.xxx.xxx[/yy]
413 Changes to the file are automatically noticed and acted upon
414 within a few minutes. Addresses or blocks of addresses can be
415 preceded with _o_k to "punch holes" in blacklisted blocks or with
416 _t_r_a_c_e to log activity. This mechanism is intended for no more
417 than a few dozen blocks of addresses.
418 dccd_clients contains client IP addresses and activity counts.
419 grey_clients contains greylist client IP addresses and activity counts.
420
421 EEXXAAMMPPLLEESS
422 ddccccdd is usually started with other system daemons with something like the
423 script _/_v_a_r_/_d_c_c_/_l_i_b_e_x_e_c_/_r_c_D_C_C. That scripts uses values in
424 /var/dcc/dcc_conf to start the server. With the argument _s_t_o_p,
425 _/_v_a_r_/_d_c_c_/_l_i_b_e_x_e_c_/_r_c_D_C_C can be used to stop the daemon.
426
427 The database grows too large unless old reports are removed. dbclean(8)
428 should be run daily with the /var/dcc/libexec/cron-dccd cron script
429
430 SSEEEE AALLSSOO
431 cdcc(8), dcc(8), dbclean(8), dblist(8), dccifd(8), dccm(8), dccproc(8).
432 dccsight(8),
433
434 HHIISSTTOORRYY
435 ddccccdd is based on an idea from Paul Vixie. It was designed and written at
436 Rhyolite Software, starting in 2000. This document describes version
437 1.3.103.
438
439 February 26, 2009