File: rfc2476.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 (843 lines) | stat: -rw-r--r-- 30,049 bytes parent folder | download | duplicates (8)
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
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843






Network Working Group                                        R. Gellens
Request for Comments: 2476                                     QUALCOMM
Category: Standards Track                                    J. Klensin
                                                                    MCI
                                                          December 1998


                           Message Submission

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table of Contents

    1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  2
    2.  Document Information  . . . . . . . . . . . . . . . . . . .   3
      2.1.  Definitions of Terms Used in this Memo . . . . . . . . .  3
      2.2.  Conventions Used in this Document . . . . . . . . . . .   4
    3.  Message Submission . . . . . . . . . . . . . . . . . . . . .  4
      3.1.  Submission Identification . . . . . . . . . . . . . . .   4
      3.2.  Message Rejection and Bouncing . . . . . . . . . . . . .  4
      3.3.  Authorized Submission . . . . . . . . . . . . . . . . .   5
      3.4.  Enhanced Status Codes  . . . . . . . . . . . . . . . . .  6
    4.  Mandatory Actions . . . . . . . . . . . . . . . . . . . . .   6
      4.1.  General Submission Rejection Code  . . . . . . . . . . .  6
      4.2.  Ensure All Domains are Fully-Qualified  . . . . . . . .   6
    5.  Recommended Actions  . . . . . . . . . . . . . . . . . . . .  7
      5.1.  Enforce Address Syntax  . . . . . . . . . . . . . . . .   7
      5.2.  Log Errors . . . . . . . . . . . . . . . . . . . . . . .  7
    6.  Optional Actions  . . . . . . . . . . . . . . . . . . . . .   7
      6.1.  Enforce Submission Rights  . . . . . . . . . . . . . . .  7
      6.2.  Require Authentication  . . . . . . . . . . . . . . . .   8
      6.3.  Enforce Permissions  . . . . . . . . . . . . . . . . . .  8
      6.4.  Check Message Data  . . . . . . . . . . . . . . . . . .   8
    7.  Interaction with SMTP Extensions . . . . . . . . . . . . . .  8
    8.  Message Modifications . . . . . . . . . . . . . . . . . . .   9
      8.1.  Add 'Sender' . . . . . . . . . . . . . . . . . . . . . .  9
      8.2.  Add 'Date'  . . . . . . . . . . . . . . . . . . . . . .  10
      8.3.  Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10



Gellens & Klensin           Standards Track                     [Page 1]

RFC 2476                   Message Submission              December 1998


      8.4.  Transfer Encode . . . . . . . . . . . . . . . . . . . .  10
      8.5.  Sign the Message . . . . . . . . . . . . . . . . . . . . 10
      8.6.  Encrypt the Message . . . . . . . . . . . . . . . . . .  10
      8.7.  Resolve Aliases  . . . . . . . . . . . . . . . . . . . . 10
      8.8.  Header Rewriting  . . . . . . . . . . . . . . . . . . .  10
    9.  Security Considerations  . . . . . . . . . . . . . . . . . . 11
   10.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  11
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . . 12
   12.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
   13.  Full Copyright Statement  . . . . . . . . . . . . . . . . .  15

1.  Abstract

   SMTP was defined as a message *transfer* protocol, that is, a means
   to route (if needed) and deliver finished (complete) messages.
   Message Transfer Agents (MTAs) are not supposed to alter the message
   text, except to add 'Received', 'Return-Path', and other header
   fields as required by [SMTP-MTA].

   However, SMTP is now also widely used as a message *submission*
   protocol, that is, a means for message user agents (MUAs) to
   introduce new messages into the MTA routing network.  The process
   which accepts message submissions from MUAs is termed a Message
   Submission Agent (MSA).

   Messages being submitted are in some cases finished (complete)
   messages, and in other cases are unfinished (incomplete) in some
   aspect or other.  Unfinished messages need to be completed to ensure
   they conform to [MESSAGE-FORMAT], and later requirements.  For
   example, the message may lack a proper 'Date' header field, and
   domains might not be fully qualified.  In some cases, the MUA may be
   unable to generate finished messages (for example, it might not know
   its time zone).  Even when submitted messages are complete, local
   site policy may dictate that the message text be examined or modified
   in some way.  Such completions or modifications have been shown to
   cause harm when performed by downstream MTAs -- that is, MTAs after
   the first-hop submission MTA -- and are in general considered to be
   outside the province of standardized MTA functionality.

   Separating messages into submissions and transfers allows developers
   and network administrators to more easily:

   *   Implement security policies and guard against unauthorized mail
       relaying or injection of unsolicited bulk mail

   *   Implement authenticated submission, including off-site submission
       by authorized users such as travelers




Gellens & Klensin           Standards Track                     [Page 2]

RFC 2476                   Message Submission              December 1998


   *   Separate the relevant software code differences, thereby making
       each code base more straightforward and allowing for different
       programs for relay and submission

   *   Detect configuration problems with a site's mail clients

   *   Provide a basis for adding enhanced submission services in the
       future

   This memo describes a low cost, deterministic means for messages to
   be identified as submissions, and specifies what actions are to be
   taken by a submission server.

   Public comments should be sent to the IETF Submit mailing list,
   <ietf-submit@imc.org>.  To subscribe, send a message containing
   SUBSCRIBE to <ietf-submit-request@imc.org>.  Private comments may be
   sent to the authors.

2.  Document Information

2.1.  Definitions of Terms Used in this Memo

   Fully-Qualified

   Containing or consisting of a domain which can be globally resolved
   using the global Domain Name Service; that is, not a local alias or
   partial specification.

   Message Submission Agent (MSA)

   A process which conforms to this specification, which acts as a
   submission server to accept messages from MUAs, and either delivers
   them or acts as an SMTP client to relay them to an MTA.

   Message Transfer Agent (MTA)

   A process which conforms to [SMTP-MTA], which acts as an SMTP server
   to accept messages from an MSA or another MTA, and either delivers
   them or acts as an SMTP client to relay them to another MTA.

   Message User Agent (MUA)

   A process which acts (usually on behalf of a user) to compose and
   submit new messages, and process delivered messages.  In the split-
   MUA model, POP or IMAP is used to access delivered messages.






Gellens & Klensin           Standards Track                     [Page 3]

RFC 2476                   Message Submission              December 1998


2.2.  Conventions Used in this Document

   In examples, "C:" is used to indicate lines sent by the client, and
   "S:" indicates those sent by the server.  Line breaks within a
   command example are for editorial purposes only.

   Examples use the 'example.net' domain.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in [KEYWORDS].

3.  Message Submission

3.1.  Submission Identification

   Port 587 is reserved for email message submission as specified in
   this document.  Messages received on this port are defined to be
   submissions.  The protocol used is ESMTP [SMTP-MTA, ESMTP], with
   additional restrictions as specified here.

   While most email clients and servers can be configured to use port
   587 instead of 25, there are cases where this is not possible or
   convenient.  A site MAY choose to use port 25 for message submission,
   by designating some hosts to be MSAs and others to be MTAs.

3.2.  Message Rejection and Bouncing

   MTAs and MSAs MAY implement message rejection rules that rely in part
   on whether the message is a submission or a relay.

   For example, some sites might configure their MTA to reject all RCPT
   TOs for messages that do not reference local users, and configure
   their MSA to reject all message submissions that do not come from
   authorized users, based on IP address, or authenticated identity.

   NOTE:  It is better to reject a message than to risk sending one that
   is damaged.  This is especially true for problems that are
   correctable by the MUA, for example, an invalid 'From' field.

   If an MSA is not able to determine a return path to the submitting
   user, from a valid MAIL FROM, a valid source IP address, or based on
   authenticated identity, then the MSA SHOULD immediately reject the
   message.  A message can be immediately rejected by returning a 550
   code to the MAIL FROM command.







Gellens & Klensin           Standards Track                     [Page 4]

RFC 2476                   Message Submission              December 1998


   Note that a null return path, that is, MAIL FROM:<>, is permitted
   and MUST be accepted. (MUAs need to generate null return-path
   messages for a variety of reasons, including disposition
   notifications.)

   Except in the case where the MSA is unable to determine a valid
   return path for the message being submitted, text in this
   specification which instructs an MSA to issue a rejection code MAY be
   complied with by accepting the message and subsequently generating a
   bounce message. (That is, if the MSA is going to reject a message for
   any reason except being unable to determine a return path, it can
   optionally do an immediate rejection or accept the message and then
   mail a bounce.)

   NOTE:  In the normal case of message submission, immediately
   rejecting the message is preferred, as it gives the user and MUA
   direct feedback.  To properly handle delayed bounces the client MUA
   must maintain a queue of messages it has submitted, and match bounces
   to them.

3.3.  Authorized Submission

   Numerous methods have been used to ensure that only authorized users
   are able to submit messages.  These methods include authenticated
   SMTP, IP address restrictions, secure IP, and prior POP
   authentication.

   Authenticated SMTP [SMTP-AUTH] has been proposed.  It allows the MSA
   to determine an authorization identity for the message submission,
   which is not tied to other protocols.

   IP address restrictions are very widely implemented, but do not allow
   for travellers and similar situations, and can be spoofed.

   Secure IP [IPSEC] can also be used, and provides additional benefits
   of protection against eavesdropping and traffic analysis.

   Requiring a POP [POP3] authentication (from the same IP address)
   within some amount of time (for example, 20 minutes) prior to the
   start of a message submission session has also been used, but this
   does impose restrictions on clients as well as servers which may
   cause difficulties.  Specifically, the client must do a POP
   authentication before an SMTP submission session, and not all clients
   are capable and configured for this.  Also, the MSA must coordinate
   with the POP server, which may be difficult.  There is also a window
   during which an unauthorized user can submit messages and appear to
   be a prior authorized user.




Gellens & Klensin           Standards Track                     [Page 5]

RFC 2476                   Message Submission              December 1998


3.4.  Enhanced Status Codes

   This memo suggests several enhanced status codes [SMTP-CODES] for
   submission-specific rejections.  The specific codes used are:

    5.6.0  Bad content.  The content of the header or text is
           improper.

    5.6.2  Bad domain or address.  Invalid or improper domain or address
           in MAIL FROM, RCPT TO, or DATA.

    5.7.1  Not allowed.  The address in MAIL FROM appears to have
           insufficient submission rights, or is invalid, or is not
           authorized with the authentication used; the address in a
           RCPT TO command is inconsistent with the permissions given to
           the user; the message data is rejected based on the
           submitting user.

    5.7.0  Site policy.  The message appears to violate site policy in
           some way.

4.  Mandatory Actions

   An MSA MUST do all of the following:

4.1.  General Submission Rejection Code

   Unless covered by a more precise response code, response code 554 is
   to be used to reject a MAIL FROM, RCPT TO, or DATA command that
   contains something improper.  Enhanced status code 5.6.0 is to be
   used if no other code is more specific.

4.2.  Ensure All Domains are Fully-Qualified

   The MSA MUST ensure that all domains in the envelope are fully-
   qualified.

   If the MSA examines or alters the message text in way, except to add
   trace header fields [SMTP-MTA], it MUST ensure that all domains in
   address header fields are fully-qualified.

   Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA
   command which contains improper domain references.

   NOTE:  A frequent local convention is to accept single-level domains
   (for example, 'sales') and then to expand the reference by adding the
   remaining portion of the domain name (for example, to




Gellens & Klensin           Standards Track                     [Page 6]

RFC 2476                   Message Submission              December 1998


   'sales.example.net').  Local conventions that permit single-level
   domains SHOULD reject, rather than expand, incomplete multi-level
   domains, since such expansion is particularly risky.

5.  Recommended Actions

   The MSA SHOULD do all of the following:

5.1.  Enforce Address Syntax

   An MSA SHOULD reject messages with illegal syntax in a sender or
   recipient envelope address.

   If the MSA examines or alters the message text in way, except to add
   trace header fields, it SHOULD reject messages with illegal address
   syntax in address header fields.

   Reply code 501 is to be used to reject a MAIL FROM or RCPT TO command
   that contains a detectably improper address.

   When addresses are resolved after submission of the message body,
   reply code 554 with enhanced status code 5.6.2 is to be used after
   end-of-data, if the message contains invalid addresses in the header.

5.2.  Log Errors

   The MSA SHOULD log message errors, especially apparent
   misconfigurations of client software.

   Note:  It can be very helpful to notify the administrator when
   problems are detected with local mail clients.  This is another
   advantage of distinguishing submission from relay: system
   administrators might be interested in local configuration problems,
   but not in client problems at other sites.

6.  Optional Actions

   The MSA MAY do any of the following:

6.1.  Enforce Submission Rights

   The MSA MAY issue an error response to the MAIL FROM command if the
   address in MAIL FROM appears to have insufficient submission rights,
   or is not authorized with the authentication used (if the session has
   been authenticated).

   Reply code 550 with enhanced status code 5.7.1 is used for this
   purpose.



Gellens & Klensin           Standards Track                     [Page 7]

RFC 2476                   Message Submission              December 1998


6.2.  Require Authentication

   The MSA MAY issue an error response to the MAIL FROM command if the
   session has not been authenticated.

   Section 3.3 discusses authentication mechanisms.

   Reply code 530 [SMTP-AUTH] is used for this purpose.

6.3.  Enforce Permissions

   The MSA MAY issue an error response to the RCPT TO command if
   inconsistent with the permissions given to the user (if the session
   has been authenticated).

   Reply code 550 with enhanced status code 5.7.1 is used for this
   purpose.

6.4.  Check Message Data

   The MSA MAY issue an error response to the DATA command or send a
   failure result after end-of-data if the submitted message is
   syntactically invalid, or seems inconsistent with permissions given
   to the user (if known), or violates site policy in some way.

   Reply code 554 is used for syntactic problems in the data.  Reply
   code 501 is used if the command itself is not syntactically valid.
   Reply code 550 with enhanced status code 5.7.1 is used to reject
   based on the submitting user.  Reply code 550 with enhanced status
   code 5.7.0 is used if the message violates site policy.

7.  Interaction with SMTP Extensions

   The following table lists the current standards-track and
   Experimental SMTP extensions.  Listed are the RFC, name, an
   indication as to the use of the extension on the submit port, and a
   reference:

   RFC   Name             Submission  Reference
   ----  ---------------  ----------  ------------------
   2197  Pipelining         SHOULD    [PIPELINING]
   2034  Error Codes        SHOULD    [CODES-EXTENSION]
   1985  ETRN              MUST NOT   [ETRN]
   1893  Extended Codes     SHOULD    [SMTP-CODES]
   1891  DSN                SHOULD    [DSN]
   1870  Size                MAY      [SIZE]
   1846  521               MUST NOT   [521REPLY]
   1845  Checkpoint          MAY      [Checkpoint]



Gellens & Klensin           Standards Track                     [Page 8]

RFC 2476                   Message Submission              December 1998


   1830  Binary              MAY      [CHUNKING]
   1652  8-bit MIME         SHOULD    [8BITMIME]
   ----  Authentication     ------    [SMTP-AUTH]

   Future SMTP extensions should explicitly specify if they are valid on
   the Submission port.

   Some SMTP extensions are especially useful for message submission:

   Extended Status Codes [SMTP-CODES], SHOULD be supported and used
   according to [CODES-EXTENSION].  This permits the MSA to notify the
   client of specific configuration or other problems in more detail
   than the response codes listed in this memo.  Because some rejections
   are related to a site's security policy, care should be used not to
   expose more detail than is needed to correct the problem.

   [PIPELINING] SHOULD be supported by the MSA.

   [SMTP-AUTH] allows the MSA to validate the authority and determine
   the identity of the submitting user.

   Any references to the DATA command in this memo also refer to any
   substitutes for DATA, such as the BDAT command used with [CHUNKING].

8.  Message Modifications

   Sites MAY modify submissions to ensure compliance with standards and
   site policy.  This section describes a number of such modifications
   that are often considered useful.

   NOTE:  As a matter of guidance for local decisions to implement
   message modification, a paramount rule is to limit such actions to
   remedies for specific problems that have clear solutions.  This is
   especially true with address elements.  For example, indiscriminately
   appending a domain to an address or element which lacks one typically
   results in more broken addresses.  An unqualified address must be
   verified to be a valid local part in the domain before the domain can
   be safely added.

8.1.  Add 'Sender'

   The MSA MAY add or replace the 'Sender' field, if the identity of the
   sender is known and this is not given in the 'From' field.

   The MSA MUST ensure that any address it places in a 'Sender' field is
   in fact a valid mail address.





Gellens & Klensin           Standards Track                     [Page 9]

RFC 2476                   Message Submission              December 1998


8.2.  Add 'Date'

   The MSA MAY add a 'Date' field to the submitted message, if it lacks
   it, or correct the 'Date' field if it does not conform to [MESSAGE-
   FORMAT] syntax.

8.3.  Add 'Message-ID'

   The MSA MAY add or replace the 'Message-ID' field, if it lacks it, or
   it is not valid syntax (as defined by [MESSAGE-FORMAT]).

8.4.  Transfer Encode

   The MSA MAY apply transfer encoding to the message according to MIME
   conventions, if needed and not harmful to the MIME type.

8.5.  Sign the Message

   The MSA MAY (digitally) sign or otherwise add authentication
   information to the message.

8.6.  Encrypt the Message

   The MSA MAY encrypt the message for transport to reflect
   organizational policies.

   NOTE:  To be useful, the addition of a signature and/or encryption by
   the MSA generally implies that the connection between the MUA and MSA
   must itself be secured in some other way, e.g., by operating inside
   of a secure environment, by securing the submission connection at the
   transport layer, or by using an [SMTP-AUTH] mechanism that provides
   for session integrity.

8.7.  Resolve Aliases

   The MSA MAY resolve aliases (CNAME records) for domain names, in the
   envelope and optionally in address fields of the header, subject to
   local policy.

   NOTE:  Unconditionally resolving aliases could be harmful.  For
   example, if www.example.net and ftp.example.net are both aliases for
   mail.example.net, rewriting them could lose useful information.

8.8.  Header Rewriting

   The MSA MAY rewrite local parts and/or domains, in the envelope and
   optionally in address fields of the header, according to local
   policy.  For example, a site may prefer to rewrite 'JRU' as '



Gellens & Klensin           Standards Track                    [Page 10]

RFC 2476                   Message Submission              December 1998


   J.Random.User' in order to hide logon names, and/or to rewrite '
   squeeky.sales.example.net' as 'zyx.example.net' to hide machine names
   and make it easier to move users.

   However, only addresses, local-parts, or domains which match specific
   local MSA configuration settings should be altered.  It would be very
   dangerous for the MSA to apply data-independent rewriting rules, such
   as always deleting the first element of a domain name.  So, for
   example, a rule which strips the left-most element of the domain if
   the complete domain matches '*.foo.example.net' would be acceptable.

9.  Security Considerations

   Separation of submission and relay of messages can allow a site to
   implement different policies for the two types of services, including
   requiring use of additional security mechanisms for one or both.  It
   can do this in a way which is simpler, both technically and
   administratively.  This increases the likelihood that policies will
   be applied correctly.

   Separation also can aid in tracking and preventing unsolicited bulk
   email.

   For example, a site could configure its MSA to require authentication
   before accepting a message, and could configure its MTA to reject all
   RCPT TOs for non-local users.  This can be an important element in a
   site's total email security policy.

   If a site fails to require any form of authorization for message
   submissions (see section 3.3 for discussion), it is allowing open use
   of its resources and name; unsolicited bulk email can be injected
   using its facilities.

10.  Acknowledgments

   This updated memo has been revised in part based on comments and
   discussions which took place on and off the IETF-Submit mailing list.
   The help of those who took the time to review the draft and make
   suggestions is appreciated, especially that of Dave Crocker, Ned
   Freed, Keith Moore, John Myers, and Chris Newman.

   Special thanks to Harald Alvestrand, who got this effort started.









Gellens & Klensin           Standards Track                    [Page 11]

RFC 2476                   Message Submission              December 1998


11.  References

   [521REPLY]        Durand, A. and F. Dupont, "SMTP 521 Reply Code",
                     RFC 1846, September 1995.

   [8BITMIME]        Klensin, J., Freed, N., Rose, M., Stefferud, E. and
                     D.  Crocker, "SMTP Service Extension for 8bit-
                     MIMEtransport", RFC 1652, July 1994.

   [ABNF]            Crocker, D., Ed. and P. Overell, "Augmented BNF for
                     Syntax Specifications: ABNF", RFC 2234, November
                     1997.

   [CHECKPOINT]      Crocker, D., Freed, N. and A. Cargille, "SMTP
                     Service Extension for Checkpoint/Restart", RFC
                     1845, September 1995.

   [CHUNKING]        Vaudreuil, G., "SMTP Service Extensions for
                     Transmission of Large and Binary MIME Messages",
                     RFC 1830, August 1995.

   [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
                     Enhanced Error Codes", RFC 2034, October 1996.

   [DSN]             Moore, K., "SMTP Service Extension for Delivery
                     Status Notifications", RFC 1891, January 1996.

   [ESMTP]           Klensin, J., Freed, N., Rose, M., Stefferud, E. and
                     D. Crocker, "SMTP Service Extensions", STD 10, RFC
                     1869, November 1995.

   [ETRN]            De Winter, J., "SMTP Service Extension for Remote
                     Message Queue Starting", RFC 1985, August 1996.

   [HEADERS]         Palme, J., "Common Internet Message Headers", RFC
                     2076, February 1997.

   [IPSEC]           Atkinson, R., "Security Architecture for the
                     Internet Protocol", RFC 1825, August 1995.

   [KEYWORDS]        Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.









Gellens & Klensin           Standards Track                    [Page 12]

RFC 2476                   Message Submission              December 1998


   [MESSAGE-FORMAT]  Crocker, D., "Standard for the format of ARPA
                     Internet text messages", STD 11, RFC 822, August
                     1982;

                     Braden, R., Editor, "Requirements for Internet
                     Hosts -- Application and Support", STD 3, RFC 1123,
                     October 1989.

   [PIPELINING]      Freed, N., "SMTP Service Extension for Command
                     Pipelining", RFC 2197, September 1997.

   [POP3]            Myers, J. and M. Rose, "Post Office Protocol --
                     Version 3", STD 53, RFC 1939, May 1996.

   [SIZE]            Klensin, J., Freed, N. and K. Moore, "SMTP Service
                     Extension for Message Size Declaration", STD 10,
                     RFC 1870, November 1995.

   [SMTP-AUTH]       Myers, J., "SMTP Service Extension for
                     Authentication", Work in Progress.

   [SMTP-CODES]      Vaudreuil, G., "Enhanced Mail System Status Codes",
                     RFC 1893, January 1996.

   [SMTP-MTA]        Postel, J., "Simple Mail Transfer Protocol", STD
                     10, RFC 821, August 1982.

                     Partridge, C., "Mail Routing and the Domain
                     System", STD 14, RFC 974, January 1986.

                     Braden, R., Editor, "Requirements for Internet
                     Hosts -- Application and Support", STD 3, RFC 1123,
                     October 1989.


















Gellens & Klensin           Standards Track                    [Page 13]

RFC 2476                   Message Submission              December 1998


12.  Authors' Addresses

   Randall Gellens
   QUALCOMM Incorporated
   6455 Lusk Blvd.
   San Diego, CA  92121-2779
   U.S.A.

   Phone: +1 619 651 5115
   Fax:   +1 619 651 5334
   EMail: Randy@Qualcomm.Com


   John C. Klensin
   MCI Telecommunications
   800 Boylston St, 7th floor
   Boston, MA 02199
   USA

   Phone: +1 617 960 1011
   EMail: klensin@mci.net






























Gellens & Klensin           Standards Track                    [Page 14]

RFC 2476                   Message Submission              December 1998


13.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Gellens & Klensin           Standards Track                    [Page 15]