🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.mail.misc
Article #1603

Re: mail servers

#1603
From: Tom Neff
Date: Wed, 22 Aug 1990 08:02
41 lines
2660 bytes
In article <BOB.90Aug22102618@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>A mail-based archive server is an impolite and destructive way to
>distribute large amounts of information, and should be discouraged in
>such applications.

Almost -- a MBAS is *potentially* destructive if it imposes no bandwidth
restrictions, satisfies requests exclusively by mailing files back to
the requestor, and makes no allowance for the loading constraints on the
delivery path.  This gloomy potential need not be realized.

 * Responsible archive servers will establish and enforce limits on how
much bandwidth an individual user can have; how much a given reply path
can tolerate; and how much overall activity per day can be supported.

 * In the most general sense of the term, a mail based archive server is
any server that accepts requests via mail.  The actions taken to satisfy
those requests need not be limited to mailing file contents back along the
reply path.  
  - A server might, for instance, satisfy a mailed file request by
placing the requested file on the nearest Internet site, and mailing a
short notification of FTP availability back to the requesting user.
  - It might respond to a mailed request by placing the file in an
anonymous UUCP download directory, and mailing back L.sys and filename
information to the user.
  - It might log the request, collate it with others for the same file,
and eventually perform one single contents mailing to a regional site,
followed by a mass mailing to the requesting users in that region
notifying them of local availability.

 * Where mailing the file is unavoidable, the server might identify the
message content as such for the management convenience of intervening
sites.  Exiting headers like Precedence: and Content-Type: could be used.

Since the MBAS genie is not going to go quietly back into its bottle, it
would be more constructive to suggest responsible strategies for running
them -- and provide software to implement those strategies -- than to
inveigh against the entire phenomenon.

-- 
The real problem with SDI is     %/    Tom Neff
that it doesn't kill anybody.    /%    tneff@bfmny0.BFM.COM
Technical Details
Message-ID: <15781@bfmny0.BFM.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!bfmny0!tneff
References: <1990Aug17.021921.1863@chinet.chi.il.us> <1594@i2ack.sublink.org> <BOB.90Aug22102618@volitans.MorningStar.Com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!bfmny0!tneff
From: tneff@bfmny0.BFM.COM (Tom Neff)
Newsgroups: comp.mail.misc
Subject: Re: mail servers
Message-ID: <15781@bfmny0.BFM.COM>
Date: 22 Aug 90 08:02:39 GMT
References: <1990Aug17.021921.1863@chinet.chi.il.us> <1594@i2ack.sublink.org> <BOB.90Aug22102618@volitans.MorningStar.Com>
Reply-To: tneff@bfmny0.BFM.COM (Tom Neff)
Lines: 41