A Beginner's Guide to the Internet/INTERNET.ISO/text/lists/ccinet10/ftpmail.doc

Text File | 1996-05-06 | 17.5 KB | 373 lines

Sender: [e-mail]

BITFTP -- Princeton BITNET FTP Server

BITFTP provides a mail interface to the FTP command supplied by the IBM
TCP/IP for VM product ("FAL") running on the Princeton University
VM/CMS system, to allow BITNET/NetNorth/EARN users to ftp files from
sites on the Internet.

To use BITFTP, send mail containing your ftp commands to
BITFTP@PUCC (or to [e-mail]).

The first command in the mail file you send to BITFTP must be "FTP",
"HELP", "VMS", or "FTPLIST".  Use "HELP" to request a current copy of
this help file.  Use "VMS" to request a collection of tips provided by
BITFTP users on how to handle binary files from BITFTP on VMS systems.
Use "FTPLIST" to obtain a list of some of the hosts that allow anonymous
ftp.  (Note that there is no guarantee that BITFTP can access all the
hosts in that list.)

The recommended syntax for FTP requests is:

   FTP hostname NETDATA    --or--    FTP hostname XXENCODE
   USER username password
   <other ftp subcommands>
   QUIT

For "hostname", specify the name (e.g., "Bambleweeny57.Princeton.EDU")
or IP address (e.g., "128.112.64.12") of the host from which you wish
to request files.  Following the hostname on the FTP command, you may
specify "NETDATA" or "UUENCODE" or "XXENCODE" to tell BITFTP the format
in which you wish to receive files.  Please use NETDATA format if you
can, as it imposes a substantially smaller burden on both BITFTP and
the network.  (Users inside IBM will be able to receive NETDATA files
only if they send their requests to BITFTP via the VNET/BITNET gateway,
rather than via the VNET/Internet gateway.)

The "username" in your request should be the userid that owns the files
you wish to request.  If the username in your ftp request is
"anonymous", no password is required; BITFTP will use your userid and
and its own nodeid for the password.  If the username is not
"anonymous", then you must specify the password appropriate for the
username.  Note that on many systems passwords are case-sensitive; that
is, the password may be required to be in lower case or mixed case or
upper case.  (The same is true of directory and file names.)

The following is an example of an ftp request:

   FTP nis.nsf.net
   USER anonymous
   cd introducing.the.internet
   get intro.to.ip
   get network.gold
   get where.to.start
   get zen.ps
   get zen.txt
   QUIT

It connects to the host nis.nsf.net and requests five files from the
"introducing.the.internet" directory of that host's anonymous login.

If the host you wish to connect to uses a non-standard ftp port, you can
specify that port number on the FTP command immediately following the
hostname field.  (This will be required only in unusual circumstances.)

BITFTP implements a subset of the ftp subcommands provided in IBM
TCP/IP for VM and uses the same syntax.  Therefore, you may find it
useful to obtain the IBM "TCP/IP for VM User's Guide", IBM order number
SC31-6081.

The currently supported subcommands are:

  ACCT        -- to send host-dependent account information.
    format:   ACCT account-information

  ASCII       -- to change the file transfer mode to ASCII.
    format:   ASCII

  BINARY      -- to change the file transfer mode to image.
    format:   BINARY <FIXED record-len> <VARIABLE>

  CD          -- to change the working directory.
    format:   CD directory

  DIR         -- to get a list of directory entries.
    format:   DIR

  EBCDIC      -- to change the file transfer mode to EBCDIC
    format:   EBCDIC

  GET         -- to get a file from the foreign host.
    format:   GET foreignfile <localfile>

              If you specify "localfile", it must be in
              the forms "filename.filetype" or "filename",
              and the filename and filetype may each be no
              more than 8 characters long and may not contain
              periods.  If the host you are FTPing to is a
              VM/CMS system, then you should specify the
              "foreignfile" as "filename.filetype"; that is,
              the parts of the name should be separated by
              periods, rather than blanks as they normally
              are for CMS file names.

  LS          -- to list the files in a directory.
    format:   LS <name>

  MODE        -- to specify Stream or Block as the file transfer
                 mode.
    format:   MODE <S|B>

  PWD         -- to print the working directory.
    format:   PWD

  QUIT        -- to disconnect from the foreign host.
    format:   QUIT

  SYSTEM      -- to get the name of the foreign host's operating
                 system.
    format:   SYSTEM

  TYPE        -- to specify ASCII ("A"), image ("I"), Kanji Shift
                 JIS ("B"), EBCDIC ("E"), or EBCDIC IBM Kanji ("F")
                 as the file transfer mode.
    format:   TYPE <A|I|B|E|F>

BITFTP does not provide a PUT capability, and there is no intention to
make it do so in the future, nor does it provide an MGET capability.

BITFTP accepts requests via RFC822-format mail, IBM NOTE-format mail
(with headers in English, French, German, or Danish), PROFS-format
messages, or files with no headers at all sent via RSCS.  It returns the
requested files as NETDATA-format files or as mail files containing
uuencoded or xxencoded data.  If you specify "UUENCODE", "XXENCODE", or
"NETDATA" on your "FTP" command, BITFTP will attempt to use the format
you request.  If you do not specify the format, BITFTP will attempt to
select the appropriate format for your node.

BITFTP attempts to determine your return address by parsing the mail
file it receives from you.  It uses the address specified in a
"Reply-to:" line in the mail headers in preference to the address
specified in the "From:" line.  If you specify a "PATH" command in the
body of the mail, that address will be used in preference to either the
"Reply-to:" or "From:" address.  The format of a "PATH" command is
simply "PATH userid@nodeid".  If you are on BITNET/EARN/NetNorth, you
should not specify a path.  In general, you need specify a path only if
you get no response from requests to BITFTP otherwise.

BITFTP will not send you a file that contains more than 17825792
bytes of data.  It will not send you more than 15000 lines of
directory listings as the result of one request file.  Uuencoded and
xxencoded files are broken up into mail files that contain no more than
750 records (containing 62 bytes each).  NETDATA-format files
that are larger than 900000 bytes are sent in 900000-byte pieces
using the BITSEND function.  You should be able to receive such files
using the BITRCV function available from your nearest NETSERV.  (If you
do not know how to use NETSERV, ask your local BITNET/EARN/NetNorth
Coordinator for assistance.  Users inside IBM can get help with BITRCV
from the BITNET FORUM.)  To recover the original file when BITRCV is not
available for your system, use the command you normally use to receive
NETDATA-format files and then catenate the files in the order shown in
the BITRCV control file.

Users in the UK should note that BITFTP attempts to send NETDATA-format
files through the gateway from EARN into Janet using the NIFTP facility
at Rutherford Lab.  Receiving files via NIFTP requires an overt action
on your part.  If you are at a Janet node and don't know how to use
NIFTP, you should ask for assistance locally.  Alternatively, you can
ask BITFTP to send your files encoded inside mail by specifying the
"UUENCODE" or "XXENCODE" option on the FTP command.

If BITFTP sends you a file you cannot read, THE FIRST THING TO DO is to
make sure that you specified "ASCII" if the file should contain textual
material (or "EBCDIC" for text files from an IBM system), or that you
specified "BINARY" if the file should contain binary data, executable
programs, tar files, or the like.

User on IBM systems (VM/CMS or MVS/TSO) should specify "MODE B" (for
"Block") when requesting files from other IBM systems, in order to
preserve the record structure of the files.

VMS users should use RECEIVE/BINARY to receive the NETDATA-format binary
files BITFTP sends to them.

If BITFTP sends you a uuencoded file that you cannot uudecode, the
first thing to do is to translate all occurrences of 0x7E in the file to
0x5E and then try uudecoding again.  (Some gateways change 5Es to 7Es
when the files pass through them.)

There are many different flavors of UUENCODE/UUDECODE.  The version that
BITFTP uses puts a "guard character" (the letter "M") at the end of
each encoded line (to prevent the removal of trailing blanks in the
encoded data).  Most implementations of uudecode know to ignore this
character.  If yours does not, then you should remove the "M" at the end
of each line before attempting to uudecode the file.

When BITFTP is told to transfer a file in FIXED format, such as "BINARY
FIXED 512", it will create a file whose total byte count is an integral
multiple of the record length (512, in this case).  This means that the
last record may be padded with binary zeros to get it to the specified
record length.  In such a case, you may need to use an editor to shorten
the last record so that the total byte count of the file is correct.
(If the file is encoded when you receive it, shorten it AFTER you have
decoded it.)

In addition to any files you request, you will also receive a mail file
containing a log of your ftp session.  In that mail file, entries
prefixed by ">" are your original commands; those prefixed by ">>" are
your commands as interpreted by BITFTP and passed to FAL; those
prefixed by ">>>" are your commands as interpreted by FAL and passed to
the remote host; those prefixed by "<<<" are messages from the remote
host; and those prefixed by ">>>>" are completion messages from BITFTP.

If BITFTP is unable to connect to the host you specify, it will send
you mail after the first attempt, but will keep trying at intervals over
two days.  The only additional mail file you will receive will be when
the connection is made successfully or when BITFTP gives up after two
days.

The load on BITFTP is often very heavy, and network backlogs are often
so great that it may take several days for a file to get to you once
BITFTP sends it on its way, so please be patient and don't send
multiple requests for the same file.  If your system allows you to send
interactive messages, you can inquire about BITFTP's backlog by sending
the query "How are you?", e.g., on a VM system:

   TELL BITFTP AT PUCC How are you?

Questions about BITFTP and suggestions for improvements should be sent
to Melinda Varian, MAINT@PUCC on BITNET or [e-mail] on
the Internet.  When you have a problem, it helps if you send along a log
mail file from BITFTP that illustrates the problem.  (Please send the
entire mail file, including the mail headers.)

The author gratefully acknowledges the use of the SENDJANI EXEC written
by Alan Flavell and an RFC822 parsing routine written by Eric Thomas.
NOTE:  If you have any complaints or suggestions about the way any of
these routines work in BITFTP, please send them to MAINT@PUCC (Melinda
Varian), not to those authors.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

From:  "ftpmail service on ftp-gw-1.pa.dec.com"   >INTERNET:[e-mail]
Subj:  your ftpmail request has been received [help]

Sender: [e-mail]
  -- Help --
>>> $Id: help-text,v 1.7 1993/05/05 00:49:43 vixie Exp $
>>>
>>> ftpmail is not a supported service. From time to time it stops working;
>>> we will tend to it when we get the time. Outages of a week or more are not
>>> abnormal.

>>> commands are:

        reply <MAILADDR>        set reply addr, since headers are usually wrong
        connect [HOST [USER [PASS [ACCT]]]]
                                defaults to gatekeeper.dec.com, anonymous
        ascii                   files grabbed are printable ascii
        binary                  files grabbed are compressed or tar or both
        chdir PLACE             "get" and "ls" commands are relative to PLACE
                                        (only one CHDIR per ftpmail session,
                                        and it executes before any LS/DIR/GETs)
        compress                compress binaries using Lempel-Ziv encoding
        compact                 compress binaries using Huffman encoding
        uuencode                binary files will be mailed in uuencode format
        btoa                    binary files will be mailed in btoa format
        chunksize SIZE          split files into SIZE-byte chunks (def: 64000)
        ls (or dir) PLACE       short (long) directory listing
        index THING             search for THING in ftp server's index
        get FILE                get a file and have it mailed to you
                                        (max 10 GET's per ftpmail session)
        quit                    terminate script, ignore rest of mail message
                                        (use if you have a .signature or
                                         are a VMSMAIL user)

>>> notes:

        -> you should send complaints to the ftpmail-admin address.  our
           postmaster does not handle ftpmail problems and you can save her
           the trouble of forwarding your complaints by just mailing them to
           the right address.  the "ftpmail-request" address is gone; don't
           use it.

        -> the "index" command depends on the "SITE EXEC INDEX" feature of
           some ftp servers.  Gatekeeper.dec.com originated this feature,
           and ftp.uu.net duplicated it (with a format change to the output,
           naturally).  Wuarchive.wustl.edu also has this feature, though
           their index seems to be empty.  The source for an ftpd that
           supports this feature is on Gatekeeper.DEC.COM in /pub/DEC/gwtools.

        -> a password of "" or '' will be sent as a null string.  if you need
           this you will know it, if you don't, you won't.

        -> the "Subject:" of your request will be contained in the "Subject:"
           of all of ftpmail's responses to you regarding that request.  You
           can therefore use it to "tag" different requests if you have more
           than one outstanding at any given time.

        -> you must give a "connect" command, default host is
           gatekeeper.dec.com, default user is anonymous, default
           password is your mail address with a hyphen prepended.

        -> binary files will not be compressed unless 'compress' or 'compact'
           command is given; use this if at all possible, it helps a lot.
           note that many files are already compressed.  if you use any of
           the binary-file qualifiers (compress, compact, uuencode, btoa)
           without setting 'binary' first, your session will abort in error.

        -> binary files will always be formatted into printable ASCII
           with "btoa" or "uuencode" (default is "btoa").  if you don't
           use the "binary" command, ftpmail will cheerfully try to mail
           you the binary data, which will absolutely, positively fail.

        -> all retrieved files will be split into chunks and mailed.  the
           size of the chunk is 64000 characters unless you change it with
           the "chunksize" command.  CompuServe users will need to set this
           to 49000.  there is no way to set it higher than 100000, so please
           don't ask.

        -> if you ask for more than 10 files in a session, you will receive
           an error message and your entire request will be rejected.

        -> VMS/DOS/Mac versions of uudecode, atob, compress and compact
           are available, ask your LOCAL wizard about them if you can't
           locate them (but try gatekeeper.dec.com in /archive/pub/VMS
           if you're still using a VMS system.)

        -> several mail unsplitters are hiding on gatekeeper.dec.com in
           /pub/mail/ua/misc/unsplit.  there is one in c, one in perl,
           and one in VMS DCL.

        -> there is no way to request only certain parts of a file and we
           do not plan to add one in the near future, so please don't ask.

        -> there is no way to delete things from the queue or to find out
           the status of things in the queue, and we do not plan to add
           either feature in the near future, so please don't ask.

>>> examples:

        -> connect to gatekeeper.dec.com and get a root directory listing:
                connect
                ls
                quit

        -> connect to gatekeeper.dec.com and get the README.ftp file:
                connect
                get README.ftp
                quit

        -> connect to gatekeeper.dec.com and get the gnuemacs sources:
                connect
                binary
                uuencode
                chdir /pub/GNU
                get emacs-18.58.tar.Z
                quit

        -> connect to ftp.uu.net as anonymous and get a root directory list:
                connect ftp.uu.net
                binary
                chdir /index/master
                get by-name.Z
                quit

Ftpmail was written by Paul Vixie while at the DEC Western Research Laboratory
and at the DEC Network Systems Laboratory, from 1989-1993.  Ftpmail is not a
product or service of Digital Equipment Corporation and no support or warranty
is expressed or implied.
  -- End of Help --