Thread View: net.mail.headers
3 messages
3 total messages
Started by gds
Wed, 19 Feb 1986 08:42
loop control
Author: gds
Date: Wed, 19 Feb 1986 08:42
Date: Wed, 19 Feb 1986 08:42
49 lines
3055 bytes
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
Re: loop control
Author: Erik E. &
Date: Mon, 24 Feb 1986 02:03
Date: Mon, 24 Feb 1986 02:03
28 lines
2008 bytes
2008 bytes
There have been some misconceptions and I have a point to add: 1. sendmail does loop detection by counting Received: headers, WITH ITS OWN HOSTNAME IN THEM. After 30 such lines (i.e. thirty times through this host), the letter gets mailed to postmaster. It does not arbitrarily throw away letters that have passed through 30 hosts. 2. sendmail will add a message-id to any letter passing through it that does not already have one. Seeing as how mailers that send out mail messages without message-ids are in violation of the relevant standards (hello TOPS-20!), this is a good thing. 3. The recnews program running here at ucbvax (the one that I hacked up) does leave the message-id of mail coming from the internet through to the USENET strictly alone (so long as it is a legal message-id according to RFC822). Now. It should be possible for items originating on the ARPANET bound for *moderated* USENET newsgroups to have multiple gateways, as long as the originating site adds a unique message-id to the letter, and ALL of the gateways run my hacked up recnews with changes to inews. I've already fed the changes back to Rick Adams, rather than distribute them myself, and when that release of netnews is official, I will try and coordinate a multiple gateway effort. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
sendmail chops addresses (was: Erik the Fair on loop control)
Author: Andrew Scott Beals
Date: Mon, 24 Feb 1986 21:11
Date: Mon, 24 Feb 1986 21:11
29 lines
1917 bytes
1917 bytes
In article <11992@ucbvax.BERKELEY.EDU> fair@ucbarpa.berkeley.edu.BERKELEY.EDU (Erik E. &) writes:
>There have been some misconceptions and I have a point to add:
And a point of information that I would like to clear. (You really
should get someone to fix rrn, Erik)
>1. sendmail does loop detection by counting Received: headers,
> WITH ITS OWN HOSTNAME IN THEM. After 30 such lines (i.e.
> thirty times through this host), the letter gets mailed
> to postmaster. It does not arbitrarily throw away letters
> that have passed through 30 hosts.
As distributed, MAXATOM (in src/conf.h) is set to 100. This is the
allowable number of tokens in an address. "eric@berkeley" is three
atoms.
Addresses longer than MAXATOM will get truncated. This usually
creates addresses that look like:
one!and!another!hop!thru!bel!tel!land!before!we!reach!ihnp4!
With the address getting chopped off somewhere in the middle. Sigh.
Unfortunately, this also seems to be the way that sendmail is
distributed with other systems (Pyramid).
--
I'm PROUD to be a CARBON-BASED lifeform!
andy beals
bandy@lll-crg.arpa {ihnp4,seismo,qantel,sun}!lll-crg!bandy
LLNL, P.O. Box 808, L-419, Livermore CA 94550 (415) 423-1948
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads