ezmlm-send \- distribute a message to a mailing list
.SH SYNOPSIS
.B ezmlm-send
+[
+.B \-cCrRvV
+] [
+.B \-h\fI header
+]
.I dir
.SH DESCRIPTION
.B ezmlm-send
exists,
.B ezmlm-send
records a copy of the message in the
-.I dir\fB/archive
+.I dir\fB/archive/
directory.
+If
+.I dir\fB/indexed
+exists,
+.B ezmlm-send
+adds the subject, author and time stamp of the message to the index, kept with
+the message in a subdirectory of
+.IR dir\fB/archive/ .
+The subject is processed to make reply-subject entries identical to
+original
+message subject entries.
+The subject index is used for the archive retrieval functions of
+.BR ezmlm-get(1) .
+Use
+.B ezmlm-idx(1)
+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
+.IR dir\fB/charset .
+The result of this process is the same for a given subject, irrespective
+of encoding.
+
At the beginning of the message,
.B ezmlm-send
prints a new
.B Mailing-List
field.
+If
+.I dir\fB/listid
+exists,
+.B ezmlm-send
+will assume that the format is correct and
+create a ``List-ID:'' header by placing the contents after the
+text ``List-ID: ''.
+
+Next,
+.B ezmlm-send
+prints all the new fields listed in
+.IR dir\fB/headeradd .
+Any tags, ``<#h#>'', ``<#l#>'', or ``<#n#>'' found in these headers
+are replaced by the list host name, list local name, and message number,
+respectively.
+
.B ezmlm-send
-then prints all the new fields listed in
-.IR dir\fB/headeradd ,
-followed by an appropriate
+then prints an appropriate
.B Delivered-To
line.
.IR dir\fB/headerremove .
.B ezmlm-send
+removes MIME parts specified in
+.I dir\fB/mimeremove
+before archiving and distribution of the message.
+
+If
+.I dir\fB/text/trailer
+exists,
+.B ezmlm-send
+adds the trailer to simple text/plain messages in the same encoding as used for
+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
+.IR dir\fB/charset .
+The trailer is not added to multipart/alternative messages.
+Any tags, ``<#h#>'', ``<#l#>'', or ``<#n#>'' found in
+.I dir\fB/text/trailer
+are replaced by the list host name, list local name, and message number,
+respectively.
+
+If
+.I dir\fB/prefix
+exists,
+.B ezmlm-send
+will prefix the subject line with the first line of this
+file. A space will be added to separate
+.B prefix
+from the subject text.
+.B prefix
+is ignored for sublists. If
+.I dir\fB/prefix
+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
+.I must
+end in ascii.
+
+The prefix feature and especially the message number feature
+modify the message in violation
+with Internet mail standards. The features have been implemented by popular
+demand. Use at your own peril.
+
+.I dir\fB/sequence
+is ignored as of ezmlm-idx-0.32. Use
+.I dir\fB/headeradd
+with substitution to achieve the same goal.
+
+If
+.I dir\fB/qmqpservers
+exists,
+.B ezmlm-send will use
+.B qmail-qmqp(1)
+to send messages.
+
+.B ezmlm-send
does not distribute bounce messages:
if the environment variable
.B SENDER
.BR #@[] ,
.B ezmlm-send
rejects the message.
+.SH OPTIONS
+.TP
+.B \-c
+No longer supported. Ignored for backwards compatibility.
+.TP
+.B \-C
+No longer supported. Ignored for backwards compatibility.
+.B ezmlm-send
+has to parse the subscriber database.
+.TP
+.B \-h\fI header
+If the list is a sublist, i.e.
+.I dir\fB/sublist
+exists,
+.I header
+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
+.I header
+rather than ``Mailing-List'' to identify messages from the list.
+Anything after the first colon (if present) in
+.I header
+is ignored.
+.TP
+.B \-r
+Copy incoming ``Received:'' headers to the outgoing message.
+.TP
+.B \-R
+(Default.)
+Do not copy incoming ``Received:'' headers, except the one added by
+the (last) listhost, to the outgoing message.
+In some
+cases, especially for sublists,
+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.
+.TP
+.B \-v
+Display
+.B ezmlm-send
+version information.
+.TP
+.B \-V
+Display
+.B ezmlm-send
+version information.
.SH "SUBLISTS"
If
.I dir\fB/sublist
does not add its own
.B Mailing-List
field.
+
+Fourth,
+.B ezmlm-send
+uses the incoming message number for the outgoing message, if the list
+is not archived and the incoming 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
+.I dir\fB/num
+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.
+.SH "OPTION USAGE"
+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
+.B \-C
+switch prevents posts from being set to SENDER. Rather than just copying
+out subscriber address files,
+.B ezmlm-send
+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.
+.SH "CHARACTER SETS"
+If the list is indexed,
+.B ezmlm-send
+will keep a message index. rfc2047-encoded subject and from lines will be
+decoded.
+If
+.I dir\fB/charset
+exists,
+.B ezmlm-send
+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,
+supported 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
+.BR ezmlm-send ,
+this affects the format of the trailer, if a trailer is specified and if the
+message is a multipart mime message
.SH "SEE ALSO"
+ezmlm-get(1),
+ezmlm-idx(1),
ezmlm-manage(1),
ezmlm-make(1),
ezmlm-sub(1),
ezmlm-unsub(1),
ezmlm-reject(1),
-ezmlm(5)
+ezmlm(5),
+qmail-qmqp(1)
~mdw / ezmlm / blobdiff