From: Paul Robinson <[log in to unmask]>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
-----
In The Matter of SMTP
via Modem
over the Public Switched Telephone Network.
July 28, 1993
Paul Robinson
[log in to unmask]
This is published to provide
commentary and response by members of the internet
community. It should
not be referenced by other documents as it is not permanent.
This document is published to solicit for comment and
opinion. Please E-Mail comments, suggestions, opinions
and/or criticism to the author.
Background
----------
Current methods used to allow a site of group of sites to
collect and transmit messages, such as mail (and Usenet News
transported as mail) for their users on the site(s) via the
Internet, will require one of:
- An expensive Full Internet connection via TCP/IP and a
router;
- An expensive SLIP dialup account plus high hourly
metering;
- An expensive and complicated UUCP connection plus high
hourly metering;
- A service account on a commercial provider, with a high
fee per message sent, and no access to news groups.
All of these involve costs of at $25 a month or more, plus
usage charges or high metering in some cases, making use of
these services expensive.
If a site wants Telnet, FTP, Gopher, Whois, IRC and other
features using or requiring Full Internet service, then a
TCP/IP or SLIP connection is appropriate. But for sites
that don't want or can't use them, this type of connection
is akin to "using nuclear weapons to kill flies."
Assuming a site gets a mail (and news) feed, it usually
involved putting up an intricate and complicated UUCP
session, and all the overhead it requires, even if all that
is desired is to move mail (and news) around the Internet.
It was my own interest in obtaining this type of capability
that got me interested in figuring out if a low cost mail
(and news) service could be made available. The easiest way
to do this was to use the Simple Mail Transport Protocol
(SMTP) which has implementations already existing or can be
developed without too much difficulty. It also means that
once a message is accepted via SMTP, further transfers into
the Internet are almost trivial. By making this accessible
as a gateway which can be called up via a modem-equipped
computer over the telephone, it can make the service
inexpensive.
But would this really mean greater availability of
inexpensive mail (and news)? Based on cost figures, a
single-user account could be set up on a gateway at the
typical charge by a commercial mail provider, e.g. $3 per
month, which would allow a user to connect to the gateay and
send and receive messages for up to 30 minutes a day without
additional charges.
For slightly more (perhaps $7 per month) a site with a
subdomain name could allow its users to send and receive
mail (and news) for the same amount of time, but allocated
monthly, e.g. 15 hours of connection each calendar month.
Additionally, for around $25, a group of ten sites could
pool their connections and have one of them pick up and
deliver mail (and news) which is destined for or received
from any of their subdomain sites, and use up to two hours
per day of connection time.
Additional usage could be charged at 1 cent per minute or
perhaps less. The suggested rates quoted here are probably
higher than is needed to cover costs and allow for
expansion. If the mail system is used heavily, charges will
decrease.
These options allow an individual to send out messages for
an effective cost of perhaps 1/2 cent each, or allows
operators of E-Mail sites such as Bulletin Board Systems and
companies with an E-Mail gateway, to put potentially
hundreds of users on the network for perhaps 1 cent each,
perhaps less.
Also, it can be of long-term benefit to the Internet in
general, because as people try out E-Mail, this will, in
some of them, "whet their appetite" so to speak, for the
other services that only a Full Internet connection can
provide, and thus encourage those that want more to move in
that direction, increasing the demand for the services and
thus encouraging their availability to more people, which
should reduce their costs, too.
It is possible to set up a gateway to provide message
transfers; SMTP is an easily implemented method of doing so;
it is not particularly difficult to use SMTP as a message
transfer protocol; but that brings us to....
The Issue
---------
In planning to provide a dial-up SMTP gateway for persons
planning to send mail (and news) across the Internet, to
keep the cost low (and to make sure people get what they pay
for and are not cheated), it is necessary to ensure (1) that
only an owner of an account on the gateway is able to send
or receive messages from or to that account, or to any
subdomain address(es) connected to that account; (2) that
they be authenticated to be able to meter their usage.
This necessity then spawned...
The Problem
-----------
RFC 841 (Dr. Postel's SMTP specification) provides no means
for chargeback or authentication schemes, since mail
transfers are normally done from one system to another as a
courtesy to each other. These systems either charge their
own users for costs or include network access as part of
their own overhead.
The problem lies with any particular caller who might give
the dialog "HELO" but otherwise has no means to authenticate
himself and can't necessarily be charged or billed for
usage.
This necessitates the development of...
A Solution
----------
This is "a" solution to the problem. I do not necessarily
claim it as the "best" solution or even an optimum one. It
is reasonable and not very difficult to accomplish. It
does, however, raise an additional issue.
There are several options which may be chosen:
(1) change the SMTP transaction stream in some manner.
This was immediately rejected as out of the question; I
can't break every mailer that complies with RFC 841 in
order to fix my problem.
(2) add an authentication mode to the HELO command.
Rejected for the same reason as #1; whatever works with
my system may have to work with others.
(3) add an authentication mode to the EHLO command.
Rejected because most RFC 841 compliant mailers don't
even *do* EHLO yet.
(4) add a command of some kind ahead of the SMTP
transaction stream. Ah! Now we have something!
The least intrusive of these is to put a prefix ahead of the
SMTP transaction stream. A prefix program or "logon"
program can be run ahead of the sendmail or other program or
whatever handles the messages, in order to issue the
authentication command ahead of the SMTP transactions.
Now, what can we use? Again, there are several options:
(1) Wait for a "raw" username and password. Rejected; if
there is a data error, part of the input data could be
cut off, resulting in extra login attempts.
(2) Use the "USER" and "PASS" commands from FTP. Rejected;
it might confuse people between this version of SMTP
and FTP.
(3) Use the "HELO" or "EHLO" command only. Rejected;
anyone can claim to be any account and sometimes do.
(4) Add a new command different from others in existence.
This seems to be the best thing under the
circumstances.
I decided to make a clean break and add a new command to be
used exclusively for SMTP authentication. This command is
used to indicate an SMTP connection will be made, by using a
command similar to "CONNECT USER PASSWORD" by using an
abbreviation of the "CONNECT" command, in the form of:
CONN
Followed by 1 space and the identifier of the account (which
may or may not be the same as the domain name), and then
followed by either end of line, or 1 or more spaces and the
password assigned to the account.
While in this document the command is shown in all upper
case, the command, account and password will be accepted in
upper, lower or mixed case without distinction.
If the command is issued without an account, an error
message is generated and the gateway waits for the command
to be reissued. If the command is issued with an account
but without a password, a check is made for whether a
password is required with the account. If one is, a request
is issued for the password.
If the account is valid and either does not require a
password or the password given is valid, the gateway will
begin an SMTP transaction starting with the usual "220 "
message, and proceeding through all the commands and data
ending with "QUIT" which ends the transaction stream and
disconnects.
Note that this is a "minimal" authentication. Since the
user's computer directly dials up the gateway, there aren't
any intervening sites which can monitor this, this form of
authentication is probably acceptable for anything short of
very critical applications.
Although the authentication dialog prior to the actual SMTP
conversation is not part of a standard SMTP message
transaction, to be consistent with it, messages from the
gateway will follow the standard, of a three digit number
followed by a space for the last message in sequence, and a
three digit number followed by a "-" for all prior messages
in that sequence.
Summary
-------
1. To implement a low cost sysstem for Internet mail (and
news), one solution was to provide a gateway which
could be accessed using a computer and a modem over the
public switched telephone network.
2. A method which would not require complicated protocols
by the gateway and thus keep costs down, was to use the
Simple Mail Transfer Protocol (SMTP).
3. In order to keep costs low, is to assess costs for use
of the gateway it is necessary to at least minimally
authenticate someone connecting to it.
4. A simple way to do this is to add an account identifier
(and password, if desired) "out of band" or ahead of
the SMTP transaction stream.
5. Once authenticated, a standard SMTP conversation takes
place.
Questions
---------
1. Would some other method than SMTP provide a not-very-
difficult means to transfer messages to and from the
Internet?
2. Is using a "prefix" ahead of the SMTP command stream an
acceptable means of authenticating a user connecting to
a system?
Currently, FTP uses "USER" and "PASS" for authentication;
this proposal intends to use a new "CONN" command for this
minimally authenticated SMTP; given these points,
3. Would it be acceptable or confusing to add the "USER" /
"PASS" authentication commands to this method in the
same manner as is used with FTP?
4. Is creating a new command (CONN) for minimal
authentication the right way to go?
5. Should an option like "USER=" and "PASS=" be added to
the optional EHLO command and allow it to be used
either in lieu of or in addition to the CONN command?
6. Should this be submitted as a proposal for an optional
standard for Internet? If so, should this be enhanced
to allow for stronger forms of authentication such as
Kerberos or other methods?
7. Are there other questions I should be asking, and are
there answers for these new questions?
Your responses to this document are appreciated,
Paul Robinson
Internet: [log in to unmask]
July 28, 1993
---
Paul Robinson - [log in to unmask]
-----
The following Automatic Fortune Cookie was selected only for this message:
Confidential memorandum - No time to xerox a copy for the entire office
-- Glossary of important business terms
|
