home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ARM Club 3
/
TheARMClub_PDCD3.iso
/
hensa
/
comms
/
maillist_1
/
!MailList
/
Docs
/
MailServer
< prev
next >
Wrap
Text File
|
1995-02-26
|
3KB
|
69 lines
Using the Mail-Server Robot
===========================
Separately from the Mailing-list Robot a Mail-Server Robot is offered by
MailList. You don't have to set-up any mailing-lists to use the Mail-Server.
And you don't have to set-up the Mail-Server to use the Mailing-list Robot.
Many archive-sites (or FTP-sites) around the Internet (eg. HENSA, Demon,
MIT) offer a Mail-server for those people unfortunate to have e-mail access
only. A mail-server allows people to "download" files/applications from it's
archive via e-mail.
The Mail-Server Robot integrated into MailList offers a simple way of
distributing files/programs via e-mail. Only one request is supported to do
this: SEND <file> [<size>]
The system-variable <MailList$MailServerDir>, which is set in the !Run file
points to the directory where the archives are stored which can be retrieved
via e-mail. By default this points to the directory:
<MailList$Dir>.MailServer
But you can change this to anything you like. For example to:
<UUCP_SPOOLDIR>.Public
or
ADFS::4.$.archives.public
or whatever you like.
You can build an entire tree in this directory with subdirectories for
different applications/archives. MailList will find its way.
Send the request: SEND INDEX
MailList will send the requester an index of all the files/subdirectories in
the directory defined by <MailList$MailServerDir>.
The request: SEND <file> [<size>]
will send the requester the requested <file>. The <file> will be UUencoded
before it is sent. Textfiles are sent unencoded.
NOTE: If a textfile contains top-bit set characters (ie. not standard
ASCII) then it is wise to change the filetype to someting else.
Top-bit set characters generally don't survive the net. Changing
the filetype will force the textfile to be UUencoded, thus
preserving the text.
If <size> is specified the (UUencoded) file will be split into parts of
<size>kB before it is sent. As some gateways/routers on the Internet do not
allow mail bigger than 100kB (AOL limits the size to 64kB) this can be a
useful feature. I myself have successfully sent mails of over 400kB but this
cannot always be guaranteed and needs some experimentation by each
individual requester.
If there's a lot of interesting information on your system you may notice
that some people have the habbit of requesting as much as possible. This
will ofcourse slow your system down as a lot of data has to be processed and
sent out. To keep things within limits you can restrict the amount of data a
person retrieves from your system.
The request: QUOTA <size>
is a hostowner request. <size> is the maximum amount of data in kB that one
person (i.e. e-mail address) may retrieve from your system per day.