Difference between revisions of "RFC1204"

From RFC-Wiki
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
−
 
−
 
−
 
−
 
−
 
−
 
 
Network Working Group                                            S. Yeh
 
Network Working Group                                            S. Yeh
 
Request for Comments: 1204                                        D. Lee
 
Request for Comments: 1204                                        D. Lee
−
                                              Netix Communications, Inc.
+
                                          Netix Communications, Inc.
−
                                                          February 1991
+
                                                        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.
 
−
 
 
−
 
 
−
 
 
−
Yeh & Lee                                                     
 
−
 
 
−
RFC 1204                          MPP                      February 1991
 
−
 
 
  
−
      354 Enter mail, end with <CRLF>.<CRLF>
+
                  Message Posting Protocol (MPP)
−
      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
+
'''Status of this Memo'''
  
−
      USER <SP> <username> <CRLF>
+
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.
  
−
        The USER command informs the message posting server about the
+
== INTRODUCTION ==
−
        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:
+
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 ([[RFC821|RFC 821]]) and File Transfer Protocol ([[RFC959|RFC 959]]).
  
−
        - when the session with the message posting server has just
+
== SPECIFICATIONS ==
−
          started;
 
  
−
        - right after a message text (terminated by the "<CRLF>.<CRLF>"
+
=== Command List ===
−
          sequence) has been successfully submitted to the message
 
−
          posting server;
 
  
−
        - right after a USER command that gets the reply code 501.
+
  USER <SP> <username> <CRLF>
 +
  PASS <SP> <password> <CRLF>
 +
  DATA <CRLF>
 +
  NOOP <CRLF>
 +
  QUIT <CRLF>
  
−
        List of possible reply codes for the USER command:
+
=== Reply List ===
  
−
        - 250   The username of the message sender has been accepted.
+
  220 Message Posting Service Ready.
 +
  221 Closing Connection.
 +
  250 Command OK.
  
−
        - 451   Internal error has occurred in the message posting
+
  354 Enter mail, end with <CRLF>.<CRLF>
−
                server.
+
  451 Local error encountered.
 +
  500 Command unrecognized.
 +
  501 Argument syntax error.
 +
  503 Illegal command sequence.
 +
  530 Authentication Failure.
 +
  550 Error.
  
−
        - 501  Syntax error detected in the username argument.
+
=== Command and Reply Descriptions ===
  
−
        - 503  The USER command has been used under an inappropriate
+
  USER <SP> <username> <CRLF>
−
                condition (i.e., one that is not specified above).
 
  
−
        It is recommended that the message posting server should return
+
      The USER command informs the message posting server about the
−
        250 even if the username is not recognized by the message
+
      username of the user trying to submit mail to the network.  The
−
        posting server, as long as the username is syntactically
+
      required argument for the USER command is a string specifying
−
        correct.  This is an attempt to prevent the message posting
+
      the message sender's username.
−
        server from releasing too much information about the user
 
−
        database.  Client should not be able to test the existence of a
 
−
        certain 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;
  
−
Yeh & Lee                                                     
+
      - right after a USER command that gets the reply code 501.
  
−
RFC 1204                          MPP                      February 1991
+
      List of possible reply codes for the USER command:
  
 +
      - 250  The username of the message sender has been accepted.
  
−
       PASS <SP> <password> <CRLF>
+
       - 451  Internal error has occurred in the message posting
 +
              server.
  
−
        The PASS command is used to inform the message posting server
+
      - 501  Syntax error detected in the username argument.
−
        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:
+
      - 503  The USER command has been used under an inappropriate
 +
              condition (i.e., one that is not specified above).
  
−
        - right after a USER command that gets the reply code 250;
+
      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.
  
−
        - right after a PASS command that gets the reply code 501.
+
  PASS <SP> <password> <CRLF>
  
−
        List of possible reply codes for the PASS command:
+
      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.
  
−
        - 250  The password has been accepted and verified to be
+
      The PASS command can only be used under two conditions:
−
                correctly associated with the username previously
 
−
                specified.
 
  
−
        - 451  Internal error has occurred in the message posting
+
      - right after a USER command that gets the reply code 250;
−
                server.
 
  
−
        - 501   Syntax error detected in the password argument.
+
      - right after a PASS command that gets the reply code 501.
  
−
        - 503  The PASS command has been used under an inappropriate
+
      List of possible reply codes for the PASS command:
−
                condition (i.e., one that is not specified above).
 
  
−
        - 530   The password provided is not the one associated with the
+
      - 250   The password has been accepted and verified to be
−
                username previously specified.
+
              correctly associated with the username previously
 +
              specified.
  
−
       DATA <CRLF>
+
       - 451  Internal error has occurred in the message posting
 +
              server.
  
−
        The DATA command is used to inform the message posting server
+
      - 501  Syntax error detected in the password argument.
−
        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:
+
      - 503  The PASS command has been used under an inappropriate
 +
              condition (i.e., one that is not specified above).
  
−
        - right after a PASS command that gets the reply code 250;
+
      - 530  The password provided is not the one associated with the
 +
              username previously specified.
  
−
        - right after a mail message text has been successfully
+
  DATA <CRLF>
−
          accepted from the client.
 
  
−
        List of possible reply codes for the DATA command:
+
      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 [[RFC821|RFC 821]].)
  
−
        - 354  The message posting server is ready to accept the mail
+
      The DATA command can only be used under two conditions:
−
                message text.
 
  
 +
      - right after a PASS command that gets the reply code 250;
  
 +
      - right after a mail message text has been successfully
 +
        accepted from the client.
  
−
Yeh & Lee                                                     
+
      List of possible reply codes for the DATA command:
  
−
RFC 1204                          MPP                      February 1991
+
      - 354  The message posting server is ready to accept the mail
 +
              message text.
  
 +
      - 451  Internal error has occurred in the message posting
 +
              server.
  
−
        - 451   Internal error has occurred in the message posting
+
      - 503   The DATA command has been used under an inappropriate
−
                server.
+
              condition (i.e., one that is not specified above).
  
−
        - 503  The DATA command has been used under an inappropriate
+
      Upon receiving the reply code 354 for the DATA command, the
−
                condition (i.e., one that is not specified above).
+
      client should submit the mail message text to message posting
 +
      server and terminate the text by the sequence "<CRLF>.<CRLF>"
 +
      as defined in [[RFC821|RFC 821]]. If the message text includes the
 +
      "<CRLF>.<CRLF>" sequence, then the sequence is replaced by the
 +
      "<CRLF>..<CRLF>" sequence as defined in [[RFC821|RFC 821]].  The extra "."
 +
      token will not be included in the final copy of the submitted
 +
      message.
  
−
        Upon receiving the reply code 354 for the DATA command, the
+
      Upon receiving the mail message text terminated by the
−
        client should submit the mail message text to message posting
+
      "<CRLF>.<CRLF>" sequence, list of possible reply codes is:
−
        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
+
      - 250  The mail message text has been successfully queued for
−
        "<CRLF>.<CRLF>" sequence, list of possible reply codes is:
+
              delivery.
  
−
        - 250   The mail message text has been successfully queued for
+
      - 451   Internal error has occurred in the message posting
−
                delivery.
+
              server and the mail message text has not been queued.
  
−
        - 451  Internal error has occurred in the message posting
+
  NOOP <CRLF>
−
                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 does not cause any action to be performed by
+
      The NOOP command cannot be used under one condition:
−
        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).
  
−
        - right after a DATA command that gets the reply code 354
+
      List of possible reply codes for the NOOP command:
−
          (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.
  
−
        - 250   The message posting server has not encountered any
+
      - 451   Internal error has occurred in the message posting
−
                internal error.
+
              server during the current session.
  
−
        - 451  Internal error has occurred in the message posting
+
  QUIT <CRLF>
−
                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 is used to terminate the session with the
+
      The QUIT command can be used under any condition.  The message
−
        message posting server.  No argument is expected.
+
      posting server should always return the reply code 221 for the
 +
      QUIT command.
  
 +
== IMPLEMENTATION OF THE MESSAGE POSTING SERVER ==
  
 +
There are several issues to be considered when implementing the
 +
message posting server:
  
−
Yeh & Lee                                                     
+
- secured environment
 +
- port number assignment
 +
- handling of idle client
 +
- local/remote password database
 +
- message queuing
 +
- handling of message delivery failure
  
−
RFC 1204                          MPP                      February 1991
+
=== 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.
  
−
        The QUIT command can be used under any condition.  The message
+
=== Port Number Assignment ===
−
        posting server should always return the reply code 221 for the
 
−
        QUIT command.
 
  
−
3. IMPLEMENTATION OF THE MESSAGE POSTING SERVER
+
Port 218 is assigned for the Netix Message Posting Protocol.
  
−
  There are several issues to be considered when implementing the
+
=== Handling of Idle Client ===
−
  message posting server:
 
  
−
  - secured environment
+
The message posting server should terminate a session if the client
−
  - port number assignment
+
has been idle for too long, to release the resource allocated for the
−
  - handling of idle client
+
session.
−
  - local/remote password database
 
−
  - message queuing
 
−
  - handling of message delivery failure
 
  
−
3.1  Secured Environment
+
=== Local/Remote Password Database ===
  
−
  The message posting server is responsible for authenticating message
+
To take advantage of existing password databases, such as the passwd
−
  senders and submitting mail to the message delivery system.  Hence,
+
file in UNIX, the message posting server can use FTP and POP3 to
−
  it should be running in a secured environment, such as running on a
+
perform the username and password checking with the appropriate
−
  system (UNIX, VMS, MS-DOS) with well restricted physical and network
+
server.
−
  access.
 
  
−
3.2  Port Number Assignment
+
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.
  
−
  Port 218 is assigned for the Netix Message Posting Protocol.
+
=== Message Queuing ===
  
−
3.3  Handling of Idle Client
+
The message posting server should attempt to submit accepted messages
 +
to the message delivery system as soon as possible.
  
−
  The message posting server should terminate a session if the client
+
=== Handling of Message Delivery Failure ===
−
  has been idle for too long, to release the resource allocated for the
 
−
  session.
 
  
−
3.4  Local/Remote Password Database
+
Failure in delivering messages should be handled by the message
 +
delivery system and the message posting server should not interfere.
  
−
  To take advantage of existing password databases, such as the passwd
+
== REFERENCES ==
−
  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
+
[1] Postel, J., "Simple Mail Transfer Protocol", [[RFC821|RFC 821]],
−
  posting server should let the system administrator specify a local
+
    USC/Information Sciences Institute, August 1982.
−
  password file on the host that the message posting server is running.
 
  
−
 
+
[2] Postel, J., and J. Reynolds, "File Transfer Protocol", [[RFC959|RFC 959]],
−
 
+
    USC/Information Sciences Institute, October 1985.
−
 
 
−
 
 
−
 
 
−
 
 
−
Yeh & Lee                                                     
 
−
 
 
−
RFC 1204                          MPP                      February 1991
 
−
 
 
−
 
 
−
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 Considerations
  
−
  Security issues are discussed in section 3.1.
+
Security issues are discussed in section 3.1.
  
 
Authors' Addresses
 
Authors' Addresses
  
−
  Shannon Yeh
+
Shannon Yeh
−
  Netix Communications, Inc.
+
Netix Communications, Inc.
−
  15375 Barranca Parkway, Suite A-215
+
15375 Barranca Parkway, Suite A-215
−
  Irvine, CA 92718
+
Irvine, CA 92718
−
 
 
−
  Phone: (714) 727-9335
 
−
 
 
− 
−
 
 
−
 
 
−
  David Lee
 
−
  Netix Communications, Inc.
 
−
  15375 Barranca Parkway, Suite A-215
 
−
  Irvine, CA 92718
 
−
 
 
−
  Phone: (714) 727-9335
 
−
 
 
− 
−
 
 
−
 
 
−
 
 
−
 
 
  
 +
Phone: (714) 727-9335
  
 +
  
 +
David Lee
 +
Netix Communications, Inc.
 +
15375 Barranca Parkway, Suite A-215
 +
Irvine, CA 92718
  
 +
Phone: (714) 727-9335
  
−
Yeh & Lee
+

Latest revision as of 13:54, 16 October 2020

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.

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).

SPECIFICATIONS

Command List

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

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.

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.

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

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.

Port Number Assignment

Port 218 is assigned for the Netix Message Posting Protocol.

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.

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.

Message Queuing

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

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.

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: [email protected]

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

Phone: (714) 727-9335

EMail: [email protected]

Retrieved from "https://rfc-wiki.org/index.php?title=RFC1204&oldid=19329"