🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.mail.headers
Article #619

loop control

#619
From: gds
Date: Wed, 19 Feb 1986 08:42
49 lines
3055 bytes
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: <mcvax!ace!teus>
 ...
> 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
Technical Details
Message-ID: <1095@brl-smoke.ARPA>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!brl-smoke!smoke!gds@SRI-SPAM.ARPA

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!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