Path: utzoo!utgpu!watmath!clyde!att!rutgers!ukma!david
From: david@ms.uky.edu (David Herron -- One of the vertebrae)
Newsgroups: comp.mail.headers
Subject: Re: Mail header wishlist
Message-ID: <10645@s.ms.uky.edu>
Date: 3 Dec 88 16:51:40 GMT
References: <1005@asylum.sf.ca.us>  <2696@sultra.UUCP> <1320@ksuvax1.cis.ksu.edu>  <359@talos.UUCP>
Reply-To: david@ms.uky.edu (David Herron -- One of the vertebrae)
Organization: U of Kentucky, Mathematical Sciences
Lines: 60

In article <359@talos.UUCP> kjones@talos.UUCP (Kyle Jones) writes:
>In  Karl Kleinpaste writes:
>[concerning Bounced-By: header]
>>That would be unnecessary if mailing lists would all make sure that,
>>when distributing out to the list's recipients, an Errors-To:
>>listname-request@listname-host-machine header were included.
>  An Errors-To: line was
>present in the message in question.
>
>For my money, the right way to avoid bounced mail hitting an entire
>mailing list is to make the From: header say -request
>instead of .  This means that recipients must edit the To:
>line if they want to reply to the list, but that's a small price to pay.


No no no no ...

The *right* way to do this is to change the out-of-band return
address to be -request@list-host.domain.  I think this
is even documented in an RFC somewhere, but is certainly the
preferred practice on the Internet.  And the main offenders are
mailing lists run at sites running SendMail.

On the internet the out-of-band information is carried as part of
the SMTP conversations in the MAIL FROM:<> and RCPT TO:<> lines.
In BITNET there isn't any good place to carry the information
unless you're using BSMTP, and this is one of the reasons why
BITNET should be converting to BSMTP.  In UUCP, this information
is carried in two places, the TO information is carried along as
arguments to rmail and the FROM information is carried along
in the "From" line.  Most rmail's allow only one argument,
which ends up requiring physically seperate messages be sent out
for each person on the mailing list.

This is one of the things which MMDF does right.  Part of the
package is the List Channel.  It accepts messages meant for
a mailing list and

	expands the TO portion of the out-of-band information
		to be all the people on the list.
	if -request exists as an alias in the system,
		changes the out-of-band FROM information to
		reflect this.
	resubmits the message to the system.  (no header munging)

A similar program would be easy to do to run under sendmail.
Part of how this happens in MMDF is that you have a sequence
of aliases like:

	:		-outgoing@list-processor
	-outgoing: :include:/file
	-request:	joe-blow

In other words, you have to set up a pseudo-host so that you can
direct mail to it.
-- 
<-- David Herron; an MMDF guy                              
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- Controlled anarchy -- the essence of the net.