1
2
3
4
5
6
7Internet Engineering Task Force (IETF) R. Gellens
8Request for Comments: 6409 QUALCOMM Incorporated
9STD: 72 J. Klensin
10Obsoletes: 4409 November 2011
11Category: Standards Track
12ISSN: 2070-1721
13
14
15 Message Submission for Mail
16
17Abstract
18
19 This memo splits message submission from message relay, allowing each ../smtpserver/server.go:301
20 service to operate according to its own rules (for security, policy,
21 etc.), and specifies what actions are to be taken by a submission
22 server.
23
24 Message relay is unaffected, and continues to use SMTP over port 25.
25
26 When conforming to this document, message submission uses the
27 protocol specified here, normally over port 587.
28
29 This separation of function offers a number of benefits, including
30 the ability to apply specific security or policy requirements.
31
32Status of This Memo
33
34 This is an Internet Standards Track document.
35
36 This document is a product of the Internet Engineering Task Force
37 (IETF). It represents the consensus of the IETF community. It has
38 received public review and has been approved for publication by the
39 Internet Engineering Steering Group (IESG). Further information on
40 Internet Standards is available in Section 2 of RFC 5741.
41
42 Information about the current status of this document, any errata,
43 and how to provide feedback on it may be obtained at
44 http://www.rfc-editor.org/info/rfc6409.
45
46
47
48
49
50
51
52
53
54
55
56
57
58Gellens & Klensin Standards Track [Page 1]
59
60RFC 6409 Message Submission for Mail November 2011
61
62
63Copyright Notice
64
65 Copyright (c) 2011 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
67
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
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
114Gellens & Klensin Standards Track [Page 2]
115
116RFC 6409 Message Submission for Mail November 2011
117
118
119Table of Contents
120
121 1. Introduction ....................................................4
122 2. Document Information ............................................5
123 2.1. Definitions of Terms Used in This Memo .....................5
124 2.2. Conventions Used in This Document ..........................6
125 3. Message Submission ..............................................6
126 3.1. Submission Identification ..................................6
127 3.2. Message Rejection and Bouncing .............................6
128 3.3. Authorized Submission ......................................7
129 4. Mandatory Actions ...............................................8
130 4.1. General Submission Rejection Code ..........................8
131 4.2. Ensure All Domains Are Fully Qualified .....................8
132 4.3. Require Authentication .....................................8
133 5. Recommended Actions .............................................9
134 5.1. Enforce Address Syntax .....................................9
135 5.2. Log Errors .................................................9
136 5.3. Apply Shorter Timeouts .....................................9
137 6. Optional Actions ...............................................10
138 6.1. Enforce Submission Rights .................................10
139 6.2. Enforce Permissions .......................................10
140 6.3. Check Message Data ........................................10
141 6.4. Support for the Postmaster Address ........................10
142 6.5. Adjust Character Encodings ................................11
143 7. Interaction with SMTP Extensions ...............................12
144 8. Message Modifications ..........................................13
145 8.1. Add 'Sender' ..............................................14
146 8.2. Add 'Date' ................................................14
147 8.3. Add 'Message-ID' ..........................................14
148 8.4. Transfer Encode ...........................................14
149 8.5. Sign the Message ..........................................14
150 8.6. Encrypt the Message .......................................14
151 8.7. Resolve Aliases ...........................................15
152 8.8. Header Rewriting ..........................................15
153 9. Security Considerations ........................................15
154 10. IANA Considerations ...........................................16
155 11. Acknowledgments ...............................................16
156 12. References ....................................................17
157 12.1. Normative References .....................................17
158 12.2. Informative References ...................................17
159 Appendix A. Major Changes from RFC 4409 ...........................20
160
161
162
163
164
165
166
167
168
169
170Gellens & Klensin Standards Track [Page 3]
171
172RFC 6409 Message Submission for Mail November 2011
173
174
1751. Introduction
176
177 SMTP [SMTP-MTA] was defined as a message *transfer* protocol, that
178 is, a means to route (if needed) and deliver finished (complete)
179 messages.
180
181 Message Transfer Agents (MTAs) are not supposed to alter the message
182 text, except to add 'Received', 'Return-Path', and other header
183 fields as required by [SMTP-MTA]. However, SMTP is now also widely
184 used as a message *submission* protocol, that is, a means for Message
185 User Agents (MUAs) to introduce new messages into the MTA routing
186 network. The process that accepts message submissions from MUAs is
187 termed a "Message Submission Agent" (MSA).
188
189 In order to permit unconstrained communications, SMTP is not often
190 authenticated during message relay.
191
192 Authentication and authorization of initial submissions have become
193 increasingly important, driven by changes in security requirements
194 and rising expectations that submission servers take responsibility
195 for the message traffic they originate.
196
197 For example, due to the prevalence of machines that have worms,
198 viruses, or other malicious software that generate large amounts of
199 spam, many sites now prohibit outbound traffic on the standard SMTP
200 port (port 25), funneling all mail submissions through submission
201 servers.
202
203 In addition to authentication and authorization issues, messages
204 being submitted are, in some cases, finished (complete) messages and,
205 in other cases, are unfinished (incomplete) in one or more aspects.
206 Unfinished messages may need to be completed to ensure they conform
207 to the Message Format specification [MESSAGE-FORMAT] and related
208 requirements. For example, the message may lack a proper 'Date'
209 header field, and domains might not be fully qualified. In some
210 cases, the MUA may be unable to generate finished messages (e.g., it
211 might not know its time zone). Even when submitted messages are
212 complete, local site policy may dictate that the message text be
213 examined or modified in some way, e.g., to conceal local name or
214 address spaces. Such completions or modifications have been shown to
215 cause harm when performed by downstream MTAs -- that is, MTAs after
216 the first-hop submission MTA -- and are, in general, considered to be
217 outside the province of standardized MTA functionality.
218
219
220
221
222
223
224
225
226Gellens & Klensin Standards Track [Page 4]
227
228RFC 6409 Message Submission for Mail November 2011
229
230
231 Separating messages into submissions and transfers allows developers
232 and network administrators to do the following more easily:
233
234 o Implement security policies and guard against unauthorized mail
235 relaying or injection of unsolicited bulk mail.
236
237 o Implement authenticated submission, including off-site submission
238 by authorized users such as travelers.
239
240 o Separate the relevant software code differences, thereby making
241 each code base more straightforward and allowing for different
242 programs for relay and submission.
243
244 o Detect configuration problems with a site's mail clients.
245
246 o Provide a basis for adding enhanced submission services.
247
248 This memo describes a low-cost, deterministic means for messages to
249 be identified as submissions, and it specifies what actions are to be
250 taken by a submission server.
251
2522. Document Information
253
2542.1. Definitions of Terms Used in This Memo
255
256 Many of the concepts and terms used in this document are defined in
257 [SMTP-MTA]; familiarity with those documents is assumed here.
258
259 Fully Qualified
260
261 Containing or consisting of a domain that can be globally resolved
262 using the Domain Name Service, that is, not a local alias or partial
263 specification.
264
265 Message Submission Agent (MSA)
266
267 A process that conforms to this specification. An MSA acts as a
268 submission server to accept messages from MUAs, and it either
269 delivers them or acts as an SMTP client to relay them to an MTA.
270
271 Message Transfer Agent (MTA)
272
273 A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server
274 to accept messages from an MSA or another MTA, and it either delivers
275 them or acts as an SMTP client to relay them to another MTA.
276
277
278
279
280
281
282Gellens & Klensin Standards Track [Page 5]
283
284RFC 6409 Message Submission for Mail November 2011
285
286
287 Message User Agent (MUA)
288
289 A process that acts (often on behalf of a user and with a user
290 interface) to compose and submit new messages, and to process
291 delivered messages.
292
293 For delivered messages, the receiving MUA may obtain and process the
294 message according to local conventions or, in what is commonly
295 referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP
296 [IMAP4] is used to access delivered messages, whereas the protocol
297 defined here (or SMTP) is used to submit messages.
298
2992.2. Conventions Used in This Document
300
301 Examples use the 'example.net' domain.
302
303 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
304 in this document are to be interpreted as defined in [KEYWORDS].
305
3063. Message Submission
307
3083.1. Submission Identification
309
310 Port 587 is reserved for email message submission as specified in
311 this document. Messages received on this port are defined to be
312 submissions. The protocol used is ESMTP [SMTP-MTA], with additional
313 restrictions or allowances as specified here.
314
315 Although most email clients and servers can be configured to use port
316 587 instead of 25, there are cases where this is not possible or
317 convenient. A site MAY choose to use port 25 for message submission
318 by designating some hosts to be MSAs and others to be MTAs.
319
3203.2. Message Rejection and Bouncing
321
322 MTAs and MSAs MAY implement message rejection rules that rely, in
323 part, on whether the message is a submission or a relay.
324
325 For example, some sites might configure their MTAs to reject all RCPT
326 commands for messages that do not reference local users, and they
327 might configure their MSA to reject all message submissions that do
328 not come from authorized users, with authorization based on either
329 the authenticated identity or the submitting endpoint being within a
330 protected IP environment.
331
332 NOTE: It is better to reject a message than to risk sending one that
333 is damaged. This is especially true for problems that are
334 correctable by the MUA, for example, an invalid 'From' field.
335
336
337
338Gellens & Klensin Standards Track [Page 6]
339
340RFC 6409 Message Submission for Mail November 2011
341
342
343 If an MSA is not able to determine a return path to the submitting
344 user, from a valid MAIL FROM, a valid source IP address, or based on
345 authenticated identity, then the MSA SHOULD immediately reject the
346 message. A message can be immediately rejected by returning a 550
347 code to the MAIL command.
348
349 Note that a null return path, that is, MAIL FROM:<>, is permitted and ../smtpserver/server.go:1497
350 MUST NOT, in itself, be cause for rejecting a message. (MUAs need to
351 generate null return-path messages for a variety of reasons,
352 including disposition notifications.)
353
354 Except in the case where the MSA is unable to determine a valid
355 return path for the message being submitted, text in this
356 specification that instructs an MSA to issue a rejection code MAY be
357 complied with by accepting the message and subsequently generating a
358 bounce message. (That is, if the MSA is going to reject a message
359 for any reason except being unable to determine a return path, it can
360 optionally do an immediate rejection or accept the message and then
361 mail a bounce.)
362
363 NOTE: In the normal case of message submission, immediately rejecting
364 the message is preferred, as it gives the user and MUA direct
365 feedback. To properly handle delayed bounces, the client MUA needs
366 to maintain a queue of messages it has submitted and match bounces to
367 them. Note that many contemporary MUAs do not have this capability.
368
3693.3. Authorized Submission
370
371 Numerous methods have been used to ensure that only authorized users
372 are able to submit messages. These methods include authenticated
373 SMTP, IP address restrictions, secure IP and other tunnels, and prior
374 POP authentication.
375
376 Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It
377 allows the MSA to determine an authorization identity for the message
378 submission, one that is not tied to other protocols.
379
380 IP address restrictions are very widely implemented, but they do not
381 allow for travelers and similar situations, and they can be easily
382 spoofed unless all transport paths between the MUA and MSA are
383 trustworthy.
384
385 Secure IP [IPSEC], and other encrypted and authenticated tunneling
386 techniques, can also be used and provide additional benefits of
387 protection against eavesdropping and traffic analysis.
388
389 Requiring a POP [POP3] authentication (from the same IP address)
390 within some amount of time (e.g., 20 minutes) prior to the start of a
391
392
393
394Gellens & Klensin Standards Track [Page 7]
395
396RFC 6409 Message Submission for Mail November 2011
397
398
399 message submission session has also been used, but this does impose
400 restrictions on clients as well as servers, which may cause
401 difficulties. Specifically, the client must do a POP authentication
402 before an SMTP submission session, and not all clients are capable
403 and configured for this. Also, the MSA must coordinate with the POP
404 server, which may be difficult. There is also a window during which
405 an unauthorized user can submit messages and appear to be a
406 previously authorized user. Since it is dependent on the MUA's IP
407 addresses, this technique is substantially as subject to IP address
408 spoofing as validation based on known IP addresses alone (see above).
409
4104. Mandatory Actions
411
412 An MSA MUST do all of the following:
413
4144.1. General Submission Rejection Code
415
416 Unless covered by a more precise response code, response code 554 is
417 to be used to reject a MAIL, RCPT, or DATA command that contains
418 something improper.
419
4204.2. Ensure All Domains Are Fully Qualified todo future: ../smtpserver/server.go:1580
421
422 The MSA MUST ensure that all domains in the SMTP envelope are fully
423 qualified.
424
425 If the MSA examines or alters the message text in any way, except to
426 add trace header fields [SMTP-MTA], it MUST ensure that all domains
427 in address header fields are fully qualified.
428
429 Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command
430 that contains improper domain references.
431
432 A frequent local convention is to accept single-level domains (e.g.,
433 'sales') and then to expand the reference by adding the remaining
434 portion of the domain name (e.g., to 'sales.example.net'). Local
435 conventions that permit single-level domains SHOULD reject, rather
436 than expand, incomplete multi-level domains (e.g., 'squeaky.sales'),
437 since such expansion is particularly risky.
438
4394.3. Require Authentication
440
441 The MSA MUST, by default, issue an error response to the MAIL command
442 if the session has not been authenticated using [SMTP-AUTH], unless
443 it has already independently established authentication or
444 authorization (such as being within a protected subnetwork).
445
446 Section 3.3 discusses authentication mechanisms.
447
448
449
450Gellens & Klensin Standards Track [Page 8]
451
452RFC 6409 Message Submission for Mail November 2011
453
454
455 Reply code 530 [SMTP-AUTH] is used for this purpose.
456
4575. Recommended Actions
458
459 The MSA SHOULD do all of the following.
460
4615.1. Enforce Address Syntax
462
463 An MSA SHOULD reject messages with illegal syntax in a sender or
464 recipient SMTP envelope address.
465
466 If the MSA examines or alters the message text in any way, except to
467 add trace header fields, it SHOULD reject messages with illegal
468 address syntax in address header fields.
469
470 Reply code 501 is to be used to reject a MAIL or RCPT command that
471 contains a detectably improper address.
472
473 When addresses are resolved after submission of the message body,
474 reply code 554 (with a suitable enhanced status code from
475 [SMTP-CODES]) is used after end-of-data, if the message contains
476 invalid addresses in the header.
477
4785.2. Log Errors
479
480 The MSA SHOULD log message errors, especially apparent
481 misconfigurations of client software.
482
483 It can be very helpful to notify the administrator when problems are
484 detected with local mail clients. This is another advantage of
485 distinguishing submission from relay: system administrators might be
486 interested in local configuration problems, but not in client
487 problems at other sites.
488
489 Note that it is important to impose limits on such logging to prevent
490 certain forms of denial-of-service (DoS) attacks.
491
4925.3. Apply Shorter Timeouts 5321:3610 todo future: ../smtpserver/server.go:481
493
494 The timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are
495 designed to deal with the many types of situations that can be
496 encountered on the public Internet. The relationship among clients
497 and servers corresponding to this specification is typically much
498 closer and more predictable. Submission clients behave differently
499 from relay client in some areas, especially tolerance for timeouts.
500 In practice, message submission clients tend to have short timeouts
501 (perhaps 2-5 minutes for a reply to any command). Submission servers
502 SHOULD respond to any command (even DATA) in fewer than 2 minutes.
503
504
505
506Gellens & Klensin Standards Track [Page 9]
507
508RFC 6409 Message Submission for Mail November 2011
509
510
511 When the submission server has a close administrative and/or network
512 relationship with the submission client(s) -- e.g., with a webmail
513 interface calling on a tightly bound submission server -- mutual
514 agreement on much shorter timeouts MAY be appropriate.
515
5166. Optional Actions
517
518 The MSA MAY do any of the following.
519
5206.1. Enforce Submission Rights
521
522 The MSA MAY issue an error response to a MAIL command if the address ../smtpserver/server.go:1523 ../smtpserver/server.go:1981
523 in MAIL FROM appears to have insufficient submission rights or is not
524 authorized with the authentication used (if the session has been
525 authenticated).
526
527 Reply code 550 with an appropriate enhanced status code per
528 [SMTP-CODES], such as 5.7.1, is used for this purpose.
529
5306.2. Enforce Permissions
531
532 The MSA MAY issue an error response to a RCPT command if inconsistent
533 with the permissions given to the user (if the session has been
534 authenticated).
535
536 Reply code 550 with an appropriate enhanced status code per
537 [SMTP-CODES], such as 5.7.1, is used for this purpose.
538
5396.3. Check Message Data
540
541 The MSA MAY issue an error response to the DATA command or send a ../smtpserver/server.go:1798 ../smtpserver/server.go:1816
542 failure result after end-of-data if the submitted message is
543 syntactically invalid, seems inconsistent with permissions given to
544 the user (if known), or violates site policy in some way.
545
546 Reply code 554 is used for syntactic problems in the data. Reply
547 code 501 is used if the command itself is not syntactically valid.
548 Reply code 550 with an appropriate enhanced status code per
549 [SMTP-CODES] (such as 5.7.1) is used to reject based on the
550 submitting user. Reply code 550 with an appropriate enhanced status
551 code (such as 5.7.0) is used if the message violates site policy.
552
5536.4. Support for the Postmaster Address
554
555 If appropriate under local conditions and to facilitate conformance
556 with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit
557 a reduced degree of authentication for mail addressed to the
558 "postmaster" (or one of its alternate spelling forms, see
559
560
561
562Gellens & Klensin Standards Track [Page 10]
563
564RFC 6409 Message Submission for Mail November 2011
565
566
567 [SMTP-MTA]), in one or more domains, as compared to requirements
568 enforced for other addresses. Among other benefits, this provides an
569 address of last resort that can be used by authorized users to report
570 problems that otherwise prevent them from submitting mail.
571
5726.5. Adjust Character Encodings
573
574 Subject to limits imposed by other protocols and specifications, the
575 MSA MAY convert among character sets or string encodings to improve
576 message usefulness, likelihood of delivery, or conformance with other
577 specifications or recommendations. Such conversions MAY include,
578 when necessary, replacement of addresses whose encoding does not
579 conform to RFC 5321 with ones that do, using information available
580 out of band.
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
618Gellens & Klensin Standards Track [Page 11]
619
620RFC 6409 Message Submission for Mail November 2011
621
622
6237. Interaction with SMTP Extensions
624
625 The following table lists Standards Track and Experimental SMTP
626 extensions whose documents do not explicitly specify their
627 applicability to this protocol. Listed are the EHLO keyword, name,
628 an indication as to the use of the extension on the submit port, and
629 a reference.
630
631+--------------------+----------------------+--------+-----------------+
632| Keyword | Name |Sub- | Reference |
633| | |mission | |
634+--------------------+----------------------+--------+-----------------+
635|PIPELINING |Pipelining |SHOULD |[PIPELINING] |
636|ENHANCEDSTATUSCODES |Enhanced Status Codes |SHOULD |[CODES-EXTENSION]|
637|ETRN |Extended Turn |MUST NOT|[ETRN] |
638| ... |Extended Codes |SHOULD |[SMTP-CODES] |
639|DSN |Delivery Status |SHOULD |[DSN] |
640| | Notification | | |
641|SIZE |Message size |MAY |[SIZE] |
642| ... |521 reply code |MUST NOT|[REPLY-521] |
643|CHECKPOINT |Checkpoint/Restart |MAY |[CHECKPOINT] |
644|BINARYMIME |Binary MIME |MAY |[CHUNKING] |
645|CHUNKING |Chunking |MAY |[CHUNKING] |
646|8BITMIME |Use 8-bit data |SHOULD |[RFC6152] |
647|AUTH |Authentication |MUST |[SMTP-AUTH] |
648|STARTTLS |Start TLS |MAY |[START-TLS] |
649|NO-SOLICITING |Notification of |MAY |[RFC3865] |
650| | no soliciting | | |
651|MTRK |Message Tracking |MAY |[MSG-TRACK] |
652|ATRN |On-Demand Relay |MUST NOT|[RFC2645] |
653|DELIVERBY |Deliver By |MAY |[RFC2852] |
654|CONPERM |Content Conversion |MAY |[RFC4141] |
655| | Permission | | |
656|CONNEG |Content Conversion |MAY |[RFC4141] |
657| | Negotiation | | |
658+--------------------+----------------------+--------+-----------------+
659 Table 1
660
661 Future SMTP extensions SHOULD explicitly specify if they are valid on
662 the Submission port.
663
664 Some SMTP extensions are especially useful for message submission:
665
666 Extended Status Codes [SMTP-CODES] SHOULD be supported and used
667 according to [CODES-EXTENSION]. This permits the MSA to notify the
668 client of specific configuration or other problems in more detail
669 than the response codes listed in this memo. Because some rejections
670
671
672
673
674Gellens & Klensin Standards Track [Page 12]
675
676RFC 6409 Message Submission for Mail November 2011
677
678
679 are related to a site's security policy, care should be used not to
680 expose more detail to unauthenticated senders than is needed.
681
682 [PIPELINING] SHOULD be supported by the MSA.
683
684 [SMTP-AUTH] allows the MSA to validate the authority and determine
685 the identity of the submitting user and MUST be supported by the MSA.
686
687 [START-TLS] is the most widely used mechanism, at the time this
688 document was written, that allows the MUA and MSA to protect message
689 submission integrity and privacy.
690
691 Any references to the DATA command in this memo also refer to any
692 substitutes for DATA, such as the BDAT command used with [CHUNKING].
693
6948. Message Modifications
695
696 Sites MAY modify submissions to ensure compliance with standards and
697 site policy. This section describes a number of such modifications
698 that are often considered useful.
699
700 NOTE: As a matter of guidance for local decisions to implement
701 message modification, a paramount rule is to limit such actions to
702 remedies for specific problems that have clear solutions. This is
703 especially true with address elements. For example, indiscriminately
704 appending a domain to an address or element that lacks one typically
705 results in more broken addresses. An unqualified address must be
706 verified to be a valid local part in the domain before the domain can
707 be safely added.
708
709 Any message forwarded or delivered by the MSA MUST conform to the
710 requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements
711 permitted by extensions that are supported by the MSA and accepted by
712 the next-hop server.
713
714 Message modification can affect the validity of an existing message
715 signature, such as by DomainKeys Identified Mail (DKIM) [DKIM],
716 Pretty Good Privacy (PGP) [RFC4880], or Secure MIME (S/MIME)
717 [RFC5751], and can render the signature invalid. This, in turn, can
718 affect message handling by later receivers, such as filtering engines
719 that consider the presence or absence of a valid signature.
720
721
722
723
724
725
726
727
728
729
730Gellens & Klensin Standards Track [Page 13]
731
732RFC 6409 Message Submission for Mail November 2011
733
734
7358.1. Add 'Sender'
736
737 The MSA MAY add or replace the 'Sender' field, if the identity of the
738 sender is known and this is not given in the 'From' field.
739
740 The MSA MUST ensure that any address it places in a 'Sender' field
741 is, in fact, a valid mail address.
742
7438.2. Add 'Date'
744
745 The MSA MAY add a 'Date' field to the submitted message, if it lacks ../smtpserver/server.go:2011
746 it, or correct the 'Date' field if it does not conform to
747 [MESSAGE-FORMAT] syntax.
748
7498.3. Add 'Message-ID'
750
751 The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it, 5321:4131 ../smtpserver/server.go:2004
752 or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note
753 that a number of clients still do not generate 'Message-ID' fields.
754
7558.4. Transfer Encode
756
757 The MSA MAY apply transfer encoding to the message according to MIME
758 conventions, if needed and not harmful to the MIME type.
759
7608.5. Sign the Message
761
762 The MSA MAY (digitally) sign or otherwise add authentication
763 information to the message.
764
7658.6. Encrypt the Message
766
767 The MSA MAY encrypt the message for transport to reflect
768 organizational policies.
769
770 NOTE: To be useful, the addition of a signature and/or encryption by
771 the MSA generally implies that the connection between the MUA and MSA
772 must, itself, be secured in some other way, for example, by operating
773 inside of a secure environment, by securing the submission connection
774 at the transport layer, or by using an [SMTP-AUTH] mechanism that
775 provides for session integrity.
776
777
778
779
780
781
782
783
784
785
786Gellens & Klensin Standards Track [Page 14]
787
788RFC 6409 Message Submission for Mail November 2011
789
790
7918.7. Resolve Aliases
792
793 The MSA MAY resolve and rewrite aliases (e.g., Canonical Name (CNAME)
794 records) for domain names, in the SMTP envelope and/or in address
795 fields of the header, subject to local policy.
796
797 NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in
798 addresses and the session-opening announcement. As with other SMTP
799 requirements, RFC 5321 effectively prohibits an MSA from forwarding
800 such messages into the public Internet. Nonetheless, unconditionally
801 resolving aliases could be harmful. For example, if www.example.net
802 and ftp.example.net are both aliases for mail.example.net, rewriting
803 them could lose useful information.
804
8058.8. Header Rewriting
806
807 The MSA MAY rewrite local parts and/or domains in the SMTP envelope
808 and, optionally, in address fields of the header, according to local
809 policy. For example, a site may prefer to rewrite 'JRU' as
810 'J.Random.User' in order to hide login names and/or to rewrite
811 'squeaky.sales.example.net' as 'zyx.example.net' to hide machine
812 names and make it easier to move users.
813
814 However, only addresses, local-parts, or domains that match specific
815 local MSA configuration settings should be altered. It would be very
816 dangerous for the MSA to apply data-independent rewriting rules, such
817 as always deleting the first element of a domain name. So, for
818 example, a rule that strips the leftmost element of the domain, if
819 the complete domain matches '*.foo.example.net', would be acceptable.
820
821 The MSA MUST NOT rewrite a forward-pointing (destination) address in
822 a way that violates the constraints of [SMTP-MTA] on modifications of
823 local-parts. Changes to addressing and encoding, carried out in
824 conjunction with the action of Section 6.5, do not violate this
825 principle if the MSA has sufficient information available to
826 successfully and accurately apply the substitution.
827
8289. Security Considerations
829
830 Separation of submission and relay of messages allows a site to
831 implement different policies for the two types of services, including
832 requiring the use of additional security mechanisms for one or both.
833 It can do this in a way that is simpler, both technically and
834 administratively. This increases the likelihood that policies will
835 be applied correctly.
836
837
838
839
840
841
842Gellens & Klensin Standards Track [Page 15]
843
844RFC 6409 Message Submission for Mail November 2011
845
846
847 Separation also can aid in tracking and preventing unsolicited bulk
848 email.
849
850 For example, a site could configure its mail servers such that the
851 MSA requires authentication before accepting a message, and the MTA
852 rejects all RCPT commands for non-local users. This can be an
853 important element in a site's total email security policy.
854
855 If a site fails to require any form of authorization for message
856 submissions (see Section 3.3 for discussion), it is allowing open use
857 of its resources and name; unsolicited bulk email can be injected
858 using its facilities.
859
860 Section 3 includes further discussion of issues with some
861 authentication methods.
862
863 Section 5.2 includes a cautionary note that unlimited logging can
864 enable certain forms of denial-of-service attacks.
865
86610. IANA Considerations
867
868 The entries in Table 1 have been corrected (reference for NO-
869 SOLICITING) and extended (ATRN, DELIVERBY, CONPERM, and CONNEG). The
870 "SMTP Service Extensions" registry has been updated to reflect the
871 changed and new entries. Entries in the registry that do not appear
872 in the table above are correct and should not be altered.
873
874 The entry in the "SMTP Service Extensions" registry for RFC 4409 has
875 been updated to reference this document. The original reference for
876 Submit (RFC 2476), which should have been corrected earlier, has also
877 been updated to point to this document.
878
879 The entry in the "Service Name and Transport Protocol Port Number
880 Registry" for port 587 has been updated to point to this document.
881
88211. Acknowledgments
883
884 The preparation and development of the current version of this
885 specification was stimulated by discussions in the IETF YAM and EAI
886 Working Groups. Dave Crocker, Subramanian Moonesamy, Barry Leiba,
887 John Levine, and others provided text that appeared in this document
888 or versions leading up to it.
889
890 Nathaniel Borenstein and Barry Leiba were instrumental in the
891 development of RFC 4409, the update to RFC 2476.
892
893 The original memo (RFC 2476) was developed, in part, based on
894 comments and discussions that took place on and off the IETF-Submit
895
896
897
898Gellens & Klensin Standards Track [Page 16]
899
900RFC 6409 Message Submission for Mail November 2011
901
902
903 mailing list. The help of those who took the time to review that
904 document and make suggestions is appreciated, especially that of Dave
905 Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.
906
907 Special thanks to Harald Alvestrand, who got this effort started.
908
90912. References
910
91112.1. Normative References
912
913 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
914 Requirement Levels", BCP 14, RFC 2119, March 1997.
915
916 [SMTP-AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension
917 for Authentication", RFC 4954, July 2007.
918
919 [SMTP-MTA] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
920 October 2008.
921
92212.2. Informative References
923
924 [CHECKPOINT] Crocker, D. and N. Freed, "SMTP Service Extension for
925 Checkpoint/Restart", RFC 1845, September 1995.
926
927 [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission
928 of Large and Binary MIME Messages", RFC 3030,
929 December 2000.
930
931 [CODES-EXTENSION]
932 Freed, N., "SMTP Service Extension for Returning
933 Enhanced Error Codes", RFC 2034, October 1996.
934
935 [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
936 Identified Mail (DKIM) Signatures", RFC 6376,
937 September 2011.
938
939 [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
940 Extension for Delivery Status Notifications (DSNs)",
941 RFC 3461, January 2003.
942
943 [ETRN] De Winter, J., "SMTP Service Extension for Remote
944 Message Queue Starting", RFC 1985, August 1996.
945
946 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
947 4rev1", RFC 3501, March 2003.
948
949 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
950 Internet Protocol", RFC 4301, December 2005.
951
952
953
954Gellens & Klensin Standards Track [Page 17]
955
956RFC 6409 Message Submission for Mail November 2011
957
958
959 [MESSAGE-FORMAT]
960 Resnick, P., Ed., "Internet Message Format", RFC 5322,
961 October 2008.
962
963 [MSG-TRACK] Allman, E. and T. Hansen, "SMTP Service Extension for
964 Message Tracking", RFC 3885, September 2004.
965
966 [PIPELINING] Freed, N., "SMTP Service Extension for Command
967 Pipelining", STD 60, RFC 2920, September 2000.
968
969 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version
970 3", STD 53, RFC 1939, May 1996.
971
972 [REPLY-521] Durand, A. and F. Dupont, "SMTP 521 Reply Code",
973 RFC 1846, September 1995.
974
975 [RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with
976 Dynamic IP Addresses", RFC 2645, August 1999.
977
978 [RFC2852] Newman, D., "Deliver By SMTP Service Extension",
979 RFC 2852, June 2000.
980
981 [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer
982 Protocol (SMTP) Service Extension", RFC 3865,
983 September 2004.
984
985 [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for
986 Content Conversion", RFC 4141, November 2005.
987
988 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
989 R. Thayer, "OpenPGP Message Format", RFC 4880,
990 November 2007.
991
992 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose
993 Internet Mail Extensions (S/MIME) Version 3.2 Message
994 Specification", RFC 5751, January 2010.
995
996 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
997 Service Extension for 8-bit MIME Transport", STD 71,
998 RFC 6152, March 2011.
999
1000 [SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service
1001 Extension for Message Size Declaration", STD 10,
1002 RFC 1870, November 1995.
1003
1004
1005
1006
1007
1008
1009
1010Gellens & Klensin Standards Track [Page 18]
1011
1012RFC 6409 Message Submission for Mail November 2011
1013
1014
1015 [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes",
1016 RFC 3463, January 2003.
1017
1018 [START-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
1019 over Transport Layer Security", RFC 3207, February 2002.
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066Gellens & Klensin Standards Track [Page 19]
1067
1068RFC 6409 Message Submission for Mail November 2011
1069
1070
1071Appendix A. Major Changes from RFC 4409
1072
1073 The protocol specified by this document is not substantively
1074 different from that of RFC 4409. However, the present specification
1075 contains several clarifications and updates to reflect changes and
1076 revisions to other documents subsequent to the publication of RFC
1077 4409. The following specific changes may be of interest to some
1078 readers.
1079
1080 o Updated several references to reflect more recent versions of the
1081 various specifications. As part of this, reclassified RFC 4954 to
1082 a normative reference (SMTP AUTH is a MUST for RFC 4409 and this
1083 specification).
1084
1085 o Updated the text in Section 7 to reflect the existence and partial
1086 population of the registry and the included table (Table 1) to
1087 correct one entry and add others. See Section 10 for more
1088 information.
1089
1090 o Added new text (Section 5.3) to clarify that Submission Servers
1091 should respond quickly.
1092
1093 o Added text to make it explicit that character encoding changes are
1094 permitted.
1095
1096 o Added text to make it clear that modifications to signed messages
1097 may cause problems and that they should be carefully considered.
1098
1099Authors' Addresses
1100
1101 Randall Gellens
1102 QUALCOMM Incorporated
1103 5775 Morehouse Drive
1104 San Diego, CA 92121-2779
1105 USA
1106
1107 EMail: rg+ietf@qualcomm.com
1108
1109
1110 John C Klensin
1111 1770 Massachusetts Ave, #322
1112 Cambridge, MA 02140
1113 USA
1114
1115 Phone: +1 617 491 5735
1116 EMail: john-ietf@jck.com
1117
1118
1119
1120
1121
1122Gellens & Klensin Standards Track [Page 20]
1123
1124