RFC 1204

Message Posting Protocol (MPP) ✨

Okay bestie, let's start with the title block 🎀 This is RFC 1204, filed under Network Working Group (Request for Comments: 1204), and it's dated February 1991 🌸

It was written by S. Yeh and D. Lee, both from Netix Communications, Inc. Their addresses are at the very bottom if you want to reach out 💜

It's an Experimental Protocol, which the Status of this Memo section below explains. The title block doesn't list anything it obsoletes or updates, so no drama there 🦋

---

Status of this Memo ✨

This memo is all about a protocol for posting messages from workstations (e.g., PCs) to a mail service host 💌 It specifies an Experimental Protocol for the Internet community, and they're literally asking for discussion and suggestions for improvement, so speak up 🗣️ For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards". Distribution of this memo is unlimited 🌈

1. INTRODUCTION ✨

Okay so here's the tea 🫖 Operating systems for personal computers don't give you a way to authenticate users. That's a huge problem for email, because knowing who really sent a message is what keeps mail forgery away 🕵️‍♀️

So if you want PCs on an email network, you need an agent, called the message posting server. It authenticates the sender's identity, then submits the mail to the message delivery system (e.g., Sendmail, MMDF) on behalf of the sender at the PC. 💅

The Netix Message Posting Protocol was made to be the interface between that message posting server and the PC (the client). It is designed to use TCP, and it borrows its command and reply structures from Simple Mail Transfer Protocol (RFC 821) and File Transfer Protocol (RFC 959). Iconic recycling ✨

2. SPECIFICATIONS 🎀

2.1. Command List

Here are the commands, no cap 👑

      USER <SP> <username> <CRLF>
      PASS <SP> <password> <CRLF>
      DATA <CRLF>
      NOOP <CRLF>
      QUIT <CRLF>

2.2. Reply List

These are the codes the server sends back to you 💬

      220 Message Posting Service Ready.
      221 Closing Connection.
      250 Command OK.

      354 Enter mail, end with <CRLF>.<CRLF>
      451 Local error encountered.
      500 Command unrecognized.
      501 Argument syntax error.
      503 Illegal command sequence.
      530 Authentication Failure.
      550 Error.

2.3. Command and Reply Descriptions

Now the main event, the commands and their replies 🦋

USER <SP> <username> <CRLF>

The USER command tells the message posting server who's trying to submit mail to the network, meaning the username. The required argument for USER is a string that specifies the message sender's username 💖

USER can only be used under three conditions, periodt 💅:

• when the session with the message posting server has just started;
• right after a message text (terminated by the "<CRLF>.<CRLF>" sequence) has been successfully submitted to the message posting server;
• right after a USER command that gets the reply code 501.

List of possible reply codes for the USER command:

• 250 The username of the message sender has been accepted.
• 451 Internal error has occurred in the message posting server.
• 501 Syntax error detected in the username argument.
• 503 The USER command has been used under an inappropriate condition (i.e., one that is not specified above).

It is recommended that the message posting server should return 250 even if the username isn't recognized, as long as it's syntactically correct. This is an attempt to stop the server from leaking too much info about the user database 🙈 The client should not be able to test whether a certain username exists.

PASS <SP> <password> <CRLF>

The PASS command tells the message posting server the password that goes with the username you gave earlier 🔑 The required argument for PASS is a string that specifies the message sender's password.

PASS can only be used under two conditions:

• right after a USER command that gets the reply code 250;
• right after a PASS command that gets the reply code 501.

List of possible reply codes for the PASS command:

• 250 The password has been accepted and verified to be correctly associated with the username previously specified.
• 451 Internal error has occurred in the message posting server.
• 501 Syntax error detected in the password argument.
• 503 The PASS command has been used under an inappropriate condition (i.e., one that is not specified above).
• 530 The password provided is not the one associated with the username previously specified.

DATA <CRLF>

The DATA command tells the message posting server to get ready to accept a mail message text 📨 No argument is expected. (This command has the same meaning as the DATA command defined in RFC 821.)

DATA can only be used under two conditions:

• right after a PASS command that gets the reply code 250;
• right after a mail message text has been successfully accepted from the client.

List of possible reply codes for the DATA command:

• 354 The message posting server is ready to accept the mail message text.
• 451 Internal error has occurred in the message posting server.
• 503 The DATA command has been used under an inappropriate condition (i.e., one that is not specified above).

Upon receiving the reply code 354 for the DATA command, the client should submit the mail message text to the message posting server and end the text with the sequence "<CRLF>.<CRLF>", as defined in RFC 821. If the message text includes the "<CRLF>.<CRLF>" sequence, then that sequence is replaced by the "<CRLF>..<CRLF>" sequence, as defined in RFC 821. The extra "." token will not be included in the final copy of the submitted message 🧚

Upon receiving the mail message text terminated by the "<CRLF>.<CRLF>" sequence, the list of possible reply codes is:

• 250 The mail message text has been successfully queued for delivery.
• 451 Internal error has occurred in the message posting server and the mail message text has not been queued.

NOOP <CRLF>

The NOOP command doesn't make the message posting server do anything. Instead, it checks the server's status, like a little vibe check 🧘‍♀️ No argument is expected.

NOOP cannot be used under one condition:

• right after a DATA command that gets the reply code 354 (i.e., when the message posting server is expecting the client to submit the mail message text).

List of possible reply codes for the NOOP command:

• 250 The message posting server has not encountered any internal error.
• 451 Internal error has occurred in the message posting server during the current session.

QUIT <CRLF>

The QUIT command ends the session with the message posting server 👋 No argument is expected.

QUIT can be used under any condition. The message posting server should always return the reply code 221 for the QUIT command.

3. IMPLEMENTATION OF THE MESSAGE POSTING SERVER 🛠️

There are several issues to be considered when implementing the message posting server:

• secured environment
• port number assignment
• handling of idle client
• local/remote password database
• message queuing
• handling of message delivery failure

3.1 Secured Environment

The message posting server is responsible for authenticating message senders and submitting mail to the message delivery system. Hence, it should be running in a secured environment, such as a system (UNIX, VMS, MS-DOS) with well restricted physical and network access 🔒

3.2 Port Number Assignment

Port 218 is assigned for the Netix Message Posting Protocol 🎀

3.3 Handling of Idle Client

The message posting server should terminate a session if the client has been idle for too long, to release the resource allocated for the session 💤

3.4 Local/Remote Password Database

To take advantage of existing password databases, such as the passwd file in UNIX, the message posting server can use FTP and POP3 to perform the username and password checking with the appropriate server 🗝️

For a network that does not have any password database, the message posting server should let the system administrator specify a local password file on the host that the message posting server is running.

3.5 Message Queuing

The message posting server should attempt to submit accepted messages to the message delivery system as soon as possible 🚀

3.6 Handling of Message Delivery Failure

Failure in delivering messages should be handled by the message delivery system, and the message posting server should not interfere 🙅‍♀️

4. REFERENCES 📚

• [1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1982.
• [2] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959, USC/Information Sciences Institute, October 1985.

Security Considerations 🔐

Okay bestie, this part is serious. Security issues are discussed in section 3.1. Go read it before anything else 😭

Authors' Addresses 🫶

Shannon Yeh
Netix Communications, Inc.
15375 Barranca Parkway, Suite A-215
Irvine, CA 92718

Phone: (714) 727-9335

Email: yeh@netix.com


David Lee
Netix Communications, Inc.
15375 Barranca Parkway, Suite A-215
Irvine, CA 92718

Phone: (714) 727-9335

EMail: dlee@netix.com