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 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. The list of servers that ddccccmm contacts is in a memory mapped file shared by local DCC clients. The file is maintained with cdcc(8). Put parame- ters into the _d_c_c___c_o_n_f file and start the daemon with the _s_t_a_r_t_-_d_c_c_m script. When sendmail is not used, then ddccccmm is not useful. dccproc(8) or dccifd(8) can often be used instead. OOPPTTIIOONNSS The following options are available: --VV displays the version of the DCC Milter interface. --dd enables debugging output from the DCC client library. 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, unresponsive DCC servers cause mail to be temporarily rejected with _4_._7_._1 _4_5_1 _D_C_C _f_a_i_l_u_r_e --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 servers --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 because the former retains the IPv4 to IPv6 mapping pre- fix. --hh _h_o_m_e_d_i_r overrides the default DCC home directory, which is often /var/dcc. --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, often _/_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 connect 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 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 default setting of --ww _w_h_i_t_e_c_l_n_t should almost never be changed. 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 white-list entry ("OK") or two or more semi-white-listings ("OK2") for 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 (except for env_To checksums). A white-listing entry for a checksum also prevents rejecting or discarding the mes- sage based on DCC recipient counts as specified by --aa and --tt. Oth- erwise, one or more checksums with blacklisting entries ("MANY") cause all of the message's checksums to be reported to the server with an addressee count of "MANY". White-list _e_n_v___T_o values are handy for white-listing or exempting destination addresses such as Postmaster from filtering and for mak- ing "spam traps" of addresses that should never receive mail. First an entry for the official envelope _R_c_p_t _T_o value is sought. If that is not found, ddccccmm looks for an entry for the sendmail "user" string. Mail sent to blacklisted addresses or with other black- listed values such as From or env_From values is reported to the DCC server as spam or with target counts of millions. 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 white-listed) and delivering the message to don't want filtering. Consider an _o_p_t_i_o_n _d_c_c_-_o_f_f line in per-user whiteclnt files to turn off DCC filtering for individual mailboxes. --UU _u_s_e_r_d_i_r_s enables per-user _w_h_i_t_e_c_l_n_t and log files. 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. If it is not absolute, _u_s_e_r_d_i_r_s is relative to the DCC home directory. The sub-directory prefixes for --ll _l_o_g_d_i_r are not honored. 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 permis- sions copied from the corresponding _l_o_g directory. To ensure the privacy of mail, it may be good to make the directories 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 directory. There can also be _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. The name of each file must be _w_h_i_t_e_c_l_n_t. Every checksum including the _e_n_v___t_o and sendmail "user" values are looked for first in the userdirs/mailer/addr/whiteclnt and list then in the global --ww _w_h_i_t_e_c_l_n_t list. A missing per-address _w_h_i_t_e_c_l_n_t file is the same as an empty file. Relative paths for whitelists included in per-address whiteclnt 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. The most likely value of _m_a_i_l_e_r is _l_o_c_a_l. Appropriate values for both _m_a_i_l_e_r and _a_d_d_r can be seen by examining _e_n_v___T_o lines in --ll _l_o_g_d_i_r files. --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 bulk. _I_G_N_O_R_E causes the message to be unaffected except for adding the _X_-_D_C_C header line to the mes- sage. 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 with- out 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. With an action of _R_E_J_E_C_T or _D_I_S_C_A_R_D, spam sent to both white-listed targets and non-white-listed targets is delivered to white-listed targets and if possible, silently discarded for non-white-listed targets. This is not possible if there are too many non-white- listed targets to be saved in a buffer of about 500 bytes. 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 also 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 discard if not white-listed. Use --aa _R_E_J_E_C_T or --aa _D_i_s_c_a_r_d to reject or discard bulk mail that is not white-listed. Use --aa _I_G_N_O_R_E _t_o only add X-DCC headers with the "bulk" or "bulk rep" string. 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 _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 _r_e_p_-_t_o_t_a_l _r_e_j_-_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 equivalent 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_,_1_0. Bad DCC reputations do not reject mail unless enabled by an _o_p_t_i_o_n _D_C_C_-_r_e_p_s_-_o_n line in the --ww or the whiteclnt file in the user's --UU directory. The checksums of locally white-listed messages are not checked with the DCC server and so only the number of targets of the current copy of a white-listed message are compared against the thresholds. The default is --tt _A_L_L_,_N_E_V_E_R, so that nothing is discarded or logged. A common choice is --tt _C_M_N_,_2_5_,_5_0 to reject or discard mail with com- mon 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 white-listed, _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 6 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. If _l_o_g_d_i_r starts with _D_?, log files are put into subdirectories of the form _l_o_g_d_i_r_/_J_J_J where _J_J_J is the current julian day. _H_?_l_o_g_d_i_r puts logs files into subdirectories of the form _l_o_g_d_i_r_/_J_J_J_/_H_H where _H_H is the current hour. _M_?_l_o_g_d_i_r puts log files into subdirectories of the form _l_o_g_d_i_r_/_J_J_J_/_H_H_/_M_M where _M_M is the current minute. 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 often /var/run/dcc. --rr _r_e_j_e_c_t_i_o_n_-_m_s_g specifies the rejection message 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 mes- sage, "5.7.1 550 mail %s from %s rejected by DCC". The second replaces "4.2.1 452 mail %s from %s temporary greylist embargoed". The third --rr _r_e_j_e_c_t_i_o_n_-_m_s_g replaces the default SMTP rejection mes- sage "5.7.1 550 %s bad reputation; see http://commercial-dcc.rhyo- lite.com/cgi-bin/reps.cgi?tgt=%s" 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. There can be up to two "%s" strings. The first %s is replaced by the sendmail queue ID and the second is replaced by the IP address of the SMTP client. 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 blacklist. --jj _m_a_x_j_o_b_s limits the number of simultaneous requests from sendmail that will be processed. The default value of _m_a_x_j_o_b_s is the maximum number that seems to be possible given the number of open files, select() bit masks, and so forth that are available, but at most 200. Start dccm 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 of the forms _s_e_t_:_o_p_t_i_o_n or _d_o_m_a_i_n[_,_I_P_a_d_d_r[_,_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 is the string "any" or the IP address in the DNS blacklist that indicates that the mail message is spam. 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 specified 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 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. They are searched in order. All searching is stopped at the first positive 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_:_d_e_b_u_g_=_X sets the DNS blacklist logging level --BB _s_e_t_:_m_a_x_j_o_b_s_=_X sets maximum number of helper processes. It is rarely a good idea to change the default, which is the same as the maximum number of simultaneous jobs set with --jj --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. In order to use typical single-threaded DNS resolver libraries, dccm(8) and dccifd(8) use fleets of helper processes. --BB _s_e_t_:_n_o_-_e_n_v_e_l_o_p_e says that SMTP client IP addresses and sender Mail_From domain names should not be checked in the following blacklists. _s_e_t_:_e_n_v_e_l_o_p_e restores the default for subsequently named black- lists. --BB _s_e_t_:_n_o_-_b_o_d_y says that URLs in the message body should not be checked in the in the following blacklists. _s_e_t_:_b_o_d_y restores the default for later blacklists. --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. _s_e_t_:_M_X restores the default. --BB _s_e_t_:_n_o_-_N_S says NS servers of sender Mail_From domain names and host names in URLs should not be checked in the following blacklists. _s_e_t_:_N_S restores the default. --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 the zero length string, the default is restored. The default DNS blacklist rejection message is the first message set with --rr. --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 default path to the helper process. --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 --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_. This can be handy for keeping "spammers" from knowing they are sending to "spam traps." 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 followed 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 white-list entries. The local white-list does control 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. libexec/start-dccm is a script often used to the daemon. 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 libexec/start-dccm. It looks for common DCC parameters in the _d_c_c___c_o_n_f file in the DCC home directory. 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 libexec/cron-dccd. 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_. It should be sufficient to copy the dcc.m4 file to the send- mail 8.11 cf/feature directory and add the line FEATURE(dcc) to the local .mc file. SSEEEE AALLSSOO cdcc(8), dbclean(8), dcc(8), dccd(8), dblist(8), dccifd(8), dccproc(8), dccsight(8), sendmail(8). HHIISSTTOORRYY Implementation of ddccccmm was started at Rhyolite Software in 2000. This describes version 1.3.50. 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 5, 2007