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
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
|
<pre>Network Working Group R. Gellens
Request for Comments: 4409 QUALCOMM
Obsoletes: <a href="./rfc2476">2476</a> J. Klensin
Category: Standards Track April 2006
<span class="h1">Message Submission for Mail</span>
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 (2006).
Abstract
This memo splits message submission from message relay, allowing each
service to operate according to its own rules (for security, policy,
etc.), and specifies what actions are to be taken by a submission
server.
Message relay and final delivery are unaffected, and continue to use
SMTP over port 25.
When conforming to this document, message submission uses the
protocol specified here, normally over port 587.
This separation of function offers a number of benefits, including
the ability to apply specific security or policy requirements.
<span class="grey">Gellens & Klensin Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Document Information ............................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Definitions of Terms Used in This Memo .....................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Conventions Used in This Document ..........................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Message Submission ..............................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Submission Identification ..................................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Message Rejection and Bouncing .............................<a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Authorized Submission ......................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Mandatory Actions ...............................................<a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. General Submission Rejection Code ..........................<a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. Ensure All Domains Are Fully-Qualified .....................<a href="#page-7">7</a>
<a href="#section-4.3">4.3</a>. Require Authentication .....................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Recommended Actions .............................................<a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. Enforce Address Syntax .....................................<a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. Log Errors .................................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Optional Actions ................................................<a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. Enforce Submission Rights ..................................<a href="#page-9">9</a>
<a href="#section-6.2">6.2</a>. Enforce Permissions ........................................<a href="#page-9">9</a>
<a href="#section-6.3">6.3</a>. Check Message Data .........................................<a href="#page-9">9</a>
<a href="#section-6.4">6.4</a>. Support for the Postmaster Address .........................<a href="#page-9">9</a>
<a href="#section-7">7</a>. Interaction with SMTP Extensions ...............................<a href="#page-10">10</a>
<a href="#section-8">8</a>. Message Modifications ..........................................<a href="#page-11">11</a>
<a href="#section-8.1">8.1</a>. Add 'Sender' ..............................................<a href="#page-11">11</a>
<a href="#section-8.2">8.2</a>. Add 'Date' ................................................<a href="#page-11">11</a>
<a href="#section-8.3">8.3</a>. Add 'Message-ID' ..........................................<a href="#page-11">11</a>
<a href="#section-8.4">8.4</a>. Transfer Encode ...........................................<a href="#page-11">11</a>
<a href="#section-8.5">8.5</a>. Sign the Message ..........................................<a href="#page-11">11</a>
<a href="#section-8.6">8.6</a>. Encrypt the Message .......................................<a href="#page-12">12</a>
<a href="#section-8.7">8.7</a>. Resolve Aliases ...........................................<a href="#page-12">12</a>
<a href="#section-8.8">8.8</a>. Header Rewriting ..........................................<a href="#page-12">12</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-10">10</a>. IANA Considerations ...........................................<a href="#page-13">13</a>
<a href="#section-11">11</a>. Acknowledgements ..............................................<a href="#page-13">13</a>
<a href="#section-12">12</a>. Normative References ..........................................<a href="#page-14">14</a>
<a href="#section-13">13</a>. Informative References ........................................<a href="#page-14">14</a>
<span class="grey">Gellens & Klensin Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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 [<a href="#ref-SMTP-MTA" title=""Simple Mail Transfer Protocol"">SMTP-MTA</a>].
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
that accepts message submissions from MUAs is termed a Message
Submission Agent (MSA).
In order to permit unconstrained communications, SMTP is not often
authenticated during message relay.
Authentication and authorization of initial submissions have become
increasingly important, driven by changes in security requirements
and rising expectations that submission servers take responsibility
for the message traffic they originate.
For example, due to the prevalence of machines that have worms,
viruses, or other malicious software that generate large amounts of
spam, many sites now prohibit outbound traffic on the standard SMTP
port (port 25), funneling all mail submissions through submission
servers.
In addition to authentication and authorization issues, messages
being submitted are in some cases finished (complete) messages, and
in other cases are unfinished (incomplete) in one or more aspects.
Unfinished messages may need to be completed to ensure they conform
to [<a href="#ref-MESSAGE-FORMAT" title=""Standard for the format of ARPA Internet text messages"">MESSAGE-FORMAT</a>], 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 (e.g., 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, e.g., to
conceal local name or address spaces. 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 do the following:
<span class="grey">Gellens & Klensin Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
* 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
* 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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Document Information</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Definitions of Terms Used in This Memo</span>
Many of the concepts and terms used in this document are defined in
[<a href="#ref-SMTP-MTA" title=""Simple Mail Transfer Protocol"">SMTP-MTA</a>]; familiarity with those documents is assumed here.
Fully-Qualified
Containing or consisting of a domain that can be globally resolved
using the Domain Name Service; that is, not a local alias or partial
specification.
Message Submission Agent (MSA)
A process that conforms to this specification. An MSA 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 that conforms to [<a href="#ref-SMTP-MTA" title=""Simple Mail Transfer Protocol"">SMTP-MTA</a>]. An MTA 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.
<span class="grey">Gellens & Klensin Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
Message User Agent (MUA)
A process that acts (often on behalf of a user and with a user
interface) to compose and submit new messages, and process delivered
messages.
For delivered messages, the receiving MUA may obtain and process the
message according to local conventions or, in what is commonly
referred to as a split-MUA model, Post Office Protocol [<a href="#ref-POP3" title=""Post Office Protocol - Version 3"">POP3</a>] or IMAP
[<a href="#ref-IMAP4" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP4</a>] is used to access delivered messages, whereas the protocol
defined here (or SMTP) is used to submit messages.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Conventions Used in This Document</span>
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 [<a href="#ref-KEYWORDS" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEYWORDS</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Message Submission</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Submission Identification</span>
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 [<a href="#ref-SMTP-MTA" title=""Simple Mail Transfer Protocol"">SMTP-MTA</a>, <a href="#ref-ESMTP" title=""SMTP Service Extensions"">ESMTP</a>], with
additional restrictions or allowances as specified here.
Although 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.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Message Rejection and Bouncing</span>
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 MTAs to reject all RCPT
commands for messages that do not reference local users, and
configure their MSA to reject all message submissions that do not
come from authorized users, with authorization based either on
authenticated identity or the submitting endpoint being within a
protected IP environment.
<span class="grey">Gellens & Klensin Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
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 command.
Note that a null return path, that is, MAIL FROM:<>, is permitted and
MUST NOT in itself be cause for rejecting a message. (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 that 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
needs to maintain a queue of messages it has submitted, and match
bounces to them. Note that many contemporary MUAs do not have this
capability.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Authorized Submission</span>
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 other tunnels, and prior
POP authentication.
Authenticated SMTP [<a href="#ref-SMTP-AUTH" title=""SMTP Service Extension for Authentication"">SMTP-AUTH</a>] has seen widespread deployment. It
allows the MSA to determine an authorization identity for the message
submission, one that is not tied to other protocols.
IP address restrictions are very widely implemented, but do not allow
for travelers and similar situations, and can be easily spoofed
unless all transport paths between the MUA and MSA are trustworthy.
<span class="grey">Gellens & Klensin Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
Secure IP [<a href="#ref-IPSEC" title=""Security Architecture for the Internet Protocol"">IPSEC</a>], and other encrypted and authenticated tunneling
techniques, can also be used and provide additional benefits of
protection against eavesdropping and traffic analysis.
Requiring a POP [<a href="#ref-POP3" title=""Post Office Protocol - Version 3"">POP3</a>] authentication (from the same IP address)
within some amount of time (e.g., 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
previously authorized user. Since it is dependent on the MUA's IP
addresses, this technique is substantially as subject to IP address
spoofing as validation based on known IP addresses alone (see above).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Mandatory Actions</span>
An MSA MUST do all of the following:
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. General Submission Rejection Code</span>
Unless covered by a more precise response code, response code 554 is
to be used to reject a MAIL, RCPT, or DATA command that contains
something improper.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Ensure All Domains Are Fully-Qualified</span>
The MSA MUST ensure that all domains in the SMTP envelope are fully-
qualified.
If the MSA examines or alters the message text in any way, except to
add trace header fields [<a href="#ref-SMTP-MTA" title=""Simple Mail Transfer Protocol"">SMTP-MTA</a>], it MUST ensure that all domains
in address header fields are fully-qualified.
Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command
that contains improper domain references.
A frequent local convention is to accept single-level domains (e.g.,
'sales') and then to expand the reference by adding the remaining
portion of the domain name (e.g., to 'sales.example.net'). Local
conventions that permit single-level domains SHOULD reject, rather
than expand, incomplete multi-level domains (e.g., 'squeaky.sales'),
since such expansion is particularly risky.
<span class="grey">Gellens & Klensin Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Require Authentication</span>
The MSA MUST by default issue an error response to the MAIL command
if the session has not been authenticated using [<a href="#ref-SMTP-AUTH" title=""SMTP Service Extension for Authentication"">SMTP-AUTH</a>], unless
it has already independently established authentication or
authorization (such as being within a protected subnetwork).
<a href="#section-3.3">Section 3.3</a> discusses authentication mechanisms.
Reply code 530 [<a href="#ref-SMTP-AUTH" title=""SMTP Service Extension for Authentication"">SMTP-AUTH</a>] is used for this purpose.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Recommended Actions</span>
The MSA SHOULD do all of the following:
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Enforce Address Syntax</span>
An MSA SHOULD reject messages with illegal syntax in a sender or
recipient SMTP 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 or RCPT command that
contains a detectably improper address.
When addresses are resolved after submission of the message body,
reply code 554 (with a suitable enhanced status code from
[<a href="#ref-SMTP-CODES" title=""Enhanced Mail System Status Codes"">SMTP-CODES</a>]) is used after end-of-data, if the message contains
invalid addresses in the header.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Log Errors</span>
The MSA SHOULD log message errors, especially apparent
misconfigurations of client software.
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.
Note that it is important to impose limits on such logging to prevent
certain forms of denial of service (DoS) attacks.
<span class="grey">Gellens & Klensin Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Optional Actions</span>
The MSA MAY do any of the following:
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Enforce Submission Rights</span>
The MSA MAY issue an error response to a MAIL 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 an appropriate enhanced status code per
[<a href="#ref-SMTP-CODES" title=""Enhanced Mail System Status Codes"">SMTP-CODES</a>], such as 5.7.1, is used for this purpose.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Enforce Permissions</span>
The MSA MAY issue an error response to a RCPT command if inconsistent
with the permissions given to the user (if the session has been
authenticated).
Reply code 550 with an appropriate enhanced status code per
[<a href="#ref-SMTP-CODES" title=""Enhanced Mail System Status Codes"">SMTP-CODES</a>], such as 5.7.1, is used for this purpose.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Check Message Data</span>
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 an appropriate enhanced status code per
[<a href="#ref-SMTP-CODES" title=""Enhanced Mail System Status Codes"">SMTP-CODES</a>] (such as 5.7.1) is used to reject based on the
submitting user. Reply code 550 with an appropriate enhanced status
code (such as 5.7.0) is used if the message violates site policy.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Support for the Postmaster Address</span>
If appropriate under local conditions and to facilitate conformance
with the "postmaster" requirements of [<a href="#ref-SMTP-MTA" title=""Simple Mail Transfer Protocol"">SMTP-MTA</a>], the MSA MAY permit
a reduced degree of authentication for mail addressed to the
"postmaster" (or one of its alternate spelling forms, see
[<a href="#ref-SMTP-MTA" title=""Simple Mail Transfer Protocol"">SMTP-MTA</a>]), in one or more domains, as compared to requirements
enforced for other addresses. Among other benefits, this provides an
address of last resort that can be used by authorized users to report
problems that otherwise prevent them from submitting mail.
<span class="grey">Gellens & Klensin Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Interaction with SMTP Extensions</span>
The following table lists the current standards-track and
Experimental SMTP extensions. Listed are the EHLO keyword, name, an
indication as to the use of the extension on the submit port, and a
reference:
Keyword Name Submission Reference
---------- -------------------------- ---------- ----------------
PIPELINING Pipelining SHOULD [<a href="#ref-PIPELINING" title=""SMTP Service Extension for Command Pipelining"">PIPELINING</a>]
ENHANCEDSTATUSCODES Enhanced Status Codes SHOULD [<a href="#ref-CODES-EXTENSION" title=""SMTP Service Extension for Returning Enhanced Error Codes"">CODES-EXTENSION</a>]
ETRN Extended Turn MUST NOT [<a href="#ref-ETRN" title=""SMTP Service Extension for Remote Message Queue Starting"">ETRN</a>]
... Extended Codes SHOULD [<a href="#ref-SMTP-CODES" title=""Enhanced Mail System Status Codes"">SMTP-CODES</a>]
DSN Delivery Status Notification SHOULD [<a href="#ref-DSN" title=""Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)"">DSN</a>]
SIZE Message size MAY [<a href="#ref-SIZE" title=""SMTP Service Extension for Message Size Declaration"">SIZE</a>]
... 521 reply code MUST NOT [<a href="#ref-521REPLY" title=""SMTP 521 Reply Code"">521REPLY</a>]
CHECKPOINT Checkpoint/Restart MAY [<a href="#ref-CHECKPOINT" title=""SMTP Service Extension for Checkpoint/Restart"">CHECKPOINT</a>]
BINARYMIME Binary MIME MAY [<a href="#ref-CHUNKING" title=""SMTP Service Extensions for Transmission of Large and Binary MIME Messages"">CHUNKING</a>]
CHUNKING Chunking MAY [<a href="#ref-CHUNKING" title=""SMTP Service Extensions for Transmission of Large and Binary MIME Messages"">CHUNKING</a>]
8BITMIME Use 8-bit data SHOULD [<a href="#ref-8BITMIME" title=""SMTP Service Extension for 8bit- MIMEtransport"">8BITMIME</a>]
AUTH Authentication MUST [<a href="#ref-SMTP-AUTH" title=""SMTP Service Extension for Authentication"">SMTP-AUTH</a>]
STARTTLS Start TLS MAY [<a href="#ref-Start-TLS" title=""SMTP Service Extension for Secure SMTP over Transport Layer Security"">Start-TLS</a>]
NO-SOLICITING Notification of no soliciting MAY [<a href="#ref-Msg-Track" title=""SMTP Service Extension for Message Tracking"">Msg-Track</a>]
MTRK Message Tracking MAY [<a href="#ref-Msg-Track" title=""SMTP Service Extension for Message Tracking"">Msg-Track</a>]
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 [<a href="#ref-SMTP-CODES" title=""Enhanced Mail System Status Codes"">SMTP-CODES</a>] SHOULD be supported and used
according to [<a href="#ref-CODES-EXTENSION" title=""SMTP Service Extension for Returning Enhanced Error Codes"">CODES-EXTENSION</a>]. 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 to unauthenticated senders than is needed
[<a id="ref-PIPELINING">PIPELINING</a>] SHOULD be supported by the MSA.
[<a id="ref-SMTP-AUTH">SMTP-AUTH</a>] allows the MSA to validate the authority and determine
the identity of the submitting user and MUST be supported by the MSA.
Any references to the DATA command in this memo also refer to any
substitutes for DATA, such as the BDAT command used with [<a href="#ref-CHUNKING" title=""SMTP Service Extensions for Transmission of Large and Binary MIME Messages"">CHUNKING</a>].
<span class="grey">Gellens & Klensin Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Message Modifications</span>
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 that 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.
Any message forwarded or delivered by the MSA MUST conform to the
requirements of [<a href="#ref-SMTP-MTA" title=""Simple Mail Transfer Protocol"">SMTP-MTA</a>] and [<a href="#ref-MESSAGE-FORMAT" title=""Standard for the format of ARPA Internet text messages"">MESSAGE-FORMAT</a>].
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Add 'Sender'</span>
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.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Add 'Date'</span>
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
[<a href="#ref-MESSAGE-FORMAT" title=""Standard for the format of ARPA Internet text messages"">MESSAGE-FORMAT</a>] syntax.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Add 'Message-ID'</span>
The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it,
or it is not valid syntax (as defined by [<a href="#ref-MESSAGE-FORMAT" title=""Standard for the format of ARPA Internet text messages"">MESSAGE-FORMAT</a>]). Note
that a number of clients still do not generate Message-ID fields.
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. Transfer Encode</span>
The MSA MAY apply transfer encoding to the message according to MIME
conventions, if needed and not harmful to the MIME type.
<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>. Sign the Message</span>
The MSA MAY (digitally) sign or otherwise add authentication
information to the message.
<span class="grey">Gellens & Klensin Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>. Encrypt the Message</span>
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, for example, by operating
inside of a secure environment, by securing the submission connection
at the transport layer, or by using an [<a href="#ref-SMTP-AUTH" title=""SMTP Service Extension for Authentication"">SMTP-AUTH</a>] mechanism that
provides for session integrity.
<span class="h3"><a class="selflink" id="section-8.7" href="#section-8.7">8.7</a>. Resolve Aliases</span>
The MSA MAY resolve aliases (CNAME records) for domain names, in the
SMTP 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.
<span class="h3"><a class="selflink" id="section-8.8" href="#section-8.8">8.8</a>. Header Rewriting</span>
The MSA MAY rewrite local parts and/or domains in the SMTP envelope,
and optionally in address fields of the header, according to local
policy. For example, a site may prefer to rewrite 'JRU' as
'J.Random.User' in order to hide login names, and/or to rewrite
'squeaky.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 that strips the left-most element of the domain, if
the complete domain matches '*.foo.example.net', would be acceptable.
The MSA MUST NOT rewrite a forward-pointing (destination) address in
a way that violates the constraints of [<a href="#ref-SMTP-MTA" title=""Simple Mail Transfer Protocol"">SMTP-MTA</a>] on modifications of
local-parts.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
Separation of submission and relay of messages allows 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
<span class="grey">Gellens & Klensin Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
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 mail servers such that the
MSA requires authentication before accepting a message, and the MTA
rejects all RCPT commands 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 <a href="#section-3.3">section 3.3</a> for discussion), it is allowing open use
of its resources and name; unsolicited bulk email can be injected
using its facilities.
<a href="#section-3">Section 3</a> includes further discussion of issues with some
authentication methods.
<a href="#section-5.2">Section 5.2</a> includes a cautionary note that unlimited logging can
enable certain forms of denial of service attacks.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
The registration for port 587 has been updated to refer to this memo
rather than <a href="./rfc2476">RFC 2476</a>.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgements</span>
Nathaniel Borenstein and Barry Leiba were instrumental in the
development of this update to <a href="./rfc2476">RFC 2476</a>.
The original memo (<a href="./rfc2476">RFC 2476</a>) was developed 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 that document
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.
<span class="grey">Gellens & Klensin Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Normative References</span>
[<a id="ref-ESMTP">ESMTP</a>] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
and D. Crocker, "SMTP Service Extensions", STD 10,
<a href="./rfc1869">RFC 1869</a>, November 1995.
[<a id="ref-KEYWORDS">KEYWORDS</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-SMTP-MTA">SMTP-MTA</a>] Postel, J., "Simple Mail Transfer Protocol", STD
10, <a href="./rfc821">RFC 821</a>, August 1982.
Partridge, C., "Mail routing and the domain
system", STD 10, <a href="./rfc974">RFC 974</a>, January 1986.
Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, <a href="./rfc1123">RFC 1123</a>, October
1989.
Klensin, J., "Simple Mail Transfer Protocol", <a href="./rfc2821">RFC</a>
<a href="./rfc2821">2821</a>, April 2001.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Informative References</span>
[<a id="ref-521REPLY">521REPLY</a>] Durand, A. and F. Dupont, "SMTP 521 Reply Code",
<a href="./rfc1846">RFC 1846</a>, September 1995.
[<a id="ref-8BITMIME">8BITMIME</a>] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
and D. Crocker, "SMTP Service Extension for 8bit-
MIMEtransport", <a href="./rfc1652">RFC 1652</a>, July 1994.
[<a id="ref-CHECKPOINT">CHECKPOINT</a>] Crocker, D., Freed, N., and A. Cargille, "SMTP
Service Extension for Checkpoint/Restart", <a href="./rfc1845">RFC</a>
<a href="./rfc1845">1845</a>, September 1995.
[<a id="ref-CHUNKING">CHUNKING</a>] Vaudreuil, G., "SMTP Service Extensions for
Transmission of Large and Binary MIME Messages",
<a href="./rfc3030">RFC 3030</a>, December 2000.
[<a id="ref-CODES-EXTENSION">CODES-EXTENSION</a>] Freed, N., "SMTP Service Extension for Returning
Enhanced Error Codes", <a href="./rfc2034">RFC 2034</a>, October 1996.
[<a id="ref-DSN">DSN</a>] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)", <a href="./rfc3461">RFC 3461</a>, January 2003.
[<a id="ref-ETRN">ETRN</a>] De Winter, J., "SMTP Service Extension for Remote
Message Queue Starting", <a href="./rfc1985">RFC 1985</a>, August 1996.
<span class="grey">Gellens & Klensin Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
[<a id="ref-IMAP4">IMAP4</a>] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", <a href="./rfc3501">RFC 3501</a>, March 2003.
[<a id="ref-IPSEC">IPSEC</a>] Kent, S. and R. Atkinson, "Security Architecture
for the Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November
1998.
[<a id="ref-MESSAGE-FORMAT">MESSAGE-FORMAT</a>] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, <a href="./rfc822">RFC 822</a>, August
1982.
Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, <a href="./rfc1123">RFC 1123</a>, October
1989.
Resnick, P., "Internet Message Format", <a href="./rfc2822">RFC 2822</a>,
April 2001.
[<a id="ref-Msg-Track">Msg-Track</a>] Allman, E. and T. Hansen, "SMTP Service Extension
for Message Tracking", <a href="./rfc3885">RFC 3885</a>, September 2004.
[<a id="ref-PIPELINING">PIPELINING</a>] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, <a href="./rfc2920">RFC 2920</a>, September 2000.
[<a id="ref-POP3">POP3</a>] Myers, J. and M. Rose, "Post Office Protocol -
Version 3", STD 53, <a href="./rfc1939">RFC 1939</a>, May 1996.
[<a id="ref-SIZE">SIZE</a>] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10,
<a href="./rfc1870">RFC 1870</a>, November 1995.
[<a id="ref-SMTP-AUTH">SMTP-AUTH</a>] Myers, J., "SMTP Service Extension for
Authentication", <a href="./rfc2554">RFC 2554</a>, March 1999.
[<a id="ref-SMTP-CODES">SMTP-CODES</a>] Vaudreuil, G., "Enhanced Mail System Status Codes",
<a href="./rfc3463">RFC 3463</a>, January 2003.
[<a id="ref-Start-TLS">Start-TLS</a>] Hoffman, P., "SMTP Service Extension for Secure
SMTP over Transport Layer Security", <a href="./rfc3207">RFC 3207</a>,
February 2002.
<span class="grey">Gellens & Klensin Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
Authors' Addresses
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121-2779
USA
EMail: rg+ietf@qualcomm.com
John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
EMail: john+ietf@jck.com
<span class="grey">Gellens & Klensin Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4409">RFC 4409</a> Message Submission for Mail April 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Gellens & Klensin Standards Track [Page 17]
</pre>
|
