Survey of FTP mail and MLFL
RFC 751

Document Type RFC - Unknown (December 1978; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 751 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
NWG/RFC 751                                          PDL 10 Dec 78 nnnnn

Network Working Group                                   P. David Lebling
Request for Comments: 751                                  (PDL@MIT-DMS)
NIC: nnnnn                                              10 December 1978

                      SURVEY OF FTP MAIL AND MLFL

Two surveys of Arpanet Server hosts were run between September 20, 1978
and December 11, 1978.  The intent was to determine the response of the
host's Server FTP program to:

(a) An attempt to mail to an unknown recipient at that host.  The
purpose of this survey was two-fold.  First, to determine whether the
host accepts mail for unknown recipients at all, and second, what
response the host gives if it does not accept such mail.

(b) An attempt to mail to a known recipient using the MLFL command
rather than the usual MAIL command.  This survey was undertaken to
determine the extent of support for the MLFL command among Server hosts,
and the sort of reply received if the Server does not support MLFL. MLFL
is potentially a 'better' form of communication than mail as the message
is sent over a data connection rather than the command connection.
Using the data connection eliminates the 'end-of-mail' marker and
'command reader' problems sometimes encountered over the command
connection.

The ground rules of the survey were that all sites listed as Servers in
the MIT/SAIL Host table were surveyed.  In many cases, a host listed as
a Server would not respond to an ICP at any time during the period of
the survey.  Once a host responded with what seemed to me to be a
'definitive' answer, I marked it as such and stopped surveying it.

                              MLFL Survey

The algorithm used was to ICP to socket 3 of the server (the standard
old-FTP socket).  Once a 300 response was received, I sent the MLFL
command.  Where I had the name of a real mailbox at a site (a
Header-person, for example) I used that, otherwise the name "**".  If a
site asked for a password (response 504) after the MLFL command I gave
"USER NETML" "PASS NETML" and retried the MLFL.  If the server replied
with a 255 SOCK command, I listened for the data-connection to be
established.  When it was, I transferred the mail file.  Interestingly
enough, most sites implement an RFC queueing algorithm that will allow
the user site to attempt to establish the data-connection from its end.

                                                                [Page 1]


NWG/RFC 751                                          PDL 10 Dec 78 nnnnn
Survey of FTP MAIL and MLFL

Complete FTP scripts may be found, if you are interested, on MIT-DM,
file NETDOC;MLFL SURVEY.

Sites are grouped by the general result they gave.

-site-          -last ftp reply if lost-                -when-

1) Sites that lost for various reasons:

BNL             530 NOT LOGGED IN.                      after MLFL
HARV-10         431 INVALID ENTRY - Try again           after USER
LLL-MFE         454 Login please                        after SOCK
LONDON          000 INDRA FTP Version 2.00  ...         after ICP
NBS-10          454 Login please                        after SOCK
WHARTON         454  DATA Connection error ...          after SOCK
WPAFB-AFAL      454 Login please                        after SOCK

Note: "when" describes the last action performed by the surveyer before
the indicated anomalous response.

   after ICP --         surveyer had done ICP to socket 3
   after MLFL --        surveyer had sent MLFL command
   after USER --        surveyer had sent USER NETML in response to
                        "504 Login please"
   after SOCK --        surveyer had attempted to connect to specified
                        data socket

2) Sites that don't support MLFL and say so:

AFWL            501 ML<?>FL **
CCA-SPEECH      501 ML<?>FL **
EGLIN           501 ML<?>FL **
LBL             506 Command not implemented.
LONDON-VDH      500 Command unrecognized
UCLA-CCN        500 COMMAND UNRECOGNIZED
WPAFB           501 ML<?>FL **

3) Sites that support MLFL (or at least go through all the right
motions):

AMES-67         MIT-AI          SRI-KL
BBN-TENEX       MIT-DMS         SU-AI
BBN-TENEXA      MIT-MC          SUMEX-AIM
BBN-TENEXD      MIT-ML          UCLA-ATS
BBN-TENEXE      MIT-XX          UCLA-SECURITY
BBN-UNIX        NBS-UNIX        USC-ECL
CCA-TENEX       OFFICE-1        USC-ISI
CMU-10A         PARC-MAXC       USC-ISIB
CMU-10B         PARC-MAXC2      USC-ISIC

                                                                [Page 2]


NWG/RFC 751                                          PDL 10 Dec 78 nnnnn
Survey of FTP MAIL and MLFL

DEC-MARLBORO    RADC-TOPS20     USC-ISIE
I4-TENEX        RAND-RCC        UTEXAS
ILL-UNIX        RAND-UNIX
LL              RUTGERS
LL-ASG          SRI-KA

4) Sites that support MLFL but require "USER NETML" "PASS NETML"
(Multics):

MIT-MULTICS
RADC-MULTICS

5) Others:

a) Sites that might support it if I could mail to a real user (some of
Show full document text