RFC 751 (rfc751) - Page 1 of 5

Survey of FTP mail and MLFL

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.