The RFC Archive
 The RFC Archive   RFC 1090   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 1090

SMTP on X.25

Last modified on Friday, February 24th, 1989

Permanent link to RFC 1090
Search GitHub Wiki for RFC 1090
Show other RFCs mentioning RFC 1090







Network Working Group                                         R. Ullmann
Request for Comments: 1090                          Prime Computer, Inc.
                                                           February 1989


                              SMTP on X.25

1. Status of this Memo

   This memo proposes a standard for SMTP on the virtual circuit
   facility provided by the X.25 standard of the CCITT.

   Distribution of this memo is unlimited.

2. Introduction

   The possibility of using the X.25 virtual circuit (ISO level 3)
   directly for SMTP is mentioned in RFC 821 ("SIMPLE MAIL TRANSPORT
   PROTOCOL"), in appendix D.  It suggests that "a reliable end-to-end
   protocol such as TCP be used on top of X.25 connections".  This was
   undoubtedly true considering the general reliability of the PSDNs at
   the time (1981).  The service is now (in 1989) reliable enough to
   allow practical direct use of the virtual circuit service.

   The procedures given here have proven to be successful in extensive
   production use, involving 24 PSDNs in 22 different countries.  The
   resulting service is economical even using some of the more expensive
   PSDNs.  Operation over private X.25 connections and X.25 LANs has
   also proven successful.

   An X.25 virtual circuit (VC) is opened for each SMTP session.  The
   full duplex channel provided by the VC is used for the session.  The
   VC is then closed, normally by the calling side.

3. Protocol ID and Call User Data

   The first four octets (bytes) of the Call User Data Field, which are
   commonly used as a protocol identifier, or PRID, should be (hex)
   C0F70000.  (In decimal, 192 247 0 0.)

   Implementations should, however, provide the ability to configure the
   call user data on a per-address basis, including the protocol ID
   field.

4. Data stream

   The SMTP data is divided into (streamed into) packets in any way the
   sending side prefers.  Sequences with the M bit (more data) set are



Ullmann                                                      PAGE 1 top


RFC 1090 SMTP on X.25 February 1989 encouraged, and may be up to 2048 bytes in total length. It is recommended that SMTP commands and responses be sent as single packets, or single more-data sequences, if only to facilitate debugging the protocol. This is not a requirement. 5. Qualified data Packets with the Q bit set and interrupt packets are not used, and should be ignored if received. 6. Circuit resets If a level 3 circuit reset is received, the VC should be cleared, and the SMTP connection attempted again. The retry may be after some delay, and may be with different call facilities. 7. Call facilities Any negotiable features selected by the X.25 call request facilities field may be used. Implementations should provide the ability to specify facilities for each called address. 8. Character code The character code used on X.25 is the full ASCII-8 code, with no escapes or modifications. Lines are terminated by CRLF (13 10 decimal). Implementations should, if possible, recognize lines terminated only by LF (10 decimal). 9. Closing the connection Unlike TCP, X.25 does not provide for synchronous delivery of data in transit when a clear request is in progress; any packets in transit are discarded when the VC is cleared. Therefore, on X.25, the SMTP session layer is closed by the calling side when the Service Closing message is received, either in response to a QUIT command, or because the service must shut down. 10. Timeouts SMTP does not normally provide for timing out a session. On X.25, the following has proven to be effective: 10.1. call request If a call accept is not received within 100 seconds, or the Service Ready message is not received within (another) 120 Ullmann PAGE 2 top

RFC 1090 SMTP on X.25 February 1989 seconds, the call should be cleared and retried later. 10.2. established After the protocol session is established, the circuit should be cleared if no response is received for 10 minutes. 10.3. closing After the QUIT command is issued, the timeout should be shortened to 20 seconds. This will sometimes cause an ungraceful exit, but this will not affect the SMTP transactions already completed. 10.4. clearing When the X.25 Clear Request packet has been sent, the VC should be timed out in accordance with the X.25 protocol specification. 11. Other features Other features of X.25, such as permanent virtual circuits and D bit selection, are not used. References [1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, USC Information Sciences Institute, August 1982. [2] CCITT Recommendation X.25, "Interface Between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode and Connected to Public Data Networks by Dedicated Circuit", International Telegraph and Telephone Consultative Committee, Fascicle VIII.3, Geneva, 1976; amended at Geneva, 1980 and Malaga-Torremolinos, 1984. ("Red Book") Author's Address Robert Ullmann 23A-32 Prime Computer, Inc. Technology Drive Milford, MA 01757 Phone: +1 508 478 8600 x1736 Email: Ariel@Relay.Prime.COM Ullmann PAGE 3 top

RFC 1090 SMTP on X.25 February 1989 Ullmann PAGE 4 top

SMTP on X.25 RFC TOTAL SIZE: 5915 bytes PUBLICATION DATE: Friday, February 24th, 1989 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 1090: The IETF Trust, Friday, February 24th, 1989
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement