Mercurial > notdcc
view dccm.0 @ 4:d329bb5c36d0
Changes making it compile the new upstream release
| author | Peter Gervai <grin@grin.hu> |
|---|---|
| date | Tue, 10 Mar 2009 14:57:12 +0100 |
| parents | c7f6b056b673 |
| children |
line wrap: on
line source
dccm(8) Distributed Checksum Clearinghouse dccm(8) NNAAMMEE ddccccmm -- Distributed Checksum Clearinghouse Milter Interface SSYYNNOOPPSSIISS ddccccmm [--VVddbbxxAANNQQ] [--GG _o_n | _o_f_f | _n_o_I_P | _I_P_m_a_s_k_/_x_x] [--hh _h_o_m_e_d_i_r] [--II _u_s_e_r] [--pp _p_r_o_t_o_c_o_l_:_f_i_l_e_n_a_m_e | _p_r_o_t_o_c_o_l_:_p_o_r_t_@_h_o_s_t] [--mm _m_a_p] [--ww _w_h_i_t_e_c_l_n_t] [--UU _u_s_e_r_d_i_r_s] [--aa _I_G_N_O_R_E | _R_E_J_E_C_T | _D_I_S_C_A_R_D] [--tt _t_y_p_e_,[_l_o_g_-_t_h_o_l_d_,]_r_e_j_-_t_h_o_l_d] [--gg [_n_o_t_-]_t_y_p_e] [--SS _h_e_a_d_e_r] [--ll _l_o_g_d_i_r] [--RR _r_u_n_d_i_r] [--rr _r_e_j_e_c_t_i_o_n_-_m_s_g] [--jj _m_a_x_j_o_b_s] [--BB _d_n_s_b_l_-_o_p_t_i_o_n] [--LL _l_t_y_p_e_,_f_a_c_i_l_i_t_y_._l_e_v_e_l] DDEESSCCRRIIPPTTIIOONN ddccccmm is a daemon built with the sendmail milter interface intended to connect sendmail(8) to DCC servers. When built with the milter filter machinery and configured to talk to ddccccmm in the _s_e_n_d_m_a_i_l_._c_f file, send- mail passes all email to ddccccmm which in turn reports related checksums to the nearest DCC server. ddccccmm then adds an _X_-_D_C_C SMTP header line to the message. Sendmail is told to reject the message if it is unsolicited bulk mail. DDccccmm sends reports of checksums related to mail received by DCC clients and queries about the total number of reports of particular checksums. A DCC server receives _n_o mail, address, headers, or other information, but only cryptographically secure checksums of such information. A DCC server cannot determine the text or other information that corresponds to the checksums it receives. Its only acts as a clearinghouse of counts for checksums computed by clients. For complete privacy as far as the DCC is concerned, the checksums of purely internal mail or other mail that is known to not be unsolicited bulk can be listed in a whitelist to not be reported to the DCC server. Since the checksums of messages that are whitelisted locally by the --ww _w_h_i_t_e_c_l_n_t file are not reported to the DCC server, ddccccmm knows nothing about the total recipient counts for their checksums and so cannot add _X_-_D_C_C header lines to such messages. Sendmail does not tell ddccccmm about messages that are not received by sendmail via SMTP, including messages submitted locally and received via UUCP, and so they also do not receive _X_-_D_C_C header lines. Enable the daemon and put its parameters in the _d_c_c___c_o_n_f file and start the daemon with the _/_v_a_r_/_d_c_c_/_l_i_b_e_x_e_c_/_s_t_a_r_t_-_d_c_c_m or _v_a_r_/_d_c_c_/_l_i_b_e_x_e_c_/_r_c_D_C_C script. The list of servers that ddccccmm contacts is in the memory mapped file _m_a_p shared by local DCC clients. The file is maintained with cdcc(8). OOPPTTIIOONNSS The following options are available: --VV displays the version of ddccccmm. --dd enables debugging output from the DCC client software. Additional --dd options increase the number of messages. A single --dd aborted SMTP transactions including those from some "dictionary attacks." --bb causes the daemon to not detach itself from the controlling tty and put itself into the background. --xx causes the daemon to try "extra hard" to contact a DCC server. Since it is usually more important to deliver mail than to report its checksums, ddccccmm normally does not delay too long while trying to contact a DCC server. It will not try again for several seconds after a failure. With --xx, it will always try to contact the DCC server and it will tell the MTA to answer the DATA command with a 4yz temporary failure. --AA adds to existing X-DCC headers in the message instead of replacing existing headers of the brand of the current server. --NN neither adds, deletes, nor replaces existing X-DCC headers in the message. Each message is logged, rejected, and otherwise handled the same. --QQ only queries the DCC server about the checksums of messages instead of reporting and querying. This is useful when ddccccmm is used to fil- ter mail that has already been reported to a DCC server by another DCC client. No single mail message should be reported to a DCC server more than once per recipient, because each report will increase the apparent "bulkness" of the message. It is better to use _M_X_D_C_C lines in the global _w_h_i_t_e_c_l_n_t file for your MX mail servers that use DCC than --QQ. --GG _o_n | _o_f_f | _n_o_I_P | _I_P_m_a_s_k_/_x_x controls _g_r_e_y_l_i_s_t_i_n_g. At least one working greylist server must be listed in the _m_a_p file in the DCC home directory. If more than one is named, they must "flood" or change checksums and they must use the same --GG parameters. See dccd(8). Usually all dccm or dccifd DCC client processes use the same --GG parameters. _I_P_m_a_s_k_/_x_x and _n_o_I_P remove part or all of the IP address from the greylist triple. The CIDR block size, _x_x, must be between 1 and 128. 96 is added to block sizes smaller than 33 to make them appro- priate for the IPv6 addresses used by the DCC. _I_P_m_a_s_k_/_9_6 differs from _n_o_I_P for IPv4 addresses, because the former retains the IPv4 to IPv6 mapping prefix. --hh _h_o_m_e_d_i_r overrides the default DCC home directory, _/_v_a_r_/_d_c_c. --II _u_s_e_r specifies the UID and GID of the process. --pp _p_r_o_t_o_c_o_l_:_f_i_l_e_n_a_m_e | _p_r_o_t_o_c_o_l_:_p_o_r_t_@_h_o_s_t specifies the protocol and address by which sendmail will contact ddccccmm. The default is a UNIX domain socket in the "run" directory, _/_v_a_r_/_r_u_n_/_d_c_c_/_d_c_c_m. (See also --RR)) This protocol and address must match the value in _s_e_n_d_m_a_i_l_._c_f. This mechanism can be used to con- nect ddccccmm on one computer to sendmail on another computer when a port and host name or IP address are used. --mm _m_a_p specifies a name or path of the memory mapped parameter file instead of the default _m_a_p file in the DCC home directory. It should be created with the cdcc(8) command. --ww _w_h_i_t_e_c_l_n_t specifies an optional file containing filtering parameters as well as SMTP client IP addresses, SMTP envelope values, and header values of mail that is spam or is not spam and does not need a _X_-_D_C_C header, and whose checksums should not be reported to the DCC server. If the pathname _w_h_i_t_e_c_l_n_t is not absolute, it is relative to the DCC home directory. The format of the ddccccmm whiteclnt file is the same as the _w_h_i_t_e_l_i_s_t files used by dbclean(8) and the _w_h_i_t_e_c_l_n_t file used by dccproc(8). See dcc(8) for a description of DCC white and blacklists. Because the contents of the _w_h_i_t_e_c_l_n_t file are used frequently, a companion file is automatically created and maintained. It has the same path- name but with an added suffix of _._d_c_c_w and contains a memory mapped hash table of the main file. A whitelist entry ("OK") or two or more semi-whitelistings ("OK2") for one of the message's checksums prevents all of the message's checksums from being reported to the DCC server and the addition of a _X_-_D_C_C header line by ddccccmm A whitelist entry for a checksum also prevents rejecting or discarding the message based on DCC recipient counts as specified by --aa and --tt. Otherwise, one or more checksums with blacklisting entries ("MANY") cause all of the message's check- sums to be reported to the server with an addressee count of "MANY". If the message has a single recipient, an _e_n_v___T_o _w_h_i_t_e_c_l_n_t entry of "OK" for the checksum of its recipient address acts like any other _w_h_i_t_e_c_l_n_t entry of "OK." When the SMTP message has more than one recipient, the effects can be complicated. When a message has sev- eral recipients with some but not all listed in the _w_h_i_t_e_c_l_n_t file, ddccccmm tries comply with the wishes of the users who want filtering as well as those who don't by silently not delivering the message to those who want filtering (i.e. are not whitelisted) and delivering the message to don't want filtering. --UU _u_s_e_r_d_i_r_s enables per-user _w_h_i_t_e_c_l_n_t files and log directories. Each target of a message can have a directory of log files named _u_s_e_d_i_r_s_/_$_{_d_c_c___u_s_e_r_d_i_r_}_/_l_o_g where _$_{_d_c_c___u_s_e_r_d_i_r_} is the _s_e_n_d_m_a_i_l_._c_f macro described below. If _$_{_d_c_c___u_s_e_r_d_i_r_} is not set, _u_s_e_r_d_i_r_s_/_$_{_r_c_p_t___m_a_i_l_e_r_}_/_$_{_r_c_p_t___a_d_d_r_}_/_l_o_g is used. The most likely value of _m_a_i_l_e_r is _l_o_c_a_l. Appropriate values for both _$_{_r_c_p_t___m_a_i_l_e_r_} and _$_{_r_c_p_t___a_d_d_r_} can be seen by examining _e_n_v___T_o lines in --ll _l_o_g_d_i_r files. If it is not absolute, _u_s_e_r_d_i_r_s is rela- tive to the DCC home directory. The directory containing the log files must be named _l_o_g and it must be writable by the ddccccmm process. Each log directory must exist or logging for the corresponding is silently disabled. The files created in the log directory are owned by the UID of the ddccccmm process, but they have _g_r_o_u_p and _o_t_h_e_r read and write permissions copied from the corresponding _l_o_g directory. To ensure the privacy of mail, it may be good to make the directo- ries readable only by _o_w_n_e_r and _g_r_o_u_p, and to use a cron script that changes the owner of each file to match the grandparent _a_d_d_r direc- tory. There can also be a per -user whitelist file named _u_s_e_r_d_i_r_s_/_$_{_d_c_c___u_s_e_r_d_i_r_}_/_w_h_i_t_e_c_l_n_t or if _$_{_d_c_c___u_s_e_r_d_i_r_} is not set, _u_s_e_r_d_i_r_s_/_$_{_r_c_p_t___m_a_i_l_e_r_}_/_$_{_r_c_p_t___a_d_d_r_} per-user whitelist files. Any checksum that is not white- or blacklisted by an individual addressee's _w_h_i_t_e_c_l_n_t file is checked in the main --ww --wwhhiitteeccllnntt file. A missing per-addressee _w_h_i_t_e_c_l_n_t file is the same as an empty file. Relative paths for files included in per-addressee files are resolved in the DCC home directory. The _w_h_i_t_e_c_l_n_t files and the _a_d_d_r directories containing them must be writable by the ddccccmm process. _O_p_t_i_o_n lines in per-user whiteclnt files can be used to modify many aspects of ddccccmm filtering, as described in the main dcc man page. For example, an _o_p_t_i_o_n _d_c_c_-_o_f_f line turns off DCC filtering for individual mailboxes. --aa _I_G_N_O_R_E | _R_E_J_E_C_T | _D_I_S_C_A_R_D specifies the action taken when DCC server counts or --tt thresholds say that a message is unsolicited and bulk. _I_G_N_O_R_E causes the mes- sage to be unaffected except for adding the _X_-_D_C_C header line to the message. This turns off DCC filtering. Spam can also be _R_E_J_E_C_Ted or accepted and silently _D_I_S_C_A_R_Ded without being delivered to local mailboxes. The default is _R_E_J_E_C_T. Mail forwarded via IP addresses marked _M_X or _M_X_D_C_C in the main _w_h_i_t_e_c_l_n_t file is treated as if --aa _D_I_S_C_A_R_D were specified. This prevents "bouncing" spam. Determinations that mail is or is not spam from sendmail via _$_{_d_c_c___i_s_s_p_a_m_} or _$_{_d_c_c___n_o_t_s_p_a_m_} macros override --aa. The effects of the --ww _w_h_i_t_e_c_l_n_t are not affected by --aa. --tt _t_y_p_e_,[_l_o_g_-_t_h_o_l_d_,]_r_e_j_-_t_h_o_l_d sets logging and "spam" thresholds for checksum _t_y_p_e. The checksum types are _I_P, _e_n_v___F_r_o_m, _F_r_o_m, _M_e_s_s_a_g_e_-_I_D, _s_u_b_s_t_i_t_u_t_e, _R_e_c_e_i_v_e_d, _B_o_d_y, _F_u_z_1, _F_u_z_2, _r_e_p_-_t_o_t_a_l, and _r_e_p. The first six, _I_P through _s_u_b_s_t_i_t_u_t_e, have no effect except when a local DCC server configured with --KK is used. The _s_u_b_s_t_i_t_u_t_e thresholds apply to the first sub- stitute heading encountered in the mail message. The string _A_L_L sets thresholds for all types, but is unlikely to be useful except for setting logging thresholds. The string _C_M_N specifies the com- monly used checksums _B_o_d_y, _F_u_z_1, and _F_u_z_2. _R_e_j_-_t_h_o_l_d and _l_o_g_-_t_h_o_l_d must be numbers, the string _N_E_V_E_R, or the string _M_A_N_Y indicating millions of targets. Counts from the DCC server as large as the threshold for any single type are taken as sufficient evidence that the message should be logged or rejected. _L_o_g_-_t_h_o_l_d is the threshold at which messages are logged. It can be handy to log messages at a lower threshold to find solicited bulk mail sources such as mailing lists. If no logging threshold is set, only rejected mail and messages with complicated combinations of white and blacklisting are logged. Messages that reach at least one of their rejection thresholds are logged regardless of logging thresholds. _R_e_j_-_t_h_o_l_d is the threshold at which messages are considered "bulk," and so should be rejected or discarded if not whitelisted. DCC Reputation thresholds in the commercial version of the DCC are controlled by thresholds on checksum types _r_e_p and _r_e_p_-_t_o_t_a_l. Mes- sages from an IP address that the DCC database says has sent more than --tt _r_e_p_-_t_o_t_a_l_,_l_o_g_-_t_h_o_l_d messages are logged. A DCC Reputation is computed for messages received from IP addresses that have sent more than --tt _r_e_p_-_t_o_t_a_l_,_l_o_g_-_t_h_o_l_d messages. The DCC Reputation of an IP address is the percentage of its messages that have been detected as bulk or having at least 10 recipients. The defaults are equiva- lent to --tt _r_e_p_,_n_e_v_e_r and --tt _r_e_p_-_t_o_t_a_l_,_n_e_v_e_r_,_2_0. Bad DCC Reputations do not reject mail unless enabled by an _o_p_t_i_o_n _D_C_C_-_r_e_p_-_o_n line in a _w_h_i_t_e_c_l_n_t file. The checksums of locally whitelisted messages are not checked with the DCC server and so only the number of targets of the current copy of a whitelisted message are compared against the thresholds. The default is _A_L_L_,_N_E_V_E_R, so that nothing is discarded, rejected, or logged. A common choice is _C_M_N_,_2_5_,_5_0 to reject or discard mail with common bodies except as overridden by the whitelist of the DCC server, the sendmail _$_{_d_c_c___i_s_s_p_a_m_} and _$_{_d_c_c___n_o_t_s_p_a_m_} macros, and --gg, and --ww. --gg [_n_o_t_-]_t_y_p_e indicates that whitelisted, _O_K or _O_K_2, counts from the DCC server for a type of checksum are to be believed. They should be ignored if prefixed with _n_o_t_-. _T_y_p_e is one of the same set of strings as for --tt. Only _I_P, _e_n_v___F_r_o_m, and _F_r_o_m are likely choices. By default all three are honored, and hence the need for _n_o_t_-. --SS _h_d_r adds to the list of substitute or locally chosen headers that are checked with the --ww _w_h_i_t_e_c_l_n_t file and sent to the DCC server. The checksum of the last header of type _h_d_r found in the message is checked. _H_d_r can be _H_E_L_O to specify the SMTP envelope HELO value. _H_d_r can also be _m_a_i_l___h_o_s_t to specify the sendmail "resolved" host name from the Mail_from value in the SMTP envelope. As many as six different substitute headers can be specified, but only the checksum of the first of the six will be sent to the DCC server. --ll _l_o_g_d_i_r specifies a directory in which files containing copies of messages processed by ddccccmm are kept. They can be copied to per-user directo- ries specified with --UU. Information about other recipients of a message is deleted from the per-user copies. See the FILES section below concerning the contents of the files. See also the _o_p_t_i_o_n _l_o_g_-_s_u_b_d_i_r_e_c_t_o_r_y_-_{_d_a_y_,_h_o_u_r_,_m_i_n_u_t_e_} lines in _w_h_i_t_e_c_l_n_t files described in dcc(8). The directory is relative to the DCC home directory if it is not absolute --RR _r_u_n_d_i_r specifies the "run" directory where the UNIX domain socket and file containing the daemon's process ID are stored. The default value is /var/run/dcc . --rr _r_e_j_e_c_t_i_o_n_-_m_s_g specifies the rejection message in --oo proxy mode for unsolicited bulk mail or for mail temporarily blocked by _g_r_e_y_l_i_s_t_i_n_g when --GG is specified. The first --rr _r_e_j_e_c_t_i_o_n_-_m_s_g replaces the default bulk mail rejection message, "5.7.1 550 mail %ID from %CIP rejected by DCC". The second replaces "4.2.1 452 mail %ID from %CIP temporary greylist embargoed". The third --rr _r_e_j_e_c_t_i_o_n_-_m_s_g replaces the default SMTP rejection message "5.7.1 550 %ID bad reputation; see http://commercial-dcc.rhyolite.com/cgi-bin/reps.cgi?tgt=%CIP" for mail with bad DCC Reputations. If _r_e_j_e_c_t_i_o_n_-_m_s_g is the zero-length string, the --rr setting is counted but the corresponding message is not changed. _R_e_j_e_c_t_i_o_n_-_m_s_g can contain specific information about the mail mes- sage. The following strings starting with % are replaced with the corresponding values: %ID message ID such as the unique part of log file name or sendmail queue ID %CIP SMTP client IP address %BTYPE type of DNS blacklist hit, such as "SMTP client", "mail_host", or "URL NS" %BTGT IP address or name declared bad by DNS blacklist %BPROBE domain name found in DNS blacklist such as 4.3.2.10.example.com %BRESULT value of the %BPROBE domain name found in DNS black- list A common alternate for the bulk mail rejection message is "4.7.1 451 Access denied by DCC" to tell the sending mail system to continue trying. Use a 4yz response with caution, because it is likely to delay for days a delivery failure message for false positives. If the rejection message does not start with an RFC 1893 status code and RFC 2821 reply code, 5.7.1 and 550 or 4.2.1 and 452 are used. See also --BB _s_e_t_:_r_e_j_-_m_s_g_=_r_e_j_e_c_t_i_o_n_-_m_s_g to set the status message for mail rejected by DNS blacklists. --jj _m_a_x_j_o_b_s limits the number of simultaneous requests that will be processed. The default value is the maximum number that seems to be possible given system limits on open files, select() bit masks, and so forth. Start ddccccmm with --dd and see the starting message in the system log to see the limit. --BB _d_n_s_b_l_-_o_p_t_i_o_n enables DNS blacklist checks of the SMTP client IP address, SMTP envelope Mail_From sender domain name, and of host names in URLs in the message body. Body URL blacklisting has too many false posi- tives to use on abuse mailboxes. It is less effective than greylisting with dccm(8) or dccifd(8) but can be useful in situa- tions where greylisting cannot be used. _D_n_s_b_l_-_o_p_t_i_o_n is either one of the --BB _s_e_t_:_o_p_t_i_o_n forms or --BB _d_o_m_a_i_n[_,_I_P_a_d_d_r[_/_x_x[_,_b_l_t_y_p_e]]] _D_o_m_a_i_n is a DNS blacklist domain such as example.com that will be searched. _I_P_a_d_d_r[_/_x_x_x] is the string "any" an IP address in the DNS blacklist that indicates that the mail message should be rejected, or a CIDR block covering results from the DNS blacklist. "127.0.0.2" is assumed if _I_P_a_d_d_r is absent. IPv6 addresses can be specified with the usual colon (:) notation. Names can be used instead of numeric addresses. The type of DNS blacklist is speci- fied by _b_l_t_y_p_e as _n_a_m_e, _I_P_v_4, or _I_P_v_6. Given an envelope sender domain name or a domain name in a URL of spam.domain.org and a blacklist of type _n_a_m_e, spam.domain.org.example.com will be tried. Blacklist types of _I_P_v_4 and _I_P_v_6 require that the domain name in a URL sender address be resolved into an IPv4 or IPv6 address. The address is then written as a reversed string of decimal octets to check the DNS blacklist, as in 2.0.0.127.example.com, More than one blacklist can be specified and blacklists can be grouped. All searching within a group is stopped at the first posi- tive result. Positive results are ignored after being logged unless an _o_p_t_i_o_n _D_N_S_B_L_-_o_n line appears in the global or per-user _w_h_i_t_e_c_l_n_t file. --BB _s_e_t_:_n_o_-_c_l_i_e_n_t says that SMTP client IP addresses and reverse DNS domain names should not be checked in the following blacklists. --BB _s_e_t_:_c_l_i_e_n_t restores the default for the following black- lists. --BB _s_e_t_:_n_o_-_m_a_i_l___h_o_s_t says that SMTP envelope Mail_From sender domain names should not be checked in the following blacklists. --BB _s_e_t_:_m_a_i_l___h_o_s_t restores the default. --BB _s_e_t_:_n_o_-_U_R_L says that URLs in the message body should not be checked in the in the following blacklists. --BB _s_e_t_:_U_R_L restores the default. --BB _s_e_t_:_n_o_-_M_X says MX servers of sender Mail_From domain names and host names in URLs should not be checked in the following blacklists. --BB _s_e_t_:_M_X restores the default. --BB _s_e_t_:_n_o_-_N_S says DNS servers of sender Mail_From domain names and host names in URLs should not be checked in the following black- lists. --BB _s_e_t_:_N_S restores the default. --BB _s_e_t_:_d_e_f_a_u_l_t_s is equivalent to all of --BB _s_e_t_:_n_o_-_t_e_m_p_-_f_a_i_l --BB _s_e_t_:_c_l_i_e_n_t --BB _s_e_t_:_m_a_i_l___h_o_s_t --BB _s_e_t_:_U_R_L --BB _s_e_t_:_M_X and --BB _s_e_t_:_N_S --BB _s_e_t_:_g_r_o_u_p_=_X adds later DNS blacklists specified with --BB _d_o_m_a_i_n[_,_I_P_a_d_d_r[_/_x_x[_,_b_l_t_y_p_e]]] to group 1, 2, or 3. --BB _s_e_t_:_d_e_b_u_g_=_X sets the DNS blacklist logging level --BB _s_e_t_:_m_s_g_-_s_e_c_s_=_S limits ddccccmm to _S seconds total for checking all DNS blacklists. The default is 25. --BB _s_e_t_:_U_R_L_-_s_e_c_s_=_S limits ddccccmm to at most _S seconds resolving and checking any single URL. The default is 11. Some spam contains dozens of URLs and that some "spamvertised" URLs contain host names that need minutes to resolve. Busy mail systems cannot afford to spend minutes checking each incoming mail message. --BB _s_e_t_:_r_e_j_-_m_s_g_=_r_e_j_e_c_t_i_o_n_-_m_s_g sets the SMTP rejection message for the following blacklists. _R_e_j_e_c_t_i_o_n_-_m_s_g must be in the same format as for --rr. If _r_e_j_e_c_t_i_o_n_-_m_s_g is null, the default is restored. The default DNS blacklist rejection message is the first message set with --rr. --BB _s_e_t_:_t_e_m_p_-_f_a_i_l causes ddccccmm to the MTA to answer the SMTP DATA command with 452 4.2.1 mail %ID from %CIP temporary delayed for DNSBL if any DNS answer required for a DNSBL in the current group times out, including resolving names in URLs. --BB _s_e_t_:_n_o_-_t_e_m_p_-_f_a_i_l restores the default of assuming a negative answer for DNS responses that take too long. --BB _s_e_t_:_m_a_x_j_o_b_s_=_X sets maximum number of helper processes to _X. In order to use typical single-threaded DNS resolver libraries, ddccccmm uses fleets of helper processes. It is rarely a good idea to change the default, which is the same as the maximum number of simul- taneous jobs set with --jj. --BB _s_e_t_:_p_r_o_g_p_a_t_h_=_/_v_a_r_/_d_c_c_/_l_i_b_e_x_e_c_/_d_n_s_-_h_e_l_p_e_r changes the path to the helper program. --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, _i_n_f_o, or _o_f_f to indicate which of the two types of messages are being con- trolled or to turn off all syslog(3) messages from ddccccmm. _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 --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 ddccccmm normally sends counts of mail rejected and so forth the to system log at midnight. The SIGUSR1 signal sends an immediate report to the system log. They will be repeated every 24 hours instead of at midnight. SSEENNDDMMAAIILL MMAACCRROOSS Sendmail can affect ddccccmm with the values of some _s_e_n_d_m_a_i_l_._c_f macros. These macro names must be added to the Milter.macros option statements in _s_e_n_d_m_a_i_l_._c_f as in the example "Feature" file dcc.m4. _$_{_d_c_c___i_s_s_p_a_m_} causes a mail message to be reported to the DCC server as having been addressed to "MANY" recipients. The _$_{_d_c_c___i_s_s_p_a_m_} macro is ignored if the _$_{_d_c_c___n_o_t_s_p_a_m_} macro is set to a non-null string If the value of the _$_{_d_c_c___i_s_s_p_a_m_} is null, ddccccmm uses SMTP rejection messages controlled by --aa and --rr. If the value of the _$_{_d_c_c___i_s_s_p_a_m_} macro starts with "DISCARD", the mail message is silently discarded as with --aa _D_I_S_C_A_R_D_. If value of the macro not null and does not start with "DISCARD", it is used as the SMTP error message given to the SMTP client trying to send the rejected message. The message starts with an optional SMTP error type and number fol- lowed by text. The --aa option does not effect messages marked spam with _$_{_d_c_c___i_s_s_p_a_m_}. When the _$_{_d_c_c___i_s_s_p_a_m_} macro is set, the message is rejected or discarded despite local or DCC database whitelist entries. The local whitelist does con- trol whether the message's checksums will be reported to the DCC server and an _X_-_D_C_C SMTP header line will be added. _$_{_d_c_c___n_o_t_s_p_a_m_} causes a message not be considered unsolicited bulk despite evidence to the contrary. It also prevents ddccccmm from reporting the checksums of the message to the DCC server and from adding an _X_-_D_C_C header line. When the macro is set by the _s_e_n_d_m_a_i_l_._c_f rules, _$_{_d_c_c___n_o_t_s_p_a_m_} macros overrides DCC threshlds that say the message should be rejected as well as the effects of the _$_{_d_c_c___i_s_s_p_a_m_} macro. _$_{_d_c_c___m_a_i_l___h_o_s_t_} specifies the name of the SMTP client that is sending the message. This macro is usually the same as the _m_a_i_l___h_o_s_t macro. They can differ when a sendmail "smart relay" is involved. The _$_{_d_c_c___m_a_i_l___h_o_s_t_} macro does not work if _F_E_A_T_U_R_E_(_d_e_l_a_y___c_h_e_c_k_s_) is used. _$_{_d_c_c___u_s_e_r_d_i_r_} is the per-user whitelist and log directory for a recipi- ent. If the macro is not set in sendmail.cf, $&{rcpt_mailer}/$&{rcpt_addr} is assumed, but with the recipient address converted to lower case. Whatever value is used, the directory name after the last slash (/) char- acter is converted to lower case. Any value containing the string "/../" is ignored. This macro also does not work if _F_E_A_T_U_R_E_(_d_e_l_a_y___c_h_e_c_k_s_) is used. The following two lines in a sendmail mc file have the same effect as not defining the ${dcc_userdir} macro, pro- vided _F_E_A_T_U_R_E_(_d_c_c_) is also used and the sendmail _c_f_/_f_e_a_t_u_r_e directory has a symbolic link to the _m_i_s_c_/_d_c_c_._m_4 file. SLocal_check_rcpt R$* $: $1 $(macro {dcc_userdir} $@ $&{rcpt_mailer}/$&{rcpt_addr} $)) FFIILLEESS /var/dcc is the DCC home directory in which other files are found. /var/dcc/libexec/start-dccm is a script used to ddccccmm. dcc/dcc_conf contains parameters used by the scripts to start DCC daemons and cron jobs. logdir is an optional directory specified with --ll and containing marked mail. Each file in the directory contains one message, at least one of whose checksums reached its --tt thresholds or that is interesting for some other reason. Each file starts with lines containing the date when the message was received, the IP address of the SMTP client, and SMTP envelope values. Those lines are followed by the body of the SMTP message including its header as it was received by sendmail and with- out any new or changed header lines. Only approximately the first 32 KBytes of the body are recorded unless modified by _._/_c_o_n_f_i_g_u_r_e _-_-_w_i_t_h_-_m_a_x_-_l_o_g_-_s_i_z_e_=_x_x The checksums for the mes- sage follow the body. They are followed by lines indicating that the _$_{_d_c_c___i_s_s_p_a_m_} or _$_{_d_c_c___n_o_t_s_p_a_m_} _s_e_n_d_m_a_i_l_._c_f macros were set or one of the checksums is white- or blacklisted by the --ww _w_h_i_t_e_c_l_n_t file. Each file ends with the _X_-_D_C_C header line added to the message and the disposition of the message including SMTP status message if appropriate. map is the memory mapped file of information concerning DCC servers in the DCC home directory. whiteclnt contains the client whitelist in the format described in dcc(8). whiteclnt.dccw is a memory mapped hash table of the _w_h_i_t_e_c_l_n_t file. dccm.pid in the --RR _r_u_n_d_i_r directory contains daemon's process ID. The string ``dccm'' is replaced by the file name containing the daemon to facilitate running multiple daemons, probably con- nected to remote instances of sendmail using TCP/IP instead of a UNIX domain socket. See also --RR. /var/run/dcc/dccm is the default UNIX domain socket used by the sendmail milter interface. See also --RR. sendmail.cf is the sendmail(8) control file. misc/dcc.m4 sendmail mc file that should have a symbolic link in the send- mail cf/feature directory so that _F_E_A_T_U_R_E_(_d_c_c_) can be used in a sendmail mc file. EEXXAAMMPPLLEESS DDccccmm should be started before sendmail with something like the script _/_v_a_r_/_d_c_c_/_l_i_b_e_x_e_c_/_s_t_a_r_t_-_d_c_c_m_. It looks for common DCC parameters in the _d_c_c___c_o_n_f file in the DCC home directory, _/_v_a_r_/_d_c_c_. Those numbers should modified to fit local conditions. It might be wise to replace the "100" numbers with much larger values or with "MANY" until a few weeks of monitoring the log directory show that sources of mailing lists are in the server's whitelist file (see dccd(8)) or the local _w_h_i_t_e_c_l_n_t file. It is usually necessary to regularly delete old log files with a script like /var/dcc/libexec/cron-dccd. On systems unlike modern FreeBSD and other UNIX-like systems which include sendmail milter support, sendmail must be built with the milter interface, such as by creating a _d_e_v_t_o_o_l_s_/_S_i_t_e_/_s_i_t_e_._c_o_n_f_i_g_._m_4 or similar file containing something like the following lines: APPENDDEF(`conf_sendmail_ENVDEF', `-D_FFR_MILTER=1') APPENDDEF(`conf_libmilter_ENVDEF', `-D_FFR_MILTER=1') Appropriate lines invoking the milter interface must be added to _s_e_n_d_m_a_i_l_._c_f_. That can be done by putting a symbolic link to the the misc/dcc.m4 file in the DCC source to the sendmail cf/feature directory and adding the line FEATURE(dcc) to the local .mc file. Note that ddccccmm should not be used with the Postfix milter mechanism. Instead use dccifd(8) as a before-queue filter as described in that man page. SSEEEE AALLSSOO cdcc(8), dbclean(8), dcc(8), dccd(8), dblist(8), dccifd(8), dccproc(8), dccsight(8), sendmail(8). HHIISSTTOORRYY Distributed Checksum Clearinghouses are based on an idea of Paul Vixie. Implementation of ddccccmm was started at Rhyolite Software in 2000. This document describes version 1.3.103. BBUUGGSS ddccccmm uses --tt where dccproc(8) uses --cc. Systems without setrlimit(2) and getrlimit(2) RLIMIT_NOFILE can have problems with the default limit on the number of simultaneous jobs, the value of --jj. Every job requires four open files. These problems are usually seen with errors messages that say something like dccm[24448]: DCC: accept() returned invalid socket A fix is to use a smaller value for --jj or to allow ddccccmm to open more files. Sendmail version 8.13 and later can be told to poll() instead of select with SM_CONF_POLL. Some older versions of sendmail knew about FFR_USE_POLL. One of the following lines in your devtools/Site/site.con- fig.m4 file can help: APPENDDEF(`conf_libmilter_ENVDEF', `-DSM_CONF_POLL') APPENDDEF(`conf_libmilter_ENVDEF', `-DFFR_USE_POLL') On many systems with sendmail 8.11.3 and preceding, a bug in the sendmail milter mechanism causes ddccccmm to die with a core file when given a signal. February 26, 2009