Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
ezmlm-send(1)		    General Commands Manual		 ezmlm-send(1)

       ezmlm-send - distribute a message to a mailing list

       ezmlm-send [ -cCrRvV ] [	-h header ] dir

       ezmlm-send reads	a mail message and sends it to the mailing list	stored
       in dir.	If dir/archived	exists,	ezmlm-send records a copy of the  mes-
       sage in the dir/archive/	directory.

       If  dir/indexed	exists,	 ezmlm-send  adds the subject, author and time
       stamp of	the message to the index, kept with the	message	in a subdirec-
       tory  of	 dir/archive/.	The subject is processed to make reply-subject
       entries identical to original message subject entries.  The subject in-
       dex  is	used for the archive retrieval functions of ezmlm-get(1).  Use
       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 charac-
       ter set specified in dir/charset.  The result of	this  process  is  the
       same for	a given	subject, irrespective of encoding.

       At  the	beginning of the message, ezmlm-send prints a new Mailing-List
       field with the contents of the TXT_MAILING_LIST	message.   It  rejects
       the message if there is already a Mailing-List field.

       If dir/listid exists, 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,  ezmlm-send  prints  all  the new fields listed in	dir/headeradd.
       Any tags, ``<#h#>'', ``<#l#>'', or ``<#n#>'' found in these headers are
       replaced	 by  the  list host name, list local name, and message number,

       ezmlm-send then prints an appropriate Delivered-To line.

       If dir/replytolist is present, ezmlm-send Adds a	 Reply-To:  header  to
       the  outgoing  message pointing to the mailing list and removes any in-
       coming Reply-To:	header.

       If it is	present, ezmlm-send deletes any	incoming fields	with names not
       listed  in  dir/headerkeep.   If	 not,  ezmlm-send deletes any incoming
       fields with names listed	in dir/headerremove.

       If dir/rewritefrom is present, ezmlm-send removes  the  original	 From:
       header and replaces it with the following:

	      From: "Real Name via listname" <listname@hostname>

       If  the DMARC record for	the address in the From: header	contains a re-
       ject policy, ezmlm-send enables rewritefrom for this message.

       If replytolist is enabled as above, the original	From: header is	 added
       to the list as a	Cc: header, otherwise as a Reply-To: header.

       If  present,  ezmlm-send	 removes  all  MIME  parts  not	 specified  in
       dir/mimekeep.  Otherwise	ezmlm-send removes  MIME  parts	 specified  in
       dir/mimeremove before archiving and distribution	of the message.

       If  dir/text/trailer  exists,  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 dir/charset.	The trailer is not added to multipart/alternative mes-
       sages.	 Any   tags,  ``<#h#>'',  ``<#l#>'',  or  ``<#n#>''  found  in
       dir/text/trailer	are replaced by	the list host name, list  local	 name,
       and message number, respectively.

       If  dir/prefix exists, ezmlm-send will prefix the subject line with the
       first line of this file.	A space	will be	added to separate prefix  from
       the  subject  text.  prefix is ignored for sublists. If dir/prefix con-
       tains 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  en-
       coded. Rfc2047 Iso-2022-* encoded prefixes 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.

       dir/sequence  is	 ignored  as of	ezmlm-idx-0.32.	Use dir/headeradd with
       substitution to achieve the same	goal.

       If dir/qmqpservers exists, ezmlm-send will use  qmail-qmqp(1)  to  send

       ezmlm-send  does	 not  distribute  bounce  messages: if the environment
       variable	SENDER is set, and is either empty or #@[], ezmlm-send rejects
       the message.

       -c     No longer	supported. Ignored for backwards compatibility.

       -C     No   longer  supported.  Ignored	for  backwards	compatibility.
	      ezmlm-send has to	parse the subscriber database.

       -h header
	      If the list is a sublist,	i.e.  dir/sublist  exists,  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 header	rather than ``Mailing-
	      List'' to	identify messages from the list.  Anything  after  the
	      first colon (if present) in header is ignored.

       -r     Copy incoming ``Received:'' headers to the outgoing message.

       -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 some-
	      where 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

       -v     Display ezmlm-send version information.

       -V     Display ezmlm-send version information.

       If dir/sublist exists, ezmlm-send changes its behavior in several ways.

       First, if SENDER	is set,	and the	first line of dir/sublist has the form
       parent@parenthost, ezmlm-send insists that SENDER have  the  form  par-

       Second, ezmlm-send demands that the message already have	a Mailing-List

       Third, ezmlm-send does not add its own Mailing-List field.

       Fourth, 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 sub-
       list archives message, it is assumed that missed	messages will  be  re-
       trieved from the	sublist	archive.

       The  list  still	increments dir/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.

       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 -C switch prevents posts from being set to SENDER. Rather than just
       copying	out  subscriber	address	files, 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	 traf-
       fic 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.

       If  the	list  is  indexed,  ezmlm-send	will  keep  a  message	index.
       rfc2047-encoded subject and from	lines will be decoded.	If dir/charset
       exists, 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.	Recog-
       nized   codes   are  ``Q''  for	``Quoted-Printable'',  and  ``B''  for

       For ezmlm-send, this affects the	format of the trailer, if a trailer is
       specified and if	the message is a multipart mime	message

       Since the MIME parser doesn't decode inner MIME layers of a multipart/*
       message,	mimekeep, mimeremove, and mimereject will be  applied  to  the
       outer MIME layer	only.

       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)



Want to link to this manual page? Use this URL:

home | help