File: rfc1204.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (339 lines) | stat: -rw-r--r-- 11,033 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339






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.



Yeh & Lee                                                       [Page 1]

RFC 1204                          MPP                      February 1991


      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.




Yeh & Lee                                                       [Page 2]

RFC 1204                          MPP                      February 1991


      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.



Yeh & Lee                                                       [Page 3]

RFC 1204                          MPP                      February 1991


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



Yeh & Lee                                                       [Page 4]

RFC 1204                          MPP                      February 1991


         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.







Yeh & Lee                                                       [Page 5]

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 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









Yeh & Lee                                                       [Page 6]