tar@ksuvax1.cis.ksu.edu (Tim Ramsey) (12/01/88)
[ I've added comp.mail.headers and directed followups there since this thread
seems to be moving in that direction. -- Tim]
The Options: header is a good idea. How about a Bounced-By: header, to make
it clear to mailing list repeaters that this mail shouldn't be broadcast to
the list? It could include the reason the mail was bounced.
--
Timothy Ramsey, USENET Keeper-Upper
BITNET: tar@KSUVAX1
Internet: tar@ksuvax1.cis.ksu.edu
UUCP: ...!rutgers!ksuvax1!tar -or- ...!{pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!tarkarl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (12/01/88)
tar@ksuvax1.cis.ksu.edu (Tim Ramsey) writes:
The Options: header is a good idea. How about a Bounced-By: header, to make
it clear to mailing list repeaters that this mail shouldn't be broadcast to
the list? It could include the reason the mail was bounced.
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. Then
bounces would go to the admin only, and nowhere else. Also, it helps
to have the From_ line indicate listname-request@listname-host-machine
to keep vacation(1) happily silent.
--Karlkjones@talos.UUCP (Kyle Jones) (12/02/88)
In <KARL.88Dec1100418@triceratops.cis.ohio-state.edu> 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. This works only if everyone runs a mailer that supports this header. There is no mention of Errors-To: in RFC822. Sendmail claims to support this header, but smail (2.5) certainly does not. I say 'claims' because I recently had a mailing list that I run flooded with returned mail from a host running sendmail. 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 <list-name>-request instead of <list-name>. 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. kyle jones <kjones@talos.UUCP> ...!uunet!talos!kjones
david@ms.uky.edu (David Herron -- One of the vertebrae) (12/04/88)
In article <359@talos.UUCP> kjones@talos.UUCP (Kyle Jones) writes: >In <KARL.88Dec1100418@triceratops.cis.ohio-state.edu> 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 <list-name>-request >instead of <list-name>. 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 <list-name>-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<space>" 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 <list-name>-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: <list>: <list>-outgoing@list-processor <list>-outgoing: :include:/file <list>-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 <david@ms.uky.edu> <-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <-- <-- Controlled anarchy -- the essence of the net.
page@swan.ulowell.edu (Bob Page) (12/07/88)
Karl Kleinpaste writes: > [include] Errors-To: Errors-To: is a sendmail-ism. A stock sendmail will bounce errors to the Errors-To: address IN ADDITION to the From: address. You should use Sender: as per rfc822. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.
marvit@hpcea.CE.HP.COM (Peter Marvit) (12/07/88)
To prevent massive repostings to a distribution list, I use the addres form (described in RFC-822): To: NiceName-of-List: real-address@host, address-alias; I also include a From: List-request@myhost as well as the usual X-Errors-to and anything else I can think of. The above addressing convention works well for small mailing lists as well (inside an organization). -Peter marvit HP Labs
mike@turing.unm.edu (Michael I. Bushnell) (12/07/88)
In article <359@talos.UUCP> kjones@talos.UUCP (Kyle Jones) writes: In <KARL.88Dec1100418@triceratops.cis.ohio-state.edu> 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. This works only if everyone runs a mailer that supports this header. There is no mention of Errors-To: in RFC822. Sendmail claims to support this header, but smail (2.5) certainly does not. I say 'claims' because I recently had a mailing list that I run flooded with returned mail from a host running sendmail. An Errors-To: line was present in the message in question. Hmmm...It appears I (who said the same thing as Karl) that you are correct. On the other hand, the Sender: field is unquestionable the proper location for errors to be sent. For my money, the right way to avoid bounced mail hitting an entire mailing list is to make the From: header say <list-name>-request instead of <list-name>. 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. Hmmmm...yeah. But then I suspect you will have to manually forward lots of postings from users who didn't manually edit the To: line. The best way is for mail addressed like so: To: mailinglist@foo.bar.bax From: Joe.User@my.machine to be transformed by foo.bar.bax when it resends the mail into Resent-From: mailinglist-request@foo.bar.bax Resent-Sender: mailinglist-request@foo.bar.bax To: mailinglist@foo.bar.bax From: Joe.User@my.machine The mail should be delivered using the Resent-* headers in preference to the originals...according to the RFC. How much you wanna bet that smail and sendmail both don't actually do this right...:-) The best defacto solution is probably to have the mail set to individual list subscribers be addressed To: mailinlist@foo.bar.bax Sender: mailinglist-request@foo.bar.bax From: Joe.User@my.machine Reply-To: mailinglist@foo.bar.bax If you want the from line changed, then go ahead--but you are asking to be filled with pain if you don't fix the Reply-To: line... -- Michael I. Bushnell \ This above all; to thine own self be true HASA - "A" division GIG! \ And it must follow, as the night the day, mike@turing.unm.edu /\ Thou canst not be false to any man. Numquam Gloria Deo / \ Farewell: my blessing season this in thee!