7Internet Engineering Task Force (IETF) R. Gellens
8Request for Comments: 6409 QUALCOMM Incorporated
10Obsoletes: 4409 November 2011
11Category: Standards Track
15 Message Submission for Mail
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
24 Message relay is unaffected, and continues to use SMTP over port 25.
26 When conforming to this document, message submission uses the
27 protocol specified here, normally over port 587.
29 This separation of function offers a number of benefits, including
30 the ability to apply specific security or policy requirements.
34 This is an Internet Standards Track document.
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.
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.
58Gellens & Klensin Standards Track [Page 1]
60RFC 6409 Message Submission for Mail November 2011
65 Copyright (c) 2011 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
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.
114Gellens & Klensin Standards Track [Page 2]
116RFC 6409 Message Submission for Mail November 2011
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
170Gellens & Klensin Standards Track [Page 3]
172RFC 6409 Message Submission for Mail November 2011
177 SMTP [SMTP-MTA] was defined as a message *transfer* protocol, that
178 is, a means to route (if needed) and deliver finished (complete)
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).
189 In order to permit unconstrained communications, SMTP is not often
190 authenticated during message relay.
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.
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
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.
226Gellens & Klensin Standards Track [Page 4]
228RFC 6409 Message Submission for Mail November 2011
231 Separating messages into submissions and transfers allows developers
232 and network administrators to do the following more easily:
234 o Implement security policies and guard against unauthorized mail
235 relaying or injection of unsolicited bulk mail.
237 o Implement authenticated submission, including off-site submission
238 by authorized users such as travelers.
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.
244 o Detect configuration problems with a site's mail clients.
246 o Provide a basis for adding enhanced submission services.
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.
2522. Document Information
2542.1. Definitions of Terms Used in This Memo
256 Many of the concepts and terms used in this document are defined in
257 [SMTP-MTA]; familiarity with those documents is assumed here.
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
265 Message Submission Agent (MSA)
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.
271 Message Transfer Agent (MTA)
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.
282Gellens & Klensin Standards Track [Page 5]
284RFC 6409 Message Submission for Mail November 2011
287 Message User Agent (MUA)
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
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.
2992.2. Conventions Used in This Document
301 Examples use the 'example.net' domain.
303 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
304 in this document are to be interpreted as defined in [KEYWORDS].
3083.1. Submission Identification
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.
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.
3203.2. Message Rejection and Bouncing
322 MTAs and MSAs MAY implement message rejection rules that rely, in
323 part, on whether the message is a submission or a relay.
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.
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.
338Gellens & Klensin Standards Track [Page 6]
340RFC 6409 Message Submission for Mail November 2011
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.
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.)
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
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.
3693.3. Authorized Submission
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
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.
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
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.
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
394Gellens & Klensin Standards Track [Page 7]
396RFC 6409 Message Submission for Mail November 2011
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).
412 An MSA MUST do all of the following:
4144.1. General Submission Rejection Code
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
422 The MSA MUST ensure that all domains in the SMTP envelope are fully
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.
429 Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command
430 that contains improper domain references.
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.
4394.3. Require Authentication
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).
446 Section 3.3 discusses authentication mechanisms.
450Gellens & Klensin Standards Track [Page 8]
452RFC 6409 Message Submission for Mail November 2011
455 Reply code 530 [SMTP-AUTH] is used for this purpose.
4575. Recommended Actions
459 The MSA SHOULD do all of the following.
4615.1. Enforce Address Syntax
463 An MSA SHOULD reject messages with illegal syntax in a sender or
464 recipient SMTP envelope address.
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.
470 Reply code 501 is to be used to reject a MAIL or RCPT command that
471 contains a detectably improper address.
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.
480 The MSA SHOULD log message errors, especially apparent
481 misconfigurations of client software.
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.
489 Note that it is important to impose limits on such logging to prevent
490 certain forms of denial-of-service (DoS) attacks.
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.
506Gellens & Klensin Standards Track [Page 9]
508RFC 6409 Message Submission for Mail November 2011
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.
518 The MSA MAY do any of the following.
5206.1. Enforce Submission Rights
523 in MAIL FROM appears to have insufficient submission rights or is not
524 authorized with the authentication used (if the session has been
527 Reply code 550 with an appropriate enhanced status code per
528 [SMTP-CODES], such as 5.7.1, is used for this purpose.
5306.2. Enforce Permissions
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
536 Reply code 550 with an appropriate enhanced status code per
537 [SMTP-CODES], such as 5.7.1, is used for this purpose.
5396.3. Check Message Data
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.
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.
5536.4. Support for the Postmaster Address
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
562Gellens & Klensin Standards Track [Page 10]
564RFC 6409 Message Submission for Mail November 2011
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.
5726.5. Adjust Character Encodings
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
618Gellens & Klensin Standards Track [Page 11]
620RFC 6409 Message Submission for Mail November 2011
6237. Interaction with SMTP Extensions
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
631+--------------------+----------------------+--------+-----------------+
632| Keyword | Name |Sub- | Reference |
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] |
656|CONNEG |Content Conversion |MAY |[RFC4141] |
658+--------------------+----------------------+--------+-----------------+
661 Future SMTP extensions SHOULD explicitly specify if they are valid on
664 Some SMTP extensions are especially useful for message submission:
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
674Gellens & Klensin Standards Track [Page 12]
676RFC 6409 Message Submission for Mail November 2011
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.
682 [PIPELINING] SHOULD be supported by the MSA.
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.
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.
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].
6948. Message Modifications
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.
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
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
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.
730Gellens & Klensin Standards Track [Page 13]
732RFC 6409 Message Submission for Mail November 2011
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.
740 The MSA MUST ensure that any address it places in a 'Sender' field
741 is, in fact, a valid mail address.
746 it, or correct the 'Date' field if it does not conform to
747 [MESSAGE-FORMAT] syntax.
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.
757 The MSA MAY apply transfer encoding to the message according to MIME
758 conventions, if needed and not harmful to the MIME type.
762 The MSA MAY (digitally) sign or otherwise add authentication
763 information to the message.
7658.6. Encrypt the Message
767 The MSA MAY encrypt the message for transport to reflect
768 organizational policies.
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.
786Gellens & Klensin Standards Track [Page 14]
788RFC 6409 Message Submission for Mail November 2011
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.
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.
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.
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.
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.
8289. Security Considerations
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.
842Gellens & Klensin Standards Track [Page 15]
844RFC 6409 Message Submission for Mail November 2011
847 Separation also can aid in tracking and preventing unsolicited bulk
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.
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.
860 Section 3 includes further discussion of issues with some
861 authentication methods.
863 Section 5.2 includes a cautionary note that unlimited logging can
864 enable certain forms of denial-of-service attacks.
86610. IANA Considerations
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.
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.
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.
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.
890 Nathaniel Borenstein and Barry Leiba were instrumental in the
891 development of RFC 4409, the update to RFC 2476.
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
898Gellens & Klensin Standards Track [Page 16]
900RFC 6409 Message Submission for Mail November 2011
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.
907 Special thanks to Harald Alvestrand, who got this effort started.
91112.1. Normative References
913 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
914 Requirement Levels", BCP 14, RFC 2119, March 1997.
916 [SMTP-AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension
917 for Authentication", RFC 4954, July 2007.
919 [SMTP-MTA] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
92212.2. Informative References
924 [CHECKPOINT] Crocker, D. and N. Freed, "SMTP Service Extension for
925 Checkpoint/Restart", RFC 1845, September 1995.
927 [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission
928 of Large and Binary MIME Messages", RFC 3030,
932 Freed, N., "SMTP Service Extension for Returning
933 Enhanced Error Codes", RFC 2034, October 1996.
935 [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
936 Identified Mail (DKIM) Signatures", RFC 6376,
939 [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
940 Extension for Delivery Status Notifications (DSNs)",
941 RFC 3461, January 2003.
943 [ETRN] De Winter, J., "SMTP Service Extension for Remote
944 Message Queue Starting", RFC 1985, August 1996.
946 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
947 4rev1", RFC 3501, March 2003.
949 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
950 Internet Protocol", RFC 4301, December 2005.
954Gellens & Klensin Standards Track [Page 17]
956RFC 6409 Message Submission for Mail November 2011
960 Resnick, P., Ed., "Internet Message Format", RFC 5322,
963 [MSG-TRACK] Allman, E. and T. Hansen, "SMTP Service Extension for
964 Message Tracking", RFC 3885, September 2004.
966 [PIPELINING] Freed, N., "SMTP Service Extension for Command
967 Pipelining", STD 60, RFC 2920, September 2000.
969 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version
970 3", STD 53, RFC 1939, May 1996.
972 [REPLY-521] Durand, A. and F. Dupont, "SMTP 521 Reply Code",
973 RFC 1846, September 1995.
975 [RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with
976 Dynamic IP Addresses", RFC 2645, August 1999.
978 [RFC2852] Newman, D., "Deliver By SMTP Service Extension",
981 [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer
982 Protocol (SMTP) Service Extension", RFC 3865,
985 [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for
986 Content Conversion", RFC 4141, November 2005.
988 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
989 R. Thayer, "OpenPGP Message Format", RFC 4880,
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.
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.
1000 [SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service
1001 Extension for Message Size Declaration", STD 10,
1002 RFC 1870, November 1995.
1010Gellens & Klensin Standards Track [Page 18]
1012RFC 6409 Message Submission for Mail November 2011
1015 [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes",
1016 RFC 3463, January 2003.
1018 [START-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
1019 over Transport Layer Security", RFC 3207, February 2002.
1066Gellens & Klensin Standards Track [Page 19]
1068RFC 6409 Message Submission for Mail November 2011
1071Appendix A. Major Changes from RFC 4409
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
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
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
1090 o Added new text (Section 5.3) to clarify that Submission Servers
1091 should respond quickly.
1093 o Added text to make it explicit that character encoding changes are
1096 o Added text to make it clear that modifications to signed messages
1097 may cause problems and that they should be carefully considered.
1102 QUALCOMM Incorporated
1103 5775 Morehouse Drive
1104 San Diego, CA 92121-2779
1107 EMail: rg+ietf@qualcomm.com
1111 1770 Massachusetts Ave, #322
1115 Phone: +1 617 491 5735
1116 EMail: john-ietf@jck.com
1122Gellens & Klensin Standards Track [Page 20]