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.