|
0
|
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> |
|
|
2 <HTML> |
|
|
3 <HEAD> |
|
|
4 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> |
|
|
5 <TITLE>dccd.0.8</TITLE> |
|
|
6 <META http-equiv="Content-Style-Type" content="text/css"> |
|
|
7 <STYLE type="text/css"> |
|
|
8 BODY {background-color:white; color:black} |
|
|
9 ADDRESS {font-size:smaller} |
|
|
10 IMG.logo {width:6em; vertical-align:middle} |
|
|
11 </STYLE> |
|
|
12 </HEAD> |
|
|
13 <BODY> |
|
|
14 <PRE> |
|
|
15 <!-- Manpage converted by man2html 3.0.1 --> |
|
|
16 <B><A HREF="dccd.html">dccd(8)</A></B> Distributed Checksum Clearinghouse <B><A HREF="dccd.html">dccd(8)</A></B> |
|
|
17 |
|
|
18 |
|
|
19 </PRE> |
|
|
20 <H2><A NAME="NAME">NAME</A></H2><PRE> |
|
|
21 <B>dccd</B> -- Distributed Checksum Clearinghouse Daemon |
|
|
22 |
|
|
23 |
|
|
24 </PRE> |
|
|
25 <H2><A NAME="SYNOPSIS">SYNOPSIS</A></H2><PRE> |
|
|
26 <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>-I</B> [<I>host-ID</I>][<I>,user</I>] |
|
|
27 [<B>-a</B> [<I>server-addr</I>][<I>,server-port</I>]] [<B>-q</B> <I>qsize</I>] |
|
|
28 [<B>-G</B> [<I>on,</I>][<I>weak-body,</I>][<I>weak-IP,</I>][<I>embargo</I>][<I>,window</I>][<I>,white</I>]] |
|
|
29 [<B>-W</B> [<I>rate</I>][<I>,chg</I>][<I>,dbsize</I>]] [<B>-K</B> [<I>no-</I>]<I>type</I>] [<B>-T</B> <I>tracemode</I>] |
|
|
30 [<B>-u</B> <I>anon-delay</I>[<I>*inflate</I>]] [<B>-C</B> <I>dbclean</I>] [<B>-L</B> <I>ltype,facility.level</I>] |
|
|
31 [<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>]] |
|
|
32 |
|
|
33 |
|
|
34 </PRE> |
|
|
35 <H2><A NAME="DESCRIPTION">DESCRIPTION</A></H2><PRE> |
|
|
36 <B>Dccd</B> receives reports of checksums related to mail received by DCC |
|
|
37 clients and queries about the total number of reports of particular |
|
|
38 checksums. A DCC server never receives mail, address, headers, or other |
|
|
39 information from clients, but only cryptographically secure checksums of |
|
|
40 such information. A DCC server cannot determine the text or other infor- |
|
|
41 mation that corresponds to the checksums it receives. It only acts as a |
|
|
42 clearinghouse of total counts of checksums computed by clients. |
|
|
43 |
|
|
44 Each DCC server or close cluster of DCC servers is identified by a |
|
|
45 numeric <I>server-ID</I>. Each DCC client is identified by a <I>client-ID</I>, either |
|
|
46 explicitly listed in the <I>ids</I> file or the special anonymous client-ID. |
|
|
47 Many computers are expected to share a single <I>client-ID</I>. A <I>server-ID</I> is |
|
|
48 less than 32768 while a <I>client-ID</I> is between 32768 and 16777215. DCC |
|
|
49 server-IDs need be known only to DCC servers and the people running them. |
|
|
50 The passwords associated with DCC server-IDs should be protected, because |
|
|
51 DCC servers listen to commands authenticated with server-IDs and their |
|
|
52 associated passwords. Each client that does not use the anonymous ID |
|
|
53 must know the client-ID and password used by each of its servers. A sin- |
|
|
54 gle client computer can use different passwords with different server |
|
|
55 computers. See the <I>ids</I> file. |
|
|
56 |
|
|
57 A whitelist of known good (or bad) sources of email prevents legitimate |
|
|
58 mailing lists from being seen as unsolicited bulk email by DCC clients. |
|
|
59 The whitelist used by a DCC server is built into the database when old |
|
|
60 entries are removed by <B><A HREF="dbclean.html">dbclean(8)</A></B>. Each DCC client has its own, local |
|
|
61 whitelist, and in general, whitelists work better in DCC clients than |
|
|
62 servers. |
|
|
63 |
|
|
64 The effectiveness of a Distributed Checksum Clearinghouse increases as |
|
|
65 the number of subscribers increases. Flooding reports of checksums among |
|
|
66 DCC servers increases the effective number of subscribers to each server. |
|
|
67 Each <B>dccd</B> daemon tries to maintain TCP/IP connections to the other |
|
|
68 servers listed in the <I>flod</I> file, and send them reports containing check- |
|
|
69 sums with total counts exceeding thresholds. Changes in the <I>flod</I> file |
|
|
70 are noticed automatically within minutes. |
|
|
71 |
|
|
72 Controls on report flooding are specified in the <I>flod</I> file. Each line |
|
|
73 specifies a hostname and port number to which reports should be flooded, |
|
|
74 a server-ID to identify and authenticate the output stream, a server-ID |
|
|
75 to identify and authenticate an input stream from the same server, and |
|
|
76 flags with each ID. The ability to delete reports of checksums is handy, |
|
|
77 but could be abused. If <I>del</I> is not present among the <I>in-opts</I> options for |
|
|
78 the incoming ID, incoming delete requests are logged and then ignored. |
|
|
79 Floods from DCC "brands" that count only mail to spam traps and whose |
|
|
80 servers use the <B>-Q</B> option to count extremely bulk mail should be marked |
|
|
81 with <I>traps</I>. They can be seen as counting millions of targets, so the |
|
|
82 <I>traps</I> flag on their <I>flod</I> file entry changes their incoming flooded |
|
|
83 reports counts to <I>many.</I> |
|
|
84 |
|
|
85 <B>Dccd</B> automatically checks its <I>flod</I> and <I>ids</I> files periodically. <B><A HREF="cdcc.html">Cdcc(8)</A></B> |
|
|
86 has the commands <B>new ids</B> and <B>flood check</B> to tell <B>dccd</B> to check those two |
|
|
87 files immediately. Both files are also checked for changes after the |
|
|
88 SIGHUP signal. |
|
|
89 |
|
|
90 <A NAME="OPTIONS"><B>OPTIONS</B></A> |
|
|
91 The following options are available: |
|
|
92 |
|
|
93 <A NAME="OPTION-6"><B>-6</B></A> enable IPv6. The default is equivalent to <B>-4</B>. See also the IPv4 |
|
|
94 and IPv6 options in the <I>flod</I> file description below and the <I>IPv6</I> <I>on</I> |
|
|
95 <B><A HREF="cdcc.html">cdcc(8)</A></B> command. |
|
|
96 |
|
|
97 <A NAME="OPTION-4"><B>-4</B></A> disable IPv6. See also <B>-6</B>. |
|
|
98 |
|
|
99 <A NAME="OPTION-d"><B>-d</B></A> enables debugging output. Additional <B>-d</B> options increase the number |
|
|
100 of messages. |
|
|
101 |
|
|
102 <A NAME="OPTION-V"><B>-V</B></A> displays the version of the DCC server daemon. |
|
|
103 |
|
|
104 <A NAME="OPTION-b"><B>-b</B></A> causes the server to not detach itself from the controlling tty or |
|
|
105 put itself into the background. |
|
|
106 |
|
|
107 <A NAME="OPTION-F"><B>-F</B></A> uses write() instead of mmap() in some cases to modify the DCC data- |
|
|
108 base. It is the default on Solaris. |
|
|
109 |
|
|
110 <A NAME="OPTION-f"><B>-f</B></A> turns off <B>-F</B>. |
|
|
111 |
|
|
112 <A NAME="OPTION-Q"><B>-Q</B></A> causes the server to treat reports of checksums as queries except |
|
|
113 from DCC clients marked trusted in the <I>ids</I> file with <I>rpt-ok</I>. See <B>-u</B> |
|
|
114 to turn off access by anonymous or unauthenticated clients |
|
|
115 |
|
|
116 <A NAME="OPTION-i"><B>-i</B></A> <I>server-ID</I> |
|
|
117 specifies the ID of this DCC server. Each server identifies itself |
|
|
118 as responsible for checksums that it forwards to other servers. |
|
|
119 |
|
|
120 <A NAME="OPTION-n"><B>-n</B></A> <I>brand</I> |
|
|
121 is an arbitrary string of letters and numbers that identifies the |
|
|
122 organization running the DCC server. The brand is required, and |
|
|
123 appears in the SMTP <I>X-DCC</I> headers generated by the DCC. |
|
|
124 |
|
|
125 <A NAME="OPTION-h"><B>-h</B></A> <I>homedir</I> |
|
|
126 overrides the default DCC home directory, <I>@prefix@</I>. |
|
|
127 |
|
|
128 <A NAME="OPTION-I"><B>-I</B></A> [<I>host-ID</I>][<I>,user</I>] |
|
|
129 changes the server's globally unique identity for flooding from the |
|
|
130 default value consisting of the first 16 characters of the host |
|
|
131 name. or changes the UID and GID of the process <I>Host-ID</I> is a string |
|
|
132 of up to 16 characters that replaces the first 16 characters of the |
|
|
133 system's hostname in assertions of the server-ID that are flooded to |
|
|
134 peers. <I>User</I> must be valid user name. |
|
|
135 |
|
|
136 <A NAME="OPTION-a"><B>-a</B></A> [<I>server-addr</I>][<I>,server-port</I>] |
|
|
137 adds an hostname or IP address to the list of local IP addresses |
|
|
138 that the server answers. Multiple <B>-a</B> options can be used to specify |
|
|
139 a subset of the available network interfaces or to use more than one |
|
|
140 port number. The default without any <B>-a</B> options is to listen on all |
|
|
141 local IP addresses. It can be useful to list some of the IP |
|
|
142 addresses of multi-homed hosts to deal with firewalls. By default |
|
|
143 <I>server-port</I> is 6277 for DCC servers and 6276 for Greylist servers. |
|
|
144 It is the UDP port at which DCC requests are received and the TCP |
|
|
145 port for incoming floods of reports. |
|
|
146 |
|
|
147 If <I>server-addr</I> is absent and if the <B>getifaddrs(8)</B> function is sup- |
|
|
148 ported, separate UDP sockets are bound to each configured network |
|
|
149 interface so that each DCC clients receives replies from the IP |
|
|
150 addresses to which corresponding request are sent. If <B>dccd</B> is |
|
|
151 started before all network interfaces are turned on or there are |
|
|
152 interfaces that are turned on and off or change their addresses such |
|
|
153 as PPP interfaces, then the special string <I>@</I> should be used to tell |
|
|
154 <B>dccd</B> to bind to an IN_ADDRANY UDP socket. |
|
|
155 |
|
|
156 Outgoing TCP connections to flood checksum reports to other DCC |
|
|
157 servers used the IP address of a single <B>-a</B> option, but only if there |
|
|
158 is single option that is not localhost. See also the <I>flod</I> file. |
|
|
159 |
|
|
160 <A NAME="OPTION-q"><B>-q</B></A> <I>qsize</I> |
|
|
161 specifies the maximum size of the queue of requests from anonymous |
|
|
162 or unauthenticated clients. The default value is the maximum DCC |
|
|
163 RTT in seconds times 200 or 1000. |
|
|
164 |
|
|
165 <A NAME="OPTION-G"><B>-G</B></A> [<I>on,</I>][<I>weak-body,</I>][<I>weak-IP,</I>][<I>embargo</I>][<I>,window</I>][<I>,white</I>] |
|
|
166 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>. |
|
|
167 Greylisting consists of temporarily rejecting or embargoing mail |
|
|
168 from unfamiliar combinations of SMTP client IP address, SMTP enve- |
|
|
169 lope sender, and SMTP envelope recipient. If the SMTP client per- |
|
|
170 sists for <I>embargo</I> <I>seconds</I> and so is probably not an open proxy, |
|
|
171 worm-infected personal computer, or other transient source of spam, |
|
|
172 the triple of <I>(IP</I> <I>address,sender,recipient)</I> is added to a database |
|
|
173 similar to the usual DCC database. If the SMTP client does not try |
|
|
174 again after <I>embargo</I> seconds and before <I>window</I> seconds after the |
|
|
175 first attempt, the triple is forgotten. If the SMTP client persists |
|
|
176 past the embargo, the triple is added to the database and becomes |
|
|
177 familiar and the message is accepted. Familiar triples are remem- |
|
|
178 bered for <I>white</I> seconds after the last accepted mail message. The |
|
|
179 triple is forgotten if it is ever associated with unsolicited bulk |
|
|
180 email. |
|
|
181 |
|
|
182 All three durations can be a number of minutes, hours, days, or |
|
|
183 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 |
|
|
184 default is <B>-G</B> <I>270seconds,7days,63days</I>. The first duration or the |
|
|
185 <I>embargo</I> should be longer than open proxies can linger retransmit- |
|
|
186 ting. The second <I>window</I> time should be as long as legitimate mail |
|
|
187 servers persist in retransmitting to recognize embargoed messages |
|
|
188 whose retransmissions were not received because of network or other |
|
|
189 problems. The <I>white</I> time should be long enough to recognize and not |
|
|
190 embargo messages from regular senders. |
|
|
191 |
|
|
192 Usually the DCC greylist system requires that an almost identical |
|
|
193 copy of the message be retransmitted during the <I>embargo</I>. If |
|
|
194 <I>weak-body</I> is present, any message with the same triple of sender IP |
|
|
195 address, sender mail address, and target mail address ends the |
|
|
196 embargo, even if the body of the message differs. |
|
|
197 |
|
|
198 If <I>weak-IP</I> is present, all mail from an SMTP client at an IP address |
|
|
199 is accept after any message from the same IP address has been |
|
|
200 accepted. |
|
|
201 |
|
|
202 Unlike DCC checksums, the contents of greylist databases are private |
|
|
203 and do not benefit from broad sharing. However, large installations |
|
|
204 can use more two or more greylist servers flooding triples among |
|
|
205 themselves. Flooding among greylist servers is controlled by the |
|
|
206 <I>grey</I><B>_</B><I>flod</I> file. |
|
|
207 |
|
|
208 All greylist cooperating or flooding greylist servers <I>must</I> use the |
|
|
209 same <B>-G</B> values. |
|
|
210 |
|
|
211 Clients of greylist servers cannot be anonymous and must have |
|
|
212 client-IDs and passwords assigned in the <I>ids</I> file. This implies |
|
|
213 that cdcc commands directed to greylist servers must specify the |
|
|
214 server-ID. |
|
|
215 |
|
|
216 White- and blacklists are honored by the DCC clients. whitelisted |
|
|
217 messages are embargoed or checked with a greylist server. The |
|
|
218 greylist triples of blacklisted messages, messages whose DCC counts |
|
|
219 make them spam, and other messages known to be spam are sent to a |
|
|
220 greylist server to be removed from the greylist database and cause |
|
|
221 an embargo on the next messages with those triples. |
|
|
222 |
|
|
223 Messages whose checksums match greylist server whitelists are not |
|
|
224 embargoed and the checksums of their triples are not added to the |
|
|
225 greylist database. |
|
|
226 |
|
|
227 The target counts of embargoed messages are reported to the DCC net- |
|
|
228 work to improve the detection of bulk mail. |
|
|
229 |
|
|
230 <A NAME="OPTION-W"><B>-W</B></A> [<I>rate</I>][<I>,chg</I>][<I>,dbsize</I>] |
|
|
231 controls quick database cleaning. If the database is larger than |
|
|
232 <I>dbsize</I>, it seems that the database has not recently and is not about |
|
|
233 to be cleaned, <B>dccd</B> is receiving fewer than <I>rate</I> requests per sec- |
|
|
234 ond, and if telling DCC clients that the database is about to be |
|
|
235 cleaned reduces that rate by <I>chg</I>%, then <B>dccd</B> starts <B><A HREF="dbclean.html">dbclean(8)</A></B> for a |
|
|
236 quick database cleaning. The cleaning is abandoned if it takes too |
|
|
237 long. The default values are equivalent to <B>-W</B> <I>1.0,40.0,RSS</I> where |
|
|
238 <I>RSS</I> is the maximum dccd resident set displayed the system log by <B>-d</B> |
|
|
239 when <B>starts</B>. |
|
|
240 |
|
|
241 <A NAME="OPTION-K"><B>-K</B></A> [<I>no-</I>]<I>type</I> |
|
|
242 marks checksums of <I>type</I> (not) be kept or counted in the database |
|
|
243 unless they appear in the whitelist. Explicit settings add to or |
|
|
244 remove from the initial contents of the list, which is equivalent to |
|
|
245 <B>-K</B> <I>Body</I> <B>-K</B> <I>Fuz1</I> <B>-K</B> <I>Fuz2</I>. |
|
|
246 |
|
|
247 <A NAME="OPTION-T"><B>-T</B></A> <I>tracemode</I> |
|
|
248 causes the server to trace or record some operations. <I>tracemode</I> |
|
|
249 must be one of the following: |
|
|
250 <I>ADMN</I> administrative requests from the control program, <B><A HREF="cdcc.html">cdcc(8)</A></B> |
|
|
251 <I>ANON</I> errors by anonymous clients |
|
|
252 <I>CLNT</I> errors by authenticated clients |
|
|
253 <I>RLIM</I> rate-limited messages |
|
|
254 <I>QUERY</I> all queries and reports |
|
|
255 <I>RIDC</I> some messages concerning the report-ID cache that is used |
|
|
256 to detect duplicate reports from clients |
|
|
257 <I>FLOOD</I> messages about inter-server flooding connections |
|
|
258 <I>FLOOD2</I> messages about flooded reports |
|
|
259 <I>IDS</I> unknown server-IDs in flooded reports |
|
|
260 <I>BL</I> requests from clients in the <I>blacklist</I> file. |
|
|
261 <I>DB</I> odd database events including long chains of duplicate |
|
|
262 checksums |
|
|
263 <I>WLIST</I> reports of whitelisted checksums from authenticated, not |
|
|
264 anonymous DCC clients |
|
|
265 The default is <I>ANON</I> <I>CLNT</I>. |
|
|
266 |
|
|
267 <A NAME="OPTION-u"><B>-u</B></A> <I>anon-delay</I>[<I>*inflate</I>] |
|
|
268 changes the number of milliseconds anonymous or unauthenticated |
|
|
269 clients must wait for answers to their queries and reports. The |
|
|
270 purpose of this delay is to discourage large anonymous clients. The |
|
|
271 <I>anon-delay</I> is multiplied by 1 plus the number of recent anonymous |
|
|
272 requests from an IP address divided by the <I>inflate</I> value. |
|
|
273 |
|
|
274 The string <I>FOREVER</I> turns off all anonymous or unauthenticated access |
|
|
275 not only for checksum queries and reports but also <B><A HREF="cdcc.html">cdcc(8)</A> stats</B> |
|
|
276 requests. A missing value for <I>inflate</I> turns off inflation. |
|
|
277 |
|
|
278 The default value is <I>50,none</I>, except when <B>-G</B> is used in which case |
|
|
279 <I>FOREVER</I> is assumed and required. |
|
|
280 |
|
|
281 <A NAME="OPTION-C"><B>-C</B></A> <I>dbclean</I> |
|
|
282 changes the default name or path of the program used to rebuild the |
|
|
283 hash table when it becomes too full. The default value is |
|
|
284 <I>@libexecdir@/dbclean</I> in the <I>@libexecdir@</I> directory. The |
|
|
285 value can include arguments as in <I>-C</I> <I>'$DCC</I><B>_</B><I>LIBEXEC/dbclean</I> <I>-F'</I>. |
|
|
286 |
|
|
287 Dbclean <I>should</I> <I>not</I> be run by <B>dccd</B> except in emergencies such as |
|
|
288 database corruption or hash table overflow. <B><A HREF="dbclean.html">Dbclean(8)</A></B> should be |
|
|
289 run daily with the @libexecdir@/cron-dccd cron script |
|
|
290 |
|
|
291 <A NAME="OPTION-L"><B>-L</B></A> <I>ltype,facility.level</I> |
|
|
292 specifies how messages should be logged. <I>Ltype</I> must be <I>error</I>, <I>info</I>, |
|
|
293 or <I>off</I> to indicate which of the two types of messages are being con- |
|
|
294 trolled or to turn off all <B>syslog(3)</B> messages from <B>dccd</B>. <I>Level</I> must |
|
|
295 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>, |
|
|
296 <I>INFO</I>, and <I>DEBUG</I>. <I>Facility</I> must be among <I>AUTH</I>, <I>AUTHPRIV</I>, <I>CRON</I>, |
|
|
297 <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 |
|
|
298 <I>LOCAL7</I>. The default is equivalent to |
|
|
299 <B>-L</B> <I>info,MAIL.NOTICE</I> <B>-L</B> <I>error,MAIL.ERR</I> |
|
|
300 |
|
|
301 <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>] |
|
|
302 sets one or more of the four rate-limits. <I>RL</I><B>_</B><I>SUB</I> limits the number |
|
|
303 of DCC transactions per second from subscribers or DCC clients with |
|
|
304 known client-IDs and passwords. This limit applies to each IP |
|
|
305 address independently. |
|
|
306 |
|
|
307 <I>RL</I><B>_</B><I>ANON</I> limits the number of DCC transactions per second from anony- |
|
|
308 mous DCC clients. This limit applies to each IP address indepen- |
|
|
309 dently. It is better to use <B>-u</B> than to change this value to exclude |
|
|
310 anonymous clients. |
|
|
311 |
|
|
312 <I>RL</I><B>_</B><I>ALL</I><B>_</B><I>ANON</I> limits the number of DCC transactions per second from |
|
|
313 all anonymous DCC clients. This limit applies to all anonymous |
|
|
314 clients as a group, regardless of their IP addresses. |
|
|
315 |
|
|
316 <I>RL</I><B>_</B><I>BUGS</I> limits the number of complaints or error messages per second |
|
|
317 for all anonymous DCC clients as a group as well as for each DCC |
|
|
318 client by IP address. |
|
|
319 |
|
|
320 The default is equivalent to <B>-R</B> <I>400,50,600,0.1</I> |
|
|
321 |
|
|
322 |
|
|
323 </PRE> |
|
|
324 <H2><A NAME="FILES">FILES</A></H2><PRE> |
|
|
325 <A NAME="FILE-@prefix@">@prefix@</A> is the DCC home directory containing data and control files. |
|
|
326 <A NAME="FILE-dcc_db">dcc_db</A> is the database of mail checksums. |
|
|
327 <A NAME="FILE-dcc_db.hash">dcc_db.hash</A> is the mail checksum database hash table. |
|
|
328 <A NAME="FILE-grey_db">grey_db</A> is the database of greylist checksums. |
|
|
329 <A NAME="FILE-grey_db.hash">grey_db.hash</A> is the greylist database hash table. |
|
|
330 <A NAME="FILE-flod">flod</A> contains lines controlling DCC flooding of the form: |
|
|
331 <I>host</I>[<I>,rport</I>][<I>;src</I>[<I>,lport</I>]] <I>rem-ID</I> [<I>passwd-ID</I> [<I>o-opt</I> [<I>i-opt</I>]]] |
|
|
332 where absent optional values are signaled with "-" and |
|
|
333 <I>host</I> is the IP address or name of a DCC server and <I>rport</I> is |
|
|
334 the name or number of the TCP port used by the remote |
|
|
335 server. |
|
|
336 <I>src</I> and <I>lport</I> are the IP address or host name and TCP port |
|
|
337 from which the outgoing flooding connection should come. |
|
|
338 Incoming flooding connections must arrive at an address |
|
|
339 and port specified with <B>-a</B>. |
|
|
340 <I>rem-id</I> is the server-ID of the remote DCC server. |
|
|
341 <I>passwd-ID</I> is a server-ID that is not assigned to a server, but |
|
|
342 whose first password is used to sign checksum reports sent |
|
|
343 to the remote system. Either of its passwords are |
|
|
344 required with incoming reports. If it is absent or "-", |
|
|
345 outgoing floods are signed with the first password of the |
|
|
346 local server in the <I>ids</I> file and incoming floods must be |
|
|
347 signed with either password of the remote server-ID. |
|
|
348 <I>i-opt</I> and <I>o-opt</I> are comma separated lists of |
|
|
349 <I>off</I> turns off flooding to the remote or local system. |
|
|
350 <I>traps</I> indicates that the remote sending or local receiv- |
|
|
351 ing system has only spam traps. |
|
|
352 <I>no-del</I> says checksum delete requests are refused by the |
|
|
353 remote or local server and so turns off sending or |
|
|
354 accepting delete requests, respectively. By default, |
|
|
355 delete requests are sent to remote servers and |
|
|
356 accepted in incoming floods if and only if the peers |
|
|
357 are exchanging DCC reputations. |
|
|
358 <I>del</I> says delete requests are accepted by the remote or |
|
|
359 local server. |
|
|
360 <I>no-log-del</I> turns off logging of incoming requests to |
|
|
361 delete checksums. |
|
|
362 <I>passive</I> is used to tell a server outside a firewall to |
|
|
363 expect a peer inside to create both of the pair of |
|
|
364 input and output TCP connections used for flooding. |
|
|
365 The peer inside the firewall should use <I>SOCKS</I> or <I>NAT</I> |
|
|
366 on its <I>flod</I> file entry for this system. |
|
|
367 <I>SOCKS</I> is used to tell a server inside a firewall that it |
|
|
368 should create both of the TCP connections used for |
|
|
369 flooding and that SOCKS protocol should be used. The |
|
|
370 peer outside the firewall should use <I>passive</I> on its |
|
|
371 <I>flod</I> file entry for this system. |
|
|
372 <I>NAT</I> differs from <I>SOCKS</I> only by not using the SOCKS proto- |
|
|
373 col. |
|
|
374 <I>ID1->ID2</I> converts server-ID <I>ID1</I> in flooded reports to |
|
|
375 server-ID <I>ID2</I>. Either <I>ID1</I> or <I>ID2</I> may be the string |
|
|
376 `self' to specify the server's own ID. <I>ID1</I> can be |
|
|
377 the string `all' to specify all server-IDs or a pair |
|
|
378 of server-IDs separated by a dash to specify an |
|
|
379 inclusive range. <I>ID2</I> can be the string `ok' to send |
|
|
380 or receive reports without translation or the string |
|
|
381 `reject' to not send outgoing or refuse incoming |
|
|
382 reports. Only the first matching conversion is |
|
|
383 applied. For example, when `self->ok,all->reject' is |
|
|
384 applied to a locally generated report, the first con- |
|
|
385 version is applied and the second is ignored. |
|
|
386 <I>leaf=path-len</I> does not send reports with paths longer |
|
|
387 than <I>path-len</I> server-IDs. |
|
|
388 <I>IPv4</I> overrides a <B>-6</B> setting for this flooding peer. |
|
|
389 <I>IPv6</I> overrides the default or an explicit <B>-4</B> setting. |
|
|
390 <I>vers</I> specifies the version of the DCC flooding protocol |
|
|
391 used by the remote DCC server with a string such as |
|
|
392 `version2'. |
|
|
393 <I>trace</I> sends information about a single peer like the |
|
|
394 <B><A HREF="cdcc.html">cdcc(8)</A></B> command <B>trace FLOOD on</B> does for all peers. |
|
|
395 <I>trace2</I> sends information about individual flooded reports |
|
|
396 like the <B><A HREF="cdcc.html">cdcc(8)</A></B> command <B>trace FLOOD2 on</B> does for all |
|
|
397 peers. |
|
|
398 <A NAME="FILE-grey_flod">grey_flod</A> is the equivalent of <I>flod</I> used by <B>dccd</B> when it is a greylist |
|
|
399 server. |
|
|
400 <A NAME="FILE-flod.map">flod.map</A> is an automatically generated file in which <B>dccd</B> records its |
|
|
401 progress sending or flooding reports to DCC peers. |
|
|
402 <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 |
|
|
403 greylist server. |
|
|
404 <A NAME="FILE-ids">ids</A> contains the IDs and passwords known by the DCC server. An <I>ids</I> |
|
|
405 file that can be read by others cannot be used. It contains |
|
|
406 blank lines, comments starting with "#" and lines of the form: |
|
|
407 <I>id</I>[<I>,rpt-ok</I>][<I>,delay=ms</I>[<I>*inflate</I>]] <I>passwd1</I> [<I>passwd2</I>] |
|
|
408 where |
|
|
409 <I>id</I> is a DCC <I>client-ID</I> or <I>server-ID</I>. |
|
|
410 <I>Rpt-ok</I> if present overrides <B>-Q</B> by saying that this client is |
|
|
411 trusted to report only checksums for unsolicited bulk |
|
|
412 mail. |
|
|
413 <I>delay=ms</I>[<I>*inflate</I>] delays answers to systems using the client |
|
|
414 <I>id</I>. The <I>delay</I> in milliseconds is multiplied by 1 plus the |
|
|
415 number of recent requests from an IP address using <I>id</I> |
|
|
416 divided by the <I>inflate</I> value. See <B>-u</B>. |
|
|
417 <I>passwd1</I> is the password currently used by clients with identi- |
|
|
418 fier <I>id</I>. It is a 1 to 32 character string that does not |
|
|
419 contain blank, tab, newline or carriage return characters. |
|
|
420 |
|
|
421 <I>passwd2</I> is the optional next password that those clients will |
|
|
422 use. A DCC server accepts either password if both are |
|
|
423 present in the file. |
|
|
424 Both passwords can be absent if the entry not used except to |
|
|
425 tell <B>dccd</B> that server-IDs in the flooded reports are valid. |
|
|
426 The string <I>unknown</I> is equivalent to the null string. |
|
|
427 <A NAME="FILE-whitelist">whitelist</A> contains the DCC server whitelist. It is not used directly but |
|
|
428 is loaded into the database when <B><A HREF="dbclean.html">dbclean(8)</A></B> is run. |
|
|
429 <A NAME="FILE-grey_whitelist">grey_whitelist</A> contains the greylist server whitelist. It is not used |
|
|
430 directly but is loaded into the database when <B><A HREF="dbclean.html">dbclean(8)</A></B> is run |
|
|
431 with <B>-G</B>. |
|
|
432 <A NAME="FILE-blacklist">blacklist</A> if present, contains a list of IP addresses and blocks of IP |
|
|
433 addresses DCC clients that are ignored. Each line in the file |
|
|
434 should be blank, a comment starting with '#', or an IP address |
|
|
435 or block of IP addresses in the form |
|
|
436 [<I>trace,</I>] [<I>ok,</I>] [<I>bad</I>] xxx.xxx.xxx.xxx[/yy] |
|
|
437 Changes to the file are automatically noticed and acted upon |
|
|
438 within a few minutes. Addresses or blocks of addresses can be |
|
|
439 preceded with <I>ok</I> to "punch holes" in blacklisted blocks or with |
|
|
440 <I>trace</I> to log activity. This mechanism is intended for no more |
|
|
441 than a few dozen blocks of addresses. |
|
|
442 <A NAME="FILE-dccd_clients">dccd_clients</A> contains client IP addresses and activity counts. |
|
|
443 <A NAME="FILE-grey_clients">grey_clients</A> contains greylist client IP addresses and activity counts. |
|
|
444 |
|
|
445 |
|
|
446 </PRE> |
|
|
447 <H2><A NAME="EXAMPLES">EXAMPLES</A></H2><PRE> |
|
|
448 <B>dccd</B> is usually started with other system daemons with something like the |
|
|
449 script <I>@libexecdir@/rcDCC</I>. That scripts uses values in |
|
|
450 @prefix@/dcc_conf to start the server. With the argument <I>stop</I>, |
|
|
451 <I>@libexecdir@/rcDCC</I> can be used to stop the daemon. |
|
|
452 |
|
|
453 The database grows too large unless old reports are removed. <B><A HREF="dbclean.html">dbclean(8)</A></B> |
|
|
454 should be run daily with the @libexecdir@/cron-dccd cron script |
|
|
455 |
|
|
456 |
|
|
457 </PRE> |
|
|
458 <H2><A NAME="SEE-ALSO">SEE ALSO</A></H2><PRE> |
|
|
459 <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>. |
|
|
460 <B><A HREF="dccsight.html">dccsight(8)</A></B>, |
|
|
461 |
|
|
462 |
|
|
463 </PRE> |
|
|
464 <H2><A NAME="HISTORY">HISTORY</A></H2><PRE> |
|
|
465 <B>dccd</B> is based on an idea from Paul Vixie. It was designed and written at |
|
|
466 Rhyolite Software, starting in 2000. This document describes version |
|
|
467 1.3.103. |
|
|
468 |
|
|
469 February 26, 2009 |
|
|
470 </PRE> |
|
|
471 <HR> |
|
|
472 <ADDRESS> |
|
|
473 Man(1) output converted with |
|
|
474 <a href="http://www.oac.uci.edu/indiv/ehood/man2html.html">man2html</a> |
|
|
475 modified for the DCC $Date 2001/04/29 03:22:18 $ |
|
|
476 <BR> |
|
|
477 <A HREF="http://www.dcc-servers.net/dcc/"> |
|
|
478 <IMG SRC="http://logos.dcc-servers.net/border.png" |
|
|
479 class=logo ALT="DCC logo"> |
|
|
480 </A> |
|
|
481 <A HREF="http://validator.w3.org/check?uri=referer"> |
|
|
482 <IMG class=logo ALT="Valid HTML 4.01 Strict" |
|
|
483 SRC="http://www.w3.org/Icons/valid-html401"> |
|
|
484 </A> |
|
|
485 </ADDRESS> |
|
|
486 </BODY> |
|
|
487 </HTML> |
