User Commands ezmlm-send(1) NNNNAAAAMMMMEEEE ezmlm-send - distribute a message to a mailing list SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS eeeezzzzmmmmllllmmmm----sssseeeennnndddd [ -aaaaAAAAccccCCCCrrrrRRRRvvvvVVVV ] [ -hhhh _h_e_a_d_e_r ] _d_i_r DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN eeeezzzzmmmmllllmmmm----sssseeeennnndddd reads a mail message and sends it to the mailing list stored in _d_i_r. If _d_i_r////aaaarrrrcccchhhhiiiivvvveeeedddd exists, eeeezzzzmmmmllllmmmm----sssseeeennnndddd records a copy of the message in the _d_i_r////aaaarrrrcccchhhhiiiivvvveeee//// directory. If _d_i_r////iiiinnnnddddeeeexxxxeeeedddd exists, eeeezzzzmmmmllllmmmm----sssseeeennnndddd adds the subject, author and time stamp of the message to the index, kept with the message in a subdirectory of _d_i_r////aaaarrrrcccchhhhiiiivvvveeee////. The subject is processed to make reply-subject entries identical to origi- nal message subject entries. The subject index is used for the archive retrieval functions of eeeezzzzmmmmllllmmmm----ggggeeeetttt((((1111)))). Use eeeezzzzmmmmllllmmmm----iiiiddddxxxx((((1111)))) to create a subject index from a preexisting archive. Subject and author lines are decoded if they are encoded per rfc2047. When split lines are unfolded, the number of escape sequences for iso-2022-* character sets is minimized. For instance, two consequtive toascii sequences are reduced. This processing is done for the character set specified in _d_i_r////cccchhhhaaaarrrrsssseeeetttt. The result of this process is the same for a given subject, irrespective of encoding. At the beginning of the message, eeeezzzzmmmmllllmmmm----sssseeeennnndddd prints a new MMMMaaaaiiiilllliiiinnnngggg----LLLLiiiisssstttt field with the contents of _d_i_r////mmmmaaaaiiiilllliiiinnnngggglllliiiisssstttt. It rejects the message if there is already a MMMMaaaaiiiilllliiiinnnngggg----LLLLiiiisssstttt field. If _d_i_r////lllliiiissssttttiiiidddd exists, eeeezzzzmmmmllllmmmm----sssseeeennnndddd will assume that the format is correct and create a ``List-ID:'' header by placing the contents after the text ``List-ID: ''. Next, eeeezzzzmmmmllllmmmm----sssseeeennnndddd prints all the new fields listed in _d_i_r////hhhheeeeaaaaddddeeeerrrraaaadddddddd. Any tags, ``<#h#>'', ``<#l#>'', or ``<#n#>'' found in these headers are replaced by the list host name, list local name, and message number, respectively. eeeezzzzmmmmllllmmmm----sssseeeennnndddd then prints an appropriate DDDDeeeelllliiiivvvveeeerrrreeeedddd----TTTToooo line. eeeezzzzmmmmllllmmmm----sssseeeennnndddd deletes any incoming fields with names listed in _d_i_r////hhhheeeeaaaaddddeeeerrrrrrrreeeemmmmoooovvvveeee. eeeezzzzmmmmllllmmmm----sssseeeennnndddd removes MIME parts specified in _d_i_r////mmmmiiiimmmmeeeerrrreeeemmmmoooovvvveeee before archiving and distribution of the message. If _d_i_r////tttteeeexxxxtttt////ttttrrrraaaaiiiilllleeeerrrr exists, eeeezzzzmmmmllllmmmm----sssseeeennnndddd adds the trailer to simple text/plain messages in the same encoding as used for SunOS 5.11 Last change: 1 User Commands ezmlm-send(1) the the message. However, if the encoding is ``base64'' it is not safe to do this and the header is suppressed. For composite MIME messages, the trailer is added as a separate part, with the character set and encoding specified in _d_i_r////cccchhhhaaaarrrrsssseeeetttt. The trailer is not added to multipart/alternative messages. Any tags, ``<#h#>'', ``<#l#>'', or ``<#n#>'' found in _d_i_r////tttteeeexxxxtttt////ttttrrrraaaaiiiilllleeeerrrr are replaced by the list host name, list local name, and message number, respectively. If _d_i_r////pppprrrreeeeffffiiiixxxx exists, eeeezzzzmmmmllllmmmm----sssseeeennnndddd will prefix the subject line with the first line of this file. A space will be added to separate pppprrrreeeeffffiiiixxxx from the subject text. pppprrrreeeeffffiiiixxxx is ignored for sublists. If _d_i_r////pppprrrreeeeffffiiiixxxx contains a ``#'', the last ``#'' will be replaced by the message number. Any prefix starting with text of a reply indicator (``Re:'', ``Re[n]:'', etc) will cause problems. The prefix may be rfc2047 encoded. Rfc2047 Iso-2022-* encoded prefixes _m_u_s_t end in ascii. The prefix feature and especially the message number feature modify the message in violation with Internet mail stan- dards. The features have been implemented by popular demand. Use at your own peril. _d_i_r////sssseeeeqqqquuuueeeennnncccceeee is ignored as of ezmlm-idx-0.32. Use _d_i_r////hhhheeeeaaaaddddeeeerrrraaaadddddddd with substitution to achieve the same goal. If _d_i_r////qqqqmmmmqqqqppppsssseeeerrrrvvvveeeerrrrssss exists, eeeezzzzmmmmllllmmmm----sssseeeennnndddd wwwwiiiillllllll uuuusssseeee qqqqmmmmaaaaiiiillll----qqqqmmmmqqqqpppp((((1111)))) to send messages. eeeezzzzmmmmllllmmmm----sssseeeennnndddd does not distribute bounce messages: if the environment variable SSSSEEEENNNNDDDDEEEERRRR is set, and is either empty or ####@@@@[[[[]]]], eeeezzzzmmmmllllmmmm----sssseeeennnndddd rejects the message. OOOOPPPPTTTTIIIIOOOONNNNSSSS -aaaa eeeezzzzmmmmllllmmmm----sssseeeennnndddd assumes that there are two trailer files: _d_i_r////tttteeeexxxxtttt////ttttrrrraaaaiiiilllleeeerrrr and _d_i_r////tttteeeexxxxtttt////aaaallllttttttttrrrraaaaiiiilllleeeerrrr. eeeezzzzmmmmllllmmmm----sssseeeennnndddd will scan the message for the occurence of ``##''. If found, the trailer used (if the message is otherwise suitable for trailer addition) will be _d_i_r////tttteeeexxxxtttt////ttttrrrraaaaiiiilllleeeerrrr. If not found, _d_i_r////tttteeeexxxxtttt////aaaallllttttttttrrrraaaaiiiilllleeeerrrr will be used, and a header will be prefixed with ``#''. In conjunction with the qmail-verh patch to qqqqmmmmaaaaiiiillll---- rrrreeeemmmmooootttteeee this allows inclusing of per-subscriber custom- ized unsubscribe instructions in _d_i_r////tttteeeexxxxtttt////aaaallllttttttttrrrraaaaiiiilllleeeerrrr in a manner that does not risk message corruption. -aaaaaaaa Same as -aaaa (see that switch), but the message is assumed to be free of ``##'' without checking. This is especially useful if piping the message directly to eeeezzzzmmmmllllmmmm----sssseeeennnndddd since it avoids the need to rewind stdin. -AAAA (Default.) The message is not checked for ``##''. If SunOS 5.11 Last change: 2 User Commands ezmlm-send(1) _d_i_r////tttteeeexxxxtttt////ttttrrrraaaaiiiilllleeeerrrr exists and the message is otherwise suitable for header addition, that trailer will be added. No signals for qqqqmmmmaaaaiiiillll----rrrreeeemmmmooootttteeee are added. -cccc No longer supported. Ignored for backwards compatibil- ity. -CCCC No longer supported. Ignored for backwards compatibil- ity. eeeezzzzmmmmllllmmmm----sssseeeennnndddd has to parse the subscriber database. -hhhh _h_e_a_d_e_r If the list is a sublist, i.e. _d_i_r////ssssuuuubbbblllliiiisssstttt exists, _h_e_a_d_e_r is required in all messages to the list. This option is used when ezmlm is used to run a sublist of a lists run by a different mailing list manager that uses _h_e_a_d_e_r rather than ``Mailing-List'' to identify mes- sages from the list. Anything after the first colon (if present) in _h_e_a_d_e_r is ignored. -rrrr Copy incoming ``Received:'' headers to the outgoing message. -RRRR (Default.) Do not copy incoming ``Received:'' headers, except the one added by the (last) listhost, to the outgoing message. In some cases, especially for sub- lists, the messages can have a large number of ``Received:'' headers. This may lead to bounces for some users due to sendmail ``hopcounts'' set too low somewhere in the mail path. These users can subscribe and receive warning and probe messages, but no list messages, unless the number of ``Received:'' headers is reduced. Pre-list ``Received:'' headers are of little interest to normal list subscribers. ``Received:'' headers are still copied to the archive and available to anyone from there for message tracking purposes. -vvvv Display eeeezzzzmmmmllllmmmm----sssseeeennnndddd version information. -VVVV Display eeeezzzzmmmmllllmmmm----sssseeeennnndddd version information. SSSSUUUUBBBBLLLLIIIISSSSTTTTSSSS If _d_i_r////ssssuuuubbbblllliiiisssstttt exists, eeeezzzzmmmmllllmmmm----sssseeeennnndddd changes its behavior in several ways. First, if SSSSEEEENNNNDDDDEEEERRRR is set, and the first line of _d_i_r////ssssuuuubbbblllliiiisssstttt has the form _p_a_r_e_n_t@@@@_p_a_r_e_n_t_h_o_s_t, eeeezzzzmmmmllllmmmm----sssseeeennnndddd insists that SSSSEEEENNNNDDDDEEEERRRR have the form _p_a_r_e_n_t............@@@@_p_a_r_e_n_t_h_o_s_t. Second, eeeezzzzmmmmllllmmmm----sssseeeennnndddd demands that the message already have a MMMMaaaaiiiilllliiiinnnngggg----LLLLiiiisssstttt field. SunOS 5.11 Last change: 3 User Commands ezmlm-send(1) Third, eeeezzzzmmmmllllmmmm----sssseeeennnndddd does not add its own MMMMaaaaiiiilllliiiinnnngggg----LLLLiiiisssstttt field. Fourth, eeeezzzzmmmmllllmmmm----sssseeeennnndddd uses the incoming message number for the outgoing message, if the list is not archived and the incom- ing SENDER has the correct format. This allows you to refer bounce warning recipients to the main list for archive retrieval of the missed messages. If the sublist archives message, it is assumed that missed messages will be retrieved from the sublist archive. The list still increments _d_i_r////nnnnuuuummmm for each message. If the sublist is archived, use of incoming message number for archive storage would be a security risk. In this case, the local sublist message number is used. OOOOPPPPTTTTIIIIOOOONNNN UUUUSSSSAAAAGGGGEEEE In general, the use of a prefix is discouraged. It wastes subject line space, creates trouble when MUAs add non- standard reply indicators. However, many users expect it not because it is useful, but because they are used to it. The -CCCC switch prevents posts from being set to SENDER. Rather than just copying out subscriber address files, eeeezzzzmmmmllllmmmm----sssseeeennnndddd has to parse them to look for SENDER. This makes it less efficient. Also, it is useful for the SENDER to see the post to know that it has made it to the list, and it's context to other subscribers, i.e. where it came within the traffic of messages on the list. Avoiding SENDER as a recipient is useful in small lists, such as small teams with varying members, where ezmlm serves mainly as an efficient tool to keep the team connected without administrator intervention. Here the overhead of subscriber list parsing is negligible. CCCCHHHHAAAARRRRAAAACCCCTTTTEEEERRRR SSSSEEEETTTTSSSS If the list is indexed, eeeezzzzmmmmllllmmmm----sssseeeennnndddd will keep a message index. rfc2047-encoded subject and from lines will be decoded. If _d_i_r////cccchhhhaaaarrrrsssseeeetttt exists, eeeezzzzmmmmllllmmmm----sssseeeennnndddd will eliminate redundant escape sequences from the headers according to the character set specified in this file. Only character sets using escape sequences need this support. Currently, sup- ported are iso-2022-jp*, iso-2022-kr, and iso-2022-cn*. Only iso-2022-jp has been tested extensively. The character set can be suffixed by ``:'' followed by a code. Recognized codes are ``Q'' for ``Quoted-Printable'', and ``B'' for ``base64''. For eeeezzzzmmmmllllmmmm----sssseeeennnndddd, this affects the format of the trailer, if a trailer is specified and if the message is a multipart mime message SunOS 5.11 Last change: 4 User Commands ezmlm-send(1) SSSSEEEEEEEE AAAALLLLSSSSOOOO ezmlm-get(1), ezmlm-idx(1), ezmlm-manage(1), ezmlm-make(1), ezmlm-sub(1), ezmlm-unsub(1), ezmlm-reject(1), ezmlm(5), qmail-qmqp(1) SunOS 5.11 Last change: 5