RFC 1090

SMTP on X.25

πŸ“… published February 1989, from ietf

RFC 1090: SMTP on X.25 πŸŽ€

okay bestie, the title block first πŸ’…

  • Network Working Group 🌸
  • Author: R. Ullmann (Robert Ullmann) at Prime Computer, Inc. πŸ’–
  • Date: February 1989 πŸ“…
  • Status: the memo proposes a standard ✨
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates πŸ¦‹

1. Status of this Memo πŸ“

so this memo proposes a standard for SMTP running on the virtual circuit facility from the X.25 standard of the CCITT. 🌈 Distribution is totally unlimited, so share it with everyone 🫢

2. Introduction ✨

okay so SMTP is the protocol for sending email, and RFC 821 ("SIMPLE MAIL TRANSPORT PROTOCOL") mentions in appendix D that you could use the X.25 virtual circuit (ISO level 3) directly for it 🧚 RFC 821 says that "a reliable end-to-end protocol such as TCP be used on top of X.25 connections." πŸ€” That was honestly fair in 1981, because the PSDNs were not that reliable back then. 😭

But ngl, by 1989 the service is reliable enough for direct use of the virtual circuit, and it's giving real progress πŸ’…βœ¨

The procedures here have a proven track record in extensive production use across 24 PSDNs in 22 different countries 🌍 They're economical even on some of the pricier PSDNs, which is iconic πŸ’Έ Private X.25 connections and X.25 LANs have worked out well too πŸŽ€

Here's the main idea: an X.25 virtual circuit (VC) is opened for each SMTP session. The full duplex channel from the VC carries the session, and then the VC gets closed, normally by the calling side πŸ¦‹

3. Protocol ID and Call User Data πŸ”₯

The first four octets (bytes) of the Call User Data Field are commonly used as a protocol identifier, or PRID, and they should be C0F70000 in hex. That's 192 247 0 0 in decimal πŸ’–

Implementations should, however, be able to configure the call user data on a per-address basis, including the protocol ID field. Customizable is the vibe 🌸

4. Data stream 🌊

The SMTP data gets divided up (streamed into packets) in whatever way the sending side prefers, no judgement 🫢 Sequences with the M bit (more data) set are encouraged, and they may be up to 2048 bytes in total length. πŸ’œ

It is recommended that SMTP commands and responses each go as single packets, or single more-data sequences, if only to make debugging easier πŸ” This is not a requirement, so you do you πŸ’…

5. Qualified data 🚫

Packets with the Q bit set and interrupt packets are not used. If you do receive them, they should be ignored. Not your problem, bestie πŸ’€

6. Circuit resets πŸ”„

If a level 3 circuit reset is received, the VC should be cleared, and then the SMTP connection should be attempted again. The retry may come after some delay, and it may use different call facilities too. Second chances are giving main character energy ✨

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 on X.25 is the full ASCII-8 code, with no escapes or modifications, so it's totally raw πŸ™ˆ Lines are terminated by CRLF (13 10 decimal). Implementations should, if possible, recognize lines terminated only by LF (10 decimal). Be flexible, babe πŸ¦‹

9. Closing the connection πŸ‘‹

Okay, this one's important 😭 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. πŸ’€

So on X.25, the SMTP session layer is closed by the calling side when the Service Closing message is received. That happens either in response to a QUIT command, or because the service must shut down. ✨

10. Timeouts ⏰

SMTP doesn't normally provide for timing out a session. On X.25, though, 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 seconds, the call should be cleared and retried later. Patience is a whole aesthetic 🫠

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 it will not affect the SMTP transactions already completed. Messy but still iconic πŸ’…

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. Follow the spec, obsessed πŸ“–

11. Other features 🌈

Other X.25 features, such as permanent virtual circuits and D bit selection, are not used. Not every feature needs to be in the group chat πŸ’œ


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

πŸ“¦ where this page comes from