rfc1168.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Westine, DeSchon, Postel & Ward                                 [Page 6]

RFC 1168      Intermail and Commercial Mail Relay Services     July 1990


   In addition, we cannot allow CMR or Intermail to be used simply as a
   bridge between two commercial systems, even though CMR has this
   technical capability.  At least one end of the communication must be
   related to FRICC acceptable use.

DETAILS OF CMR SYSTEM USE

   The CMR host computer is Internet host INTERMAIL.ISI.EDU
   (128.9.2.203).  The users of the commercials system are required to
   know the proper gateways between the Internet and other networks such
   as BITNET, CSNET, or UUCP.  Users on networks interconnected to the
   Internet likewise need to know how to reach the Internet to send mail
   through INTERMAIL.ISI.EDU to a commercial system.

   The relay connection to Telemail is through their host TELEMAIL/USA.
   The general syntax for Telemail addresses is
   "[USER/ORGANIZATION]HOST/COUNTRY", making the full address for the
   relay mailbox:

                      [INTERMAIL/USCISI]TELEMAIL/USA

   Users across the entire Telemail service can send mail to this
   address.  Users on the TELEMAIL host need only send to INTERMAIL.

   Internet users can use the basic Telemail format, append a
   "%TELEMAIL" to it, and mail to the resulting address as if it really
   existed on INTERMAIL.ISI.EDU, e.g.:

           [CWARD/USCISI]TELEMAIL/[e-mail]

   Note that the CMR system will accept anything before the "%TELEMAIL",
   that is, the CMR does not validate Telemail addresses before
   transmitting them to Telemail.

   The CMR handles Dialcom mail delivery in a similar way, but this
   system has what might be called "virtual hosts".  Groups can be set
   up with an alias system to allow easier intra-group access.  For
   example, both NSF and USDA share the same Dialcom host (157); but,
   while both groups send relay messages to Intermail, their actual
   fully qualified Dialcom mailboxes are different. For example, NSF's
   mailbox is NSF153, and USDA's mailbox is AGS9999.

   Mail going in either direction may use an embedded Simple Forwarding
   Header.  An SFH must be the first part of the message text.  It
   starts with a "Forward:"  field followed by a "To:" field.  "Cc:",
   "Subject:", and other fields may follow the "To:" fields. The SFH is
   terminated by a blank line.




Westine, DeSchon, Postel & Ward                                 [Page 7]

RFC 1168      Intermail and Commercial Mail Relay Services     July 1990


   This is a template of an SFH:

      Forward: Destination-Network
      To: User@host1, User@host2,
           User2@host2
      Cc: User@host1
      Subject: This subject supercedes the subject in the host net header
      <Blank-Line>

   Dialcom syntax is "Host-ID:User-ID", for example, 134:ABC1234.  This
   format will work from any Dialcom host; but users in the same group
   as ABC would be able to use the user name, for example, JSMITH.

   Using the SFH format, mail to a Dialcom system could be sent as
   follows:

      To: [e-mail]
      Subject:  Test Message

      Forward: Compmail
      To: 134:ABC1234

      Here is the text of the message.

   Proper destination network names include ARPA, Telemail, Compmail,
   NSF-Mail, and USDA-Mail.

   It is possible for a user to make mistakes at many points in the
   process. Errors are handled as automatically as possible by the CMR.
   Many errors are caught in the standard Internet mail traffic, and
   users receive the usual error messages from the system.  Messages
   with incorrect commercial system addresses or faulty SFHs are also
   automatically returned to sender.  Messages that the software cannot
   handle are sent to the CMR's user-service mailbox, Intermail-
   [e-mail].  This mailbox has been set up to take care of user
   problems and to be a central distribution point for user
   instructions.

PROBLEMS

   Several problems arise from the store-and-forward nature of the CMR.
   One of the biggest is that almost all of the commercial systems lack
   a machine-to-machine interface -- the CMR software must mimic a human
   user of the commercial system.  Another problem is that the Internet
   and a commercial system have different forms (or syntax) for
   electronic mail addresses.  A major goal of the CMR project is to
   make the link between networks as transparent as possible, allowing
   Internet users to use off-the-shelf mail programs.  Making commercial



Westine, DeSchon, Postel & Ward                                 [Page 8]

RFC 1168      Intermail and Commercial Mail Relay Services     July 1990


   address formats fit the Internet standard is a major task [2].

   Compatibility with Internet addressing standards is also a concern.
   The commercial accounts are not able to take advantage of the
   transparency features of the Domain Name System (DNS) (see Appendix
   D); and some commercial addresses are incompatible with the Internet
   syntax--this requires Internet users to continue using the older
   methods.

   Another general problem to be solved is to reduce the amount of time
   needed to maintain the system.  Because most commercial systems force
   our software to mimic a human user, automatic error detection and
   handling are quite complex. The Intermail system requires human
   intervention in processing failed mail.  A goal of the CMR is to
   fully automate these processes.

   A related problem facing the CMR, as well as its predecessor
   Intermail, is the frequency with which commercial systems change
   their software.  The changes are usually minor and do not bother most
   human users; however, the CMR depends on being able to recognize
   certain strings.  To avoid the necessity of rebuilding the whole CMR
   when these strings change, most of the string markers are stored in
   ASCII files that are read at run time.

   The translation of commercial system addresses has created a new set
   of problems,  most of which are caused by the use of "special"
   characters by the commercial systems.

   Telemail uses square brackets ("[" and "]") around user names. While
   these characters are not special by Internet standards when found in
   the local part of an address, many (perhaps most) Internet mailers
   refuse to accept these characters unless they are quoted.  MMDF was
   modified locally to correct this.

   The square bracket problem is even worse for users of IBM mainframe
   machines, many of which are used on BITNET.  The square bracket is
   not a printable character on many BITNET IBM hosts, and all kinds of
   strange addresses can result from its use.

   The colon is another example.  Dialcom uses it as the delimiter
   between host and mailbox.  However, the colon is a special character
   in the Internet mail standard [2].  Users can avoid this problem by
   using the SFH and placing the Dialcom address at the beginning of the
   message text.  Although the CMR can accept addresses with colons,
   many Internet hosts and relays are unable to accept addresses that
   contain colons.  Mail with colons in the address fields is often
   rejected by Internet hosts and is returned to the Intermail-Request
   mailbox for error processing.  This can cause significant delays.



Westine, DeSchon, Postel & Ward                                 [Page 9]

RFC 1168      Intermail and Commercial Mail Relay Services     July 1990


   Problems have also been caused by confusion about which hosts are
   mail relays between the Internet and other systems compatible with
   the Internet mail standard [2]. (e.g., BITNET, UUCP, and CSNET).
   When the CMR was implemented, a decision was made that the CMR would
   not keep track of these mail relays.  When a relay is changed, as the
   BITNET mail relays were in 1988, mail may be rejected because the
   host either no longer exists or refuses the mail.

   The mail relay problem is a subset of the larger problem of
   communicating information about new features and changes to the user
   community. Virtually none of the users of the CMR are local.  Many
   are hidden behind the veil of the commercial system.  (Dealing with
   commercial system customer support people has proven to be
   frustrating -- few of them seem to understand the concept of
   machine-to-machine exchanges.) Enhancements to commercial software
   that necessitate minor changes can disrupt some CMR users for days.

   Another problem that has not been adequately solved is validation of
   commercial system addresses and processing of failed commercial
   system mail.  The Telemail system will not validate a user/host
   combination until after the full text of the message has been
   transmitted.  If a long message is sent to an invalid address, it can
   be very expensive in terms of wasted time and connect charges.

   Telemail also gives inadequate information when the host is correct
   but the user name is not.  The failed mail notice received from
   Telemail is of little use to either a human reader or the CMR
   software.  The only information that Telemail returns is the message
   ID number -- it provides no subject, and no text to distinguish the
   message from the numerous others that pass through the mailbox.

   Dialcom does a better job of validating addresses.  If an address is
   not recognized, the system immediately prompts for a correction.  A
   simple <RETURN> will delete the invalid address from the list.

   The commercial systems are geared for paying customers to send and
   receive mail to other paying customers.  They are not equipped to
   handle reverse billing, or "collect calls."  ISI is currently charged
   for connect time needed to transmit and receive mail to and from
   other Internet sites.  A possible solution to this problem would be
   to extend the CMR. to include accounting and billing procedures that
   would pass the costs of CMR to its users.

   What had been GTE Telemail became Sprint SprintMail, Telenet became
   Sprintnet, and the host TELEMAIL/USA became SM66/USA.

   In April 1990, Sprint installed its X.400 implementation.  For the
   time being, the old-style Interconnect syntax will work. The CMR



Westine, DeSchon, Postel & Ward                                [Page 10]

RFC 1168      Intermail and Commercial Mail Relay Services     July 1990


   telemail channel and the Simple Forwarding Header (SFH) processor,
   were modified to accept either format in the SprintMail "From" field.

   Sprint uses the following syntax for X.400:

                      (O:USCISI,UN:INTERMAIL,TS:SM66)

   The SFH processor will "translate" this into:

                 /O=USCISI/UN=INTERMAIL/TS=SM66/%TELEMAIL

   The channel program will reverse the process.  In the translation,
   parentheses become slashes, colons become equal signs and commas
   become slashes and vice versa.

   Unfortunately, the translation algorithm is not foolproof.  A
   Sprint/Internet relay did not use the same field names and values as
   those in SprintMail.  Consequently, a CMR translated address can not
   be sent unmodified to Sprint's relay, Sprint.COM, and Sprint.COM
   processed addresses cannot be sent unmodified to the CMR.

   From experimentation, the modifications necessary to a CMR processed
   address to make it acceptable to Sprint.COM are (1) take the "non-
   standard" X.400 fields of "UN" and "TS" and prepend "DD." to them,
   (2) add the country field and code (C:US) and (3) add the Telemail
   administrative domain name (ADMD:Telemail).  The above example would
   become:

    /O=USCISI/DD.UN=INTERMAIL/DD.TS=SM66/ADMD=TELEMAIL/C=US/@Sprint.COM

   The country code must be changed from "US" to "USA."  The CMR queue
   name must also be appended: "%TELEMAIL."

   The situation is further complicated by Sprint's decision to only
   relay mail to and from its own administrative domain.  Other X.400
   ADMDs may be added in the future if payment problems can be overcome.

   SprintMail encoded Internet addresses are not parsed correctly by the
   SFH processor, but that should not be a major problem -- who on the
   Internet is going to send to the commercial side of the relay?

   When the NSF decided to terminate NSFMAIL, it became clear that the
   CMR Project needed a way to get news out to the commercial users.
   The CMR channel programs now are able to append a news file to the
   end of messages going into the commercial networks.  After
   transmitting a message, each channel checks for a news file with the
   channel name and if present, sends it.




Westine, DeSchon, Postel & Ward                                [Page 11]

RFC 1168      Intermail and Commercial Mail Relay Services     July 1990


   The biggest costs of the CMR are the connect times to the Sprintnet
   X.25 network and the commercial machines.  Making the CMR transmit
   faster is the current number one problem.

   Three strategies are being pursued:

      - Improve the implementation of the current method

      - Change the method to take advantage of changes in the commercial
        software

      - Upgrade the modems and increase the number of phone lines

   For a list of known problems or bugs in the CMR software, see the
   Appendix of the program logic manual [6].

FUTURE DIRECTIONS

   No software project is ever completed, and the CMR is no exception.
   There are many possible extensions, some more difficult than others.

   One addition that will be made to the CMR is a channel for
   interacting with MCI Mail.  MCI Mail is one of the original TOPS-20
   commercial systems that were serviced by Intermail; the CMR will need
   to replace this function before all of the TOPS-20 machines are
   removed from service on the Internet.

   The adaptability of the CMR is such that adding new commercial
   systems should not be a major problem.  Additional commercial systems
   under consideration include General Electric's GENIE, Western Union's
   EasyLink, and Compuserve.

   One possible addition to the CMR system could be maintenance of a
   list of gateways.  This would allow commercial system users to
   incorporate the native address formats of other networks into the
   SFHs.  An advantage of this would be that users could simply tell the
   CMR to forward a message to BITNET, for example, and the CMR would
   find the gateway and properly format the address for that gateway.

   To increase the ease of use to Internet users, the system might treat
   each commercial system as an Internet host and create DNS database
   records for them.  This would allow users to send mail to a non-
   Internet user at an Internet-style domain name.

   Another improvement would be the possibility of accepting X.400-style
   addressing. The current system rejects them.





Westine, DeSchon, Postel & Ward                                [Page 12]