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