Message Posting Protocol (MPP)
Protocol for personal computers to submit outgoing mail to a mail service host.
Yeh, S. and D. Lee, "Message Posting Protocol (MPP)", RFC 1204, DOI 10.17487/RFC1204, February 1991, <https://www.rfc-editor.org/info/rfc1204>.
@misc{rfc1204,
series = {Request for Comments},
number = 1204,
howpublished = {RFC 1204},
publisher = {RFC Editor},
doi = {10.17487/RFC1204},
url = {https://www.rfc-editor.org/info/rfc1204},
author = {S. Yeh and D. Lee},
title = {{Message Posting Protocol (MPP)}},
pagetotal = 6,
year = 1991,
month = feb,
} RFC text
Contents
Network Working Group S. Yeh
Request for Comments: 1204 D. Lee
Netix Communications, Inc.
February 1991
Message Posting Protocol (MPP)
Status of this Memo
This memo describes a protocol for posting messages from workstations
(e.g., PCs) to a mail service host. This RFC specifies an
Experimental Protocol for the Internet community. Discussion and
suggestions for improvement are requested. Please refer to the
current edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol. Distribution of
this memo is unlimited.
1. INTRODUCTION
Operating systems for personal computers do not provide a mechanism
for user authentication. However, such a mechanism is crucial for
electronic mail system since authenticating message sender's identity
is important in preventing mail forgery. Hence, adding personal
computers to an electronic mail network requires an agent (message
posting server) to authenticate sender's identity and then submit
mail to the message delivery system (e.g., Sendmail, MMDF) on behalf
of the sender at a PC. The Netix Message Posting Protocol is
developed to be the interface between the message posting server and
the PC (client). The protocol is designed to use TCP and is based on
the command and reply structures defined for Simple Mail Transfer
Protocol (RFC 821) and File Transfer Protocol (RFC 959).
2. SPECIFICATIONS
2.1. Command List
USER <SP> <username> <CRLF>
PASS <SP> <password> <CRLF>
DATA <CRLF>
NOOP <CRLF>
QUIT <CRLF>
2.2. Reply List
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
USER <SP> <username> <CRLF>
The USER command informs the message posting server about the
username of the user trying to submit mail to the network. The
required argument for the USER command is a string specifying
the message sender's username.
The USER command can only be used under three conditions:
- 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 is not recognized by the message
posting server, as long as the username is syntactically
correct. This is an attempt to prevent the message posting
server from releasing too much information about the user
database. Client should not be able to test the existence of a
certain username.
PASS <SP> <password> <CRLF>
The PASS command is used to inform the message posting server
about the password associated with the username previously
specified. The required argument for the PASS command is a
string specifying the message sender's password.
The PASS command 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 is used to inform 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.)
The DATA command 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 message posting
server and terminate the text by the sequence "<CRLF>.<CRLF>"
as defined in RFC 821. If the message text includes the
"<CRLF>.<CRLF>" sequence, then the 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, 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 does not cause any action to be performed by
the message posting server. Instead, it tests the status of
the message posting server. No argument is expected.
The NOOP command 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 is used to terminate the session with the
message posting server. No argument is expected.
The QUIT command 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 running on 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 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
Security issues are discussed in section 3.1.
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
AI ELI5
On this page
§1The Problem and Solution
Personal computers running operating systems like MS-DOS do not provide operating-system-level user authentication. This creates a problem for email: the email system must authenticate a sender's identity to prevent mail forgery. The solution is to use an intermediary agent called a message posting server that authenticates the sender and then submits mail to the message delivery system on behalf of the sender.
The Netix Message Posting Protocol defines the interface between the message posting server (running on a trusted host) and the PC client. The protocol uses TCP and is based on command-reply structures from RFC 821 (SMTP) and RFC 959 (FTP).
Your computer at home does not have a secure way to prove who you are. So you log in to a trusted mail server, and it sends your mail for you.
§2Commands and Reply Codes
The protocol defines five main commands. USER informs the server of the username attempting to send mail, restricted to three conditions: session start, after successful message submission, or after a syntax error on a previous USER command. PASS provides the password associated with the previously specified username.
DATA instructs the server to accept mail message text, followed by the client sending lines of message content terminated by a bare period on its own line (matching RFC 821 convention). NOOP tests the status of the server without performing any action. QUIT terminates the session.
Reply codes follow SMTP conventions: 220 (service ready), 250 (command OK), 354 (ready for message), 451 (local error), 500 (unrecognized command), 501 (syntax error), 503 (illegal command sequence), 530 (authentication failure), and 550 (error).
The protocol has simple commands: tell your name, give your password, say you want to send a message, send the message, and hang up.
§3Server Implementation Considerations
The RFC identifies several implementation issues for message posting servers. Security is paramount: the server must run in a secured environment with restricted physical and network access. Port 218 is assigned for the protocol.
Idle client handling should terminate sessions if no activity occurs for too long to free resources. For username and password verification, servers can leverage existing password databases (such as UNIX passwd files) using FTP and POP3, or maintain a local password file specified by the system administrator. The server should accept any syntactically correct username and return 250 to avoid leaking information about which usernames exist.
Accepted messages should be queued and submitted to the message delivery system immediately. Message delivery failures should be handled by the message delivery system itself, not by the message posting server.
The server needs to be careful about security, not keep clients connected forever, and pass messages to the real mail system quickly.
§4Security and Operational Status
The MPP protocol addresses one specific security problem: authenticating the originator of a message before it enters the mail system. By requiring username and password authentication on the message posting server, the server can verify that a PC user is who they claim to be before accepting their mail.
RFC 1204 remains an Experimental specification rather than a standard. While it provided an early approach to the problem of mail authentication from untrusted clients, later solutions like SMTP authentication extensions (SMTP AUTH) became the standardized approach for client authentication in the Internet email ecosystem.
The main security idea is to check who you are before letting you send mail. Later standards provided better ways to do this.