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
|
dccd(SMM) LOCAL dccd(SMM)
NNAAMMEE
ddccccdd -- Distributed Checksum Clearinghouse Daemon
SSYYNNOOPPSSIISS
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]
[--aa [_s_e_r_v_e_r_-_a_d_d_r][_,_s_e_r_v_e_r_-_p_o_r_t]] [--II _h_o_s_t_-_I_D] [--qq _q_s_i_z_e]
[--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_a_i_t][_,_w_h_i_t_e]]
[--tt [_t_y_p_e]_,_t_h_r_e_s_h_o_l_d] [--KK [_n_o_-]_t_y_p_e] [--TT _t_r_a_c_e_m_o_d_e]
[--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]
[--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]]
DDEESSCCRRIIPPTTIIOONN
DDccccdd 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 _s_e_r_v_e_r_-_I_D. Each DCC client is identified by a _c_l_i_e_n_t_-_I_D, either
explicitly listed in the _i_d_s file or the special anonymous client-ID.
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
less than 32768 while a _c_l_i_e_n_t_-_I_D 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_d_s 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 dbclean(8). 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 ddccccdd daemon tries to maintain TCP/IP connections to the other
servers listed in the _f_l_o_d file, and send them reports containing check-
sums with total counts exceeding thresholds. Changes in the _f_l_o_d file
are noticed automatically within minutes.
Controls on report flooding are specified in the _f_l_o_d 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 _d_e_l is not present among the _i_n_-_o_p_t_s 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 --QQ option to count extremely "bulk" mail should be marked
with _t_r_a_p_s. They can be seen as counting millions of targets, so the
_t_r_a_p_s flag on their _f_l_o_d file entry changes their incoming flooded
reports counts to "many."
DDccccdd automatically checks its _f_l_o_d and _i_d_s files periodically. Cdcc(8)
has the server commands nneeww iiddss and fflloooodd cchheecckk to tell ddccccdd to check
those two files immediately. Both files are also checked for changes in
response to the SIGHUP signal.
OOPPTTIIOONNSS
The following options are available:
--66 enable IPv6. The default is equivalent to --44. See also the IPv4
and IPv6 options in the _f_l_o_d file.
--44 disable IPv6. See also --66.
--dd enables debugging output. Additional --dd options increase the number
of messages.
--VV displays the version of the DCC server daemon.
--bb causes the server to not detach itself from the controlling tty or
put itself into the background.
--FF uses read() and write() instead of mmap() in some cases to access
the DCC database. It is never the default.
--ff turns off --FF.
--QQ causes the server to treat reports of checksums as queries except
from DCC clients marked trusted in the _i_d_s file with _r_p_t_-_o_k. See --uu
to turn off access by anonymous or unauthenticated clients
--ii _s_e_r_v_e_r_-_I_D
specifies the ID of this DCC server. Each server identifies itself
as responsible for checksums that it forwards to other servers.
--nn _b_r_a_n_d
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 _X_-_D_C_C headers generated by the DCC.
--hh _h_o_m_e_d_i_r
overrides the default DCC home directory, which is often _/_v_a_r_/_d_c_c.
--aa [_s_e_r_v_e_r_-_a_d_d_r][_,_s_e_r_v_e_r_-_p_o_r_t]
adds an hostname or IP address to the list of local IP addresses
that the server answers. Multiple --aa 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
_s_e_r_v_e_r_-_p_o_r_t 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 _s_e_r_v_e_r_-_a_d_d_r is absent and if the getifaddrs(8) 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 ddccccdd 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 _@ should be used to tell
ddccccdd 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 --aa option, but only if there
is single option. Note that this means that --aa --112277..00..00..11 breaks
flooding, often with "Invalid argument" messages. See also the _f_l_o_d
file.
--II _h_o_s_t_-_I_D
changes the server's globally unique identity from the default value
consisting of the first 16 characters of the host name. _H_o_s_t_-_I_D is
a string of up to 16 characters to be used instead of the first 16
characters of the system's hostname.
--qq _q_s_i_z_e
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.
--tt [_t_y_p_e]_,_t_h_r_e_s_h_o_l_d
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 _t_h_r_e_s_h_o_l_d are not flooded. If _t_h_r_e_s_h_o_l_d is the
string "many," a value of millions is understood. It must be at
least 10. If _t_y_p_e is absent, only the thresholds for the body
checksums are set. The thresholds built into ddccccdd for the body
checksums, _B_o_d_y, _F_u_z_1, and _F_u_z_2 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 ddccccdd sets the body thresholds to one third of _D_C_C_M___R_E_J_E_C_T___A_T
in the dcc_conf file but no less than 10 or more than 20. That is
the rejection threshold for dccm(8),
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.
--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_a_i_t][_,_w_h_i_t_e]
changes ddccccdd to a Greylist server for dccm(8) or dccifd(8).
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 _e_m_b_a_r_g_o _s_e_c_o_n_d_s and so is probably not an "open proxy,"
worm-infected personal computer, or other transient source of spam,
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
similar to the usual DCC database. If the SMTP client does not try
again after _e_m_b_a_r_g_o seconds and before _w_a_i_t 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 _w_h_i_t_e 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 _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
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
_e_m_b_a_r_g_o should be longer than open proxies can linger retransmit-
ting. The second _w_a_i_t 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 _w_h_i_t_e 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 _e_m_b_a_r_g_o. If
_w_e_a_k_-_b_o_d_y is present, any message with the same triple of sender IP
address, sender mail address, and target mail address ends the
embargo.
If _w_e_a_k_-_I_P 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
_g_r_e_y___f_l_o_d file.
_N_o_t_e_: All greylist cooperating or flooding greylist servers must use
the same --GG values.
Clients of greylist servers cannot be anonymous and must have
client-IDs and passwords assigned in the _i_d_s 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.
--KK [_n_o_-]_t_y_p_e
marks checksums of _t_y_p_e (not) be "kept" or counted in the database
unless they appear in the whitelist. The default is equivalent to
--KK _n_o_-_a_l_l --KK _B_o_d_y --KK _F_u_z_1 --KK _F_u_z_2 to count only the body checksums.
--TT _t_r_a_c_e_m_o_d_e
causes the server to trace or record some operations. _t_r_a_c_e_m_o_d_e
must be one of the following:
_A_L_L all tracing
_A_D_M_N administrative requests from the control program, cdcc(8)
_A_N_O_N errors by anonymous clients
_C_L_N_T errors by authenticated clients
_R_L_I_M rate-limited messages
_Q_U_E_R_Y all queries and reports
_R_I_D_C some messages concerning the report-ID cache that is used
to detect duplicate reports from clients
_F_L_O_O_D messages about inter-server flooding
_I_D_S unknown server-IDs in flooded reports
_B_L requests from clients with IP addresses in the _b_l_a_c_k_l_i_s_t
file.
The default is _A_N_O_N _C_L_N_T.
--uu _a_n_o_n_-_d_e_l_a_y[_*_i_n_f_l_a_t_e]
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
_a_n_o_n_-_d_e_l_a_y is multiplied by 1 plus the number of recent anonymous
requests from an IP address divided by the _i_n_f_l_a_t_e value.
The string _F_O_R_E_V_E_R turns off all anonymous or unauthenticated access
not only for checksum queries and reports but also cdcc(8) ssttaattss
requests. A missing value for _i_n_f_l_a_t_e turns off inflation.
The default value is _5_0_,_n_o_n_e, except when --GG is used in which case
_F_O_R_E_V_E_R is assumed and required.
--CC _d_b_c_l_e_a_n
changes the default name or path of the program used to rebuild the
hash table when it becomes too full. The default value is
_l_i_b_e_x_e_c_/_d_b_c_l_e_a_n in the DCC home directory. The 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_'.
--LL _l_t_y_p_e_,_f_a_c_i_l_i_t_y_._l_e_v_e_l
specifies how messages should be logged. _L_t_y_p_e must be _e_r_r_o_r or
_i_n_f_o to indicate which of the two types of messages are being con-
trolled. _L_e_v_e_l must 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, _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, _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 _L_O_C_A_L_7. The default is equivalent to
-L info,MAIL.NOTICE -L error,MAIL.ERR
--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]
sets the four categories of rate-limits. _R_L___S_U_B 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.
_R_L___A_N_O_N 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 --uu than to change this value to exclude
anonymous clients.
_R_L___A_L_L___A_N_O_N 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.
_R_L___B_U_G_S 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 --RR _2_0_0_,_5_0_,_2_0_0_,_0_._1
FFIILLEESS
/var/dcc is the DCC home directory containing data and control files.
dcc_db is the database of mail checksums.
dcc_db.hash is the mail checksum database hash table.
grey_db is the database of greylist checksums.
grey_db.hash is the greylist database hash table.
flod contains lines controlling DCC flooding of the form:
_h_o_s_t[_,_p_o_r_t][_;_s_r_c] _r_e_m_-_I_D [_p_a_s_s_w_d_-_I_D [_o_-_o_p_t_s [_i_-_o_p_t_s]]]
where absent optional values are signaled with "-" and
_h_o_s_t is the IP address or name of a DCC server.
_p_o_r_t is the name or number of the UDP port used by the server.
_s_r_c is the IP address or host name from which the outgoing
connection should come.
_r_e_m_-_i_d is the server-ID of the remote DCC server.
_p_a_s_s_w_d_-_I_D 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_d_s file and incoming floods must be
signed with either password of the remote server-ID.
_i_-_o_p_t_s and _o_-_o_p_t_s are comma-separated lists of
_o_f_f turns off flooding to the remote or local system.
_t_r_a_p_s indicates that the remote sending or local receiv-
ing system has only "spam traps."
_n_o_-_d_e_l 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.
_d_e_l says delete requests are accepted by the remote or
local server.
_n_o_-_l_o_g_-_d_e_l turns off logging of incoming requests to
delete checksums.
_p_a_s_s_i_v_e 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 _S_O_C_K_S on its
_f_l_o_d file entry for this system.
_S_O_C_K_S 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 _p_a_s_s_i_v_e on its
_f_l_o_d file entry for this system.
_I_D_1_-_>_I_D_2 converts server-ID _I_D_1 in flooded reports to
server-ID _I_D_2. Either _I_D_1 or _I_D_2 may be the string
`self' to specify the server's own ID. _I_D_1 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_D_2 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.
_l_e_a_f_=_p_a_t_h_-_l_e_n does not send reports with paths longer
than _p_a_t_h_-_l_e_n server-IDs.
_I_P_v_4 overrides a --66 setting for this flooding peer.
_I_P_v_6 overrides the default or an explicit --44 setting.
_v_e_r_s specifies the version of the DCC flooding protocol
used by the remote DCC server with a string such as
`version2'.
grey_flod is the equivalent of _f_l_o_d _u_s_e_d _b_y ddccccdd when it is a greylist
server.
flod.map is an automatically generated file in which ddccccdd records its
progress sending or flooding reports to DCC peers.
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
greylist server.
ids contains the IDs and passwords known by the DCC server. An _i_d_s
file that can be read by others cannot be used. It contains
blank lines, comments starting with "#" and lines of the form:
_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]
where
_i_d is a DCC _c_l_i_e_n_t_-_I_D or _s_e_r_v_e_r_-_I_D.
_R_p_t_-_o_k if present overrides --QQ by saying that this client is
trusted to report only checksums for unsolicited bulk
mail.
_d_e_l_a_y_=_m_s[_*_i_n_f_l_a_t_e] delays answers to systems using the client
_i_d. The _d_e_l_a_y in milliseconds is multiplied by 1 plus the
number of recent requests from an IP address using _i_d
divided by the _i_n_f_l_a_t_e value. See --UU.
_p_a_s_s_w_d_1 is the password currently used by clients with identi-
fier _i_d. It is a 1 to 32 character string that does not
contain blank, tab, newline or carriage return characters.
_p_a_s_s_w_d_2 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 ddccccdd that server-IDs in the flooded reports are valid.
The string _u_n_k_n_o_w_n is equivalent to the null string.
whitelist contains the DCC server whitelist. It is not used directly but
is loaded into the database when dbclean(8) is run.
grey_whitelist contains the greylist server whitelist. It is not used
directly but is loaded into the database when dbclean(8) is run
with --GG.
blacklist 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.
EEXXAAMMPPLLEESS
ddccccdd is usually started with other system daemons with something like the
script misc/start-dccd. It uses values in the file dcc_conf in the DCC
home directory to start the server.
The following is useful for cleanly stopping the daemon:
cdcc 'id 100; stop'
Again, the ID of the local server must be used instead of "100."
Unless old reports are removed from the database, it grows too large.
dbclean(8) should be run daily with script like /var/dcc/libexec/cron-
dccd.
SSEEEE AALLSSOO
cdcc(8), dcc(8), dbclean(8), dblist(8), dccifd(8), dccm(8), dccproc(8).
dccsight(8),
HHIISSTTOORRYY
ddccccdd is based on an idea from Paul Vixie. It was designed and written at
Rhyolite Software starting in 2000. This document describes version
1.2.74.
FreeBSD 4.9 March 20, 2005 FreeBSD 4.9
|