As per Relevance of the word internal, we have this rfc below:











Network Working Group S.
Request for Comments: 1204 D.
Netix Communications, Inc
February 1991


Message Posting Protocol (MPP

Status of this

This memo describes a protocol for posting messages from
(e.g., PCs) to a mail service host. This RFC specifies
Experimental Protocol for the Internet community. Discussion
suggestions for improvement are requested. Please refer to
current edition of the "IAB Official Protocol Standards" for
standardization state and status of this protocol. Distribution
this memo is unlimited

1.

Operating systems for personal computers do not provide a
for user authentication. However, such a mechanism is crucial
electronic mail system since authenticating message sender's
is important in preventing mail forgery. Hence, adding
computers to an electronic mail network requires an agent (
posting server) to authenticate sender's identity and then
mail to the message delivery system (e.g., Sendmail, MMDF) on
of the sender at a PC. The Netix Message Posting Protocol
developed to be the interface between the message posting server
the PC (client). The protocol is designed to use TCP and is based
the command and reply structures defined for Simple Mail
Protocol (RFC 821) and File Transfer Protocol (RFC 959).

2.

2.1. Command

USER <username> PASS <password> DATA NOOP QUIT
2.2. Reply

220 Message Posting Service Ready
221 Closing Connection
250 Command OK



Yeh & Lee [Page 1]

RFC 1204 MPP February 1991


354 Enter mail, end with . 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

USER <username>
The USER command informs the message posting server about
username of the user trying to submit mail to the network.
required argument for the USER command is a string
the message sender's username

The USER command can only be used under three conditions

- when the session with the message posting server has
started

- right after a message text (terminated by the "."
sequence) has been successfully submitted to the
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
server

- 501 Syntax error detected in the username argument

- 503 The USER command has been used under an
condition (i.e., one that is not specified above).

It is recommended that the message posting server should
250 even if the username is not recognized by the
posting server, as long as the username is
correct. This is an attempt to prevent the message
server from releasing too much information about the
database. Client should not be able to test the existence of
certain username




Yeh & Lee [Page 2]

RFC 1204 MPP February 1991


PASS <password>
The PASS command is used to inform the message posting
about the password associated with the username
specified. The required argument for the PASS command is
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
correctly associated with the username
specified

- 451 Internal error has occurred in the message
server

- 501 Syntax error detected in the password argument

- 503 The PASS command has been used under an
condition (i.e., one that is not specified above).

- 530 The password provided is not the one associated with
username previously specified

DATA
The DATA command is used to inform the message posting
to get ready to accept a mail message text. No argument
expected. (This command has the same meaning as the
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
accepted from the client

List of possible reply codes for the DATA command

- 354 The message posting server is ready to accept the
message text



Yeh & Lee [Page 3]

RFC 1204 MPP February 1991


- 451 Internal error has occurred in the message
server

- 503 The DATA command has been used under an
condition (i.e., one that is not specified above).

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

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

- 250 The mail message text has been successfully queued
delivery

- 451 Internal error has occurred in the message
server and the mail message text has not been queued

NOOP
The NOOP command does not cause any action to be performed
the message posting server. Instead, it tests the status
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
to submit the mail message text).

List of possible reply codes for the NOOP command

- 250 The message posting server has not encountered
internal error

- 451 Internal error has occurred in the message
server during the current session

QUIT
The QUIT command is used to terminate the session with
message posting server. No argument is expected



Yeh & Lee [Page 4]

RFC 1204 MPP February 1991


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

3. IMPLEMENTATION OF THE MESSAGE POSTING

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

- secured
- port number
- handling of idle
- local/remote password
- message
- handling of message delivery

3.1 Secured

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

3.2 Port Number

Port 218 is assigned for the Netix Message Posting Protocol

3.3 Handling of Idle

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

3.4 Local/Remote Password

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

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







Yeh & Lee [Page 5]

RFC 1204 MPP February 1991


3.5 Message

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

3.6 Handling of Message Delivery

Failure in delivering messages should be handled by the
delivery system and the message posting server should not interfere

4.

[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

Security issues are discussed in section 3.1.

Authors'

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

Phone: (714) 727-9335

Email: yeh@netix.


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

Phone: (714) 727-9335

EMail: dlee@netix.









Yeh & Lee [Page 6]







if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum