Dear Kurt, Thank you for your prompt response to the letter that Jeff forwarded to you. I'm actually a bystander here. There has been a discussion on the LSTOWN-L list about a problem that occurred on the MINI-AIR list. I'm sending this message to the list so that those who were directly affected can contact you directly. I was answering a message on LSTOWN-L which said: > On Mon, 15 Aug 1994 14:40:34 EDT, Marc Abrahams wrote: > >I am the owner of MINI-AIR, which has something over 18,000 subscribers. > >We send out, typically, one item a month to everyone on the list. > >(Only the editor is allowed to distribute items.) > > > >WhenI sent out the last mailing, the list went into a loop. Most or all of > >the 18,000 subscribers received 6 copies before I found out it was happening. > > What puzzles me is, if Marc is the only one empowered to distribute mail to > the list, then howcome the mail from the misconfigured daemon at Alaska.Edu > got posted? > > Naturally, this problem occured on a weekend (fortunately Marc was > reachable). My inquiry to [log in to unmask] back with a 'host > unreachable for three days' from my local SMTP (odd since Alaska spent the > day repeatedly bouncing that 50K message message at the list). > > I can imaging the problem creating a lot of junk in the postmaster's > mailbox, but the failure to reply to the list owner brands the staff at > Alaska.Edu as less than exemplary net citizens. If the primary domain > mailer remains misconfigured, I wouldn't feel quilty filtering > *@Alaska.Edu. > > /s Murphy A. Sewall <[log in to unmask]> (203) 486-2489 voice > Professor of Marketing (203) 486-5246 fax As you can see, the failure at alaska.edu generated a fair amount of anger. It seems that the failure created an infinite loop that caused a load of over 100,000 unnecessary messages. Furthermore, no response has been received to inquires sent to [log in to unmask] The KIDLINK list was not affected by the loop. Our list filter recognized the message as an error message and did not allow it to be posted to the list. But I got the message. This enabled me to examine the header so that I could answer the question raised above about how it was possible for a loop to occur on a fully moderated list. Moderated lists accept postings only from the people listed as the editors of the list. The error messages sent from alaska.edu contained a from: line saying that the message was from the list editor. This is what fooled the MINI-AIR list and created the infinite loop. Attached below is your complete message to me. The members of LSTOWN-L who were directly affected will probably be in touch with you. Peace, Dan << Daniel D. Wheeler Internet: [log in to unmask] >> << University of Cincinnati Bitnet: wheeler@ucbeh >> +++++++++++++++++++++++++< attachment >+++++++++++++++++++++++++ Return-path: <[log in to unmask]> MR-Received: by mta ORCA; Relayed; Tue, 16 Aug 1994 11:12:29 -0800 Date: Tue, 16 Aug 1994 11:12:29 -0800 From: Kurt Carlson <[log in to unmask]> Subject: Re: nasty bounce problem and a BIG list To: [log in to unmask], [log in to unmask] X400-MTS-identifier: [;92211161804991/1222529@ORCA] Hop-count: 1 Jeff & Dan, > maybe you can take a look and see if there is a problem > with the mail being bounced to the list. seems they are > implying it is bounced improperly. the user disk was > full which caused the bounce. From the information I have, the message was bounced correctly to to [log in to unmask] which was the RFC822 'Sender:' of the message, see below. There is not yet a defined standard for non-delivery and receipt notifications on the Internet, there is a draft standard under development. Until that is completed (and implemented), I believe the "correct" process is to abide by the RFC822 spec... other comments welcome! * * * From MRDAEMON.LOG: 15-AUG-1994 05:04:28.07 Fetched 1 Messages Sender: [log in to unmask] To: IMCC2 From: [log in to unmask] Author: [log in to unmask] Reply: [log in to unmask] Disassembled: 0815050423_0000.ENV;1 74754051804991/1219734@ORCA 2801 bytes %MAIL-I-CRENEW, Unable to create new message file IMCC2 -RMS-F-FUL, device full (insufficient space for allocation) [Non-Deliverable: Unable to create new message file IMCC2] (From>[log in to unmask]) PMDF-MR maps RFC822 to MR as follows: BSMTP MAIL FROM --> envelope 'sender' RFC822 Sender: --> content 'from' RFC822 From: --> content 'author' RFC822 states: o The "Sender" field mailbox should be sent notices of any problems in transport or delivery of the original messages. If there is no "Sender" field, then the "From" field mailbox should be used. The RFC822 'Sender' is the MR 'from', the non-delivery should have been sent to [log in to unmask] (which it was). I would guess (?) they really want non-delivery notifications to get to owner-kidlink. If somebody knows of a document that says it's kosher to use the bsmtp MAIL FROM once the message has been accepted, I can easily use that as first choice... but I could find no reference to that in an RFC. There is a secondary issue that disk fulls are leading to bounces instead of holding the messages. A disk off-line holds, I can probably fix mrdaemon to hold messages under a full disk condition as well. Regards... Kurt Carlson, U of Alaska