Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!brl-smoke!smoke!gds@SRI-SPAM.ARPA From: gds@SRI-SPAM.ARPA Newsgroups: net.mail.headers Subject: loop control Message-ID: <1095@brl-smoke.ARPA> Date: Wed, 19-Feb-86 03:42:44 EST Article-I.D.: brl-smok.1095 Posted: Wed Feb 19 03:42:44 1986 Date-Received: Fri, 21-Feb-86 07:28:41 EST Sender: news@brl-smoke.ARPA Lines: 49 Hello everyone. Remember this event? > From @MIT-MC.ARPA:mcvax!ace!teus@seismo.CSS.GOV Wed Dec 11 01:37:39 1985 > Received: from MIT-MC.ARPA by sri-spam.arpa (5.4/4.16) > id AA01923; Wed, 11 Dec 85 01:37:39 PST > Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:28:49 EST > Return-Path: ... > Message-Id: <8512101018.AA16148@sunrel1> This was the solution I previously proposed. > It might be the case that we also want to modify our mailers so that > upon receipt and full delivery of a message with a given Message-ID, all > subsequent messages received with that same Message-Id are dropped on > the floor (no need to advise anybody automagically of duplicates, since > we don't want to see exponential growth of looping mail :-). I don't > know if this is an MHS requirement or not but it is essential in a > conferencing system (where the same messsage might come from different > nodes in a network) and would relieve us of seeing duplicates. The only > problem is that not all mailers generate Message-IDs at the source of > the message, plus a redistributor may replace (or add) its own > Message-ID. We should limit the number of Message-IDs to one per > message. Given the growing number of "conferences" (actually Usenet groups) which are fed into the ARPA Internet as mailing lists, I think we should honor the Message-ID's generated at their source and refuse to process anything arriving with a Message-ID that has previously been processed. Although Usenet lists arrive in the ARPA Internet through single points of entry (commonly known as "gateways"), the increasing load to these machines may cause them to use multiple entry points. This increases the possibility of a loop if the gateways have common forwarding entries. Also, in our current mail environment, mail looping is caused for other, more obscure reasons. I've never looked into the part of sendmail which handles Message-IDs, but I imagine it wouldn't be too difficult to modify sendmail to refuse to process a message with an ID which has already been processed. There is a fundamental difference between Mailnet, Usenet and the ARPA mailing lists, in that the ARPA lists are not currently conferenced. I was wondering if anyone here is on the multimedia conferencing project, will there be standards set for converting our mailing lists into conferences, so we can read the mail as a conference? Also, the NNTP work can help solve looping problems caused by generation of duplicate postings. --gregbo