[comp.sys.amiga] Archive Mail Server ANNOUNCEMENT

raz@kilowatt.uucp (Raz- Berry) (05/11/89)

                     *** Announcement ***

 There now exists on kilowatt.sun.com a usenet mail server. This server
 is available to any one on the net who would like to get a copy of a
 comp.source|binaries.amiga posting. All of the files that Bob Page
 has posted since he has become moderator are available, as well as
 any future postings (since kilowatt is where the master copies of
 these groups are kept).

 Access to these files are by e-mail only, and I would hope that
 you will limit your requests to only those files that you can't
 find on your host machine or in your local area. Abuse of the archive
 will not be tolerated, and will result in discontinued privleges for
 the party concerned. If I find that too many people are ignoring the
 archive rules (defined below), or if I spend too much of my time on
 archive management, the server will be discontinued. 

 There is still some chance that the programs that maintain the archive
 are incorectly set up, if you find a problem and are ABSOLUTELY POSTITVE
 that it is the servers problem, and you have read the message below, and
 you have talked to your local guru (and he agrees), send mail to 
 archive-management@kilowatt or sun!kilowatt!archive-management. I'll
 get to it as soon as possible.

 With that out of the way, here is the help file that the archive-server
 will send to you if you send mail containing the line:

 send help
or
 help

 Good luck, and let archive-management@kilowatt.sun.com know if you have
 any problems.

	Steve -Raz- Berry


Here is the help file... PLEASE READ IT FIRST!
------------------------------------------------------------------------

This message comes to you from the archive server at kilowatt.sun.com,
archive-server@kilowatt.sun.com.  It received a message from you asking
for help.

The archive server is a mail-response program. That means that you mail
it a request, and it mails back the response.

The archive server is a very dumb program.  It does not have much error
checking. If you don't send it the commands that it understands, it will
just answer "I don't understand you".

The archive server has 4 commands. Each command must be the first word
on a line. The archive server reads your entire message before it does
anything, so you can have several different commands in a single
message. The archive server treats the "Subject:" header line just like
any other line of the message. You can use any combination of upper and
lower case letters in the commands.

The archives are organized into a series of directories and
subdirectories.  Each directory has an index, and each subdirectory has
an index. The top-level index gives you an overview of what is in the
subdirectories, and the index for each subdirectory tells you what is
in it.

---------------------------------------------------------------------------
If you are bored with reading documentation and just want to try
something, then send the server a message containing the line
	send index applications
When you get the index back, it will give you the names of all of the
files in the 'applications' directory in the archive; send the server
another message asking it to send you the files that you want:
	send applications plplot.2 plplot.3
etc.  If you are using a mailer that understands "@" notation, send to
archive-server@kilowatt.sun.com. If your mailer deals in "!" notation,
try sending to {someplace}!kilowatt.sun.com!archive-server, e.g.
uunet!kilowatt.sun.com!archive-server. For other mailers, you're on your own.
---------------------------------------------------------------------------


The server has 4 commands:

"help" command: The command "help" or "send help" causes the server to
	send you the help file. You already know this, of course,
	because you are reading the help file. No other commands are
	honored in a message that asks for help (the server figures that
	you had better read the help message before you do anything else).

"index" command: if your message contains a line whose first word is
	"index", then the server will send you the top-level index of
	the contents of the archive. If there are other words on that
	line that match the name of subdirectories, then the indexes for
	those subdirectories are sent instead of the top-level index.
	For example, you can say
		index
	or
		index iff

	You can then send back another message to the archive server,
	using a "send" command (see below) to ask it to send you the
	files whose name you learned from that list.

	(Footnote: "index iff" and "send index iff" mean the
	same thing: you can use the "send" command instead of the
	"index" command, if you want, for getting an index.

	If your message has an "index" or a "send index" command, then
	all other "send" commands will be ignored. This means that you
	cannot get an index and data in the same request. This is so
	that index requests can be given high priority.)

"send" command: if your message contains a line whose first word is
	"send", then the archive server will send you the item(s) named
	on the rest of the line. To name an item, you give its directory
	and its name. For example
		send workbench ptranim.uu2
	or
		send audio vclock.uu
	Once you have named a category, you can put as many names as you
	like on the rest of the line; they will all be taken from that
	category. For example:
		send exec xoper13.1 xoper13.2 xoper13.uu1

	Each "send" command can reference only one directory. If you 
	would like to get files from more than one directory, you must use
	two "send" commands.

	You may put as many "send" commands as you like into one message
	to the server, but the more you ask for, the longer it will take
	to receive. See "FAIRNESS", below, for an explanation. Actually,
	it's not strictly true that you can put as many "send" commands 
	as you want into one message. If the server must use uucp mail
	to send your files, then it cannot send more than 100K bytes
	in one message. If you ask for more than it can send, then it
	will send as much as it can and ignore the rest.  Since many
	files in the archive are around 60K, it's probably best to
	ask for one file at a time unless you know it's safe to do
	otherwise.

"path" command: The "path" command exists to help in case you do not
	get responses from the server when you mail to it.

	Sometimes the server is unable to return mail over the incoming
	path.  There are dozens of reasons why this might happen, and if
	you are a true wizard, you already know what those reasons are.
	If you are an apprentice wizard, you might not know all the
	reasons but you might know a way to circumvent them.

	If you put in a "path" command, then everything that the server
	mails to you will be mailed to that address, rather than to the
	return address on your mail. For example, if you say
	    path decwrl!pyramid!rutgers!zakkaroo!jj@uunet.uu.net
	then all mail sent by the server will be sent to that address.
	If you use mixed-mode addresses (! and @), the archive-server
	will put precedence on '@' before '!'.

	You cannot expect the archive server to pick a uucp path to be
	determined for you.  If you can't determine a path yourself,
	make the path relative to a 'known' site, e.g.:
	    path place!person@uunet.uu.net
	which will cause the archive-server to send to site uunet.uu.net
	with the instructions "send this to place!person".


EXAMPLES:

1) Find out the list of Amiga iff files that are in the archive.
   Send this message:
	To: archive-server@kilowatt.sun.com
	Subject: hi there

	index iff

2) Get files from the archive (you have learned their
   file names from the list that was sent to you in step 1).
	To: archive-server@kilowatt.sun.com
	Subject: send digest 3.17

	send iff gif2iff.uu2 ifflib161.uu1
	send iff dplaz.uu1

	(it turns out these three files add up to less that 100k,
	so they can all be sent by return mail).

3) Get a file, and send it over the best path to my site:
	To: uunet!mcvax!kilowatt.sun.com!archive-server

	path myname@site.uucp
	send iff iff2ps20.1

NOTES:

The archive server acknowledges every request by return mail. If you
don't get a message back in a few days (depending on how close you
are to sun.com on the network) you should assume that something is
going wrong, and perhaps try sending another request, this time
with a "path" command. If you aren't getting anywhere and you don't
know a wizard to help you, try putting
	path mysite!myname@uunet.uu.net
in your message, where "myname" is your mailbox name and "mysite" is the
uucp name of your machine.

The delays in sending out large items from the archives are
intentional, to make it difficult to get copies of everything in the
archives. If you are new to the network and would like to get all back
issues of everything, you should post a request to a regional newsgroup
asking whether someone who is geographically near you can provide
them.

Don't send mail with long lines. If you want to ask for 40 files in one
request, you don't need to put all 40 of them in one "send" command.
The archive server is quite able to handle long lines, but before your
mail message is received by the archive server it might pass through
relay computers that will choke on long lines, or chop them up.

The archive server does not respond to requests from users named
"root", "system", "daemon", or "mailer". This is to prevent mail
loops.  If your name is "Bruce Root" or "Joe Daemon".  Yes, I know
about Norman Mailer and Waverley Root. Norman doesn't use netmail and
Waverley is dead.


FAIRNESS:

The archive server contains many safeguards to ensure that it is not
monopolized by people asking for large amounts of data. The mailer is
set up so that it will send no more than a fixed amount of data each
day. If the work queue contains more requests than the day's quota,
then the unsent files will not be processed until the next day.
Whenever the mailer is run to send its day's quota, it sends the
requests out shortest-first.

If you have a request waiting in the work queue and you send in another
request, the new request is added to the old one (thereby increasing
its size) rather than being filed anew. This prevents you from being
able to send in a large number of small requests as a way of beating
the system.  If you request 10 files together, you will get
substantially higher priority than if you make 10 requests for 1 file
each.

The reason for all of these quotas and limitations is that the delivery
resources are finite, and there may be many people who would like to
make use of the archive.

[end of help]

-- 
Steve -Raz- Berry      Disclaimer: I didn't do nutin!
UUCP: sun!kilowatt!raz                    ARPA: raz%kilowatt.EBay@sun.com
"Fate, it protects little children, old women, and ships named Enterprize"