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