idnits 2.17.1 draft-ietf-yam-rfc4409bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4409, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 2, 2011) is 4620 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 YAM R. Gellens 3 Internet-Draft QUALCOMM Incorporated 4 Obsoletes: 4409 (if approved) J. Klensin 5 Intended status: Standards Track September 2, 2011 6 Expires: March 5, 2012 8 Message Submission for Mail 9 draft-ietf-yam-rfc4409bis-03 11 Abstract 13 This memo splits message submission from message relay, allowing each 14 service to operate according to its own rules (for security, policy, 15 etc.), and specifies what actions are to be taken by a submission 16 server. 18 Message relay is unaffected, and continues to use SMTP over port 25. 20 When conforming to this document, message submission uses the 21 protocol specified here, normally over port 587. 23 This separation of function offers a number of benefits, including 24 the ability to apply specific security or policy requirements. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 5, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Discussion List . . . . . . . . . . . . . . . . . . . . . 5 62 1.2. Note to IESG and/or Document Shepherd . . . . . . . . . . 5 63 2. Document Information . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. Definitions of Terms Used in This Memo . . . . . . . . . . 6 65 2.2. Conventions Used in This Document . . . . . . . . . . . . 6 66 3. Message Submission . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Submission Identification . . . . . . . . . . . . . . . . 7 68 3.2. Message Rejection and Bouncing . . . . . . . . . . . . . . 7 69 3.3. Authorized Submission . . . . . . . . . . . . . . . . . . 8 70 4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. General Submission Rejection Code . . . . . . . . . . . . 8 72 4.2. Ensure All Domains Are Fully-Qualified . . . . . . . . . . 9 73 4.3. Require Authentication . . . . . . . . . . . . . . . . . . 9 74 5. Recommended Actions . . . . . . . . . . . . . . . . . . . . . 9 75 5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . . . 9 76 5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.3. Apply Shorter Timeouts . . . . . . . . . . . . . . . . . . 10 78 6. Optional Actions . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. Enforce Submission Rights . . . . . . . . . . . . . . . . 10 80 6.2. Enforce Permissions . . . . . . . . . . . . . . . . . . . 11 81 6.3. Check Message Data . . . . . . . . . . . . . . . . . . . . 11 82 6.4. Support for the Postmaster Address . . . . . . . . . . . . 11 83 6.5. Adjust Character Encodings . . . . . . . . . . . . . . . . 11 84 7. Interaction with SMTP Extensions . . . . . . . . . . . . . . . 12 85 8. Message Modifications . . . . . . . . . . . . . . . . . . . . 13 86 8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . . 14 87 8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . . . 14 88 8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . . 14 89 8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . . 14 90 8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . . 14 91 8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . . 14 92 8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . . 14 93 8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . . . 15 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 99 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 100 Appendix A. Major Changes from RFC 4409 . . . . . . . . . . . . . 19 101 Appendix B. Note on References . . . . . . . . . . . . . . . . . 20 102 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 20 103 C.1. Changes between RFC 4409 and version-00 of this 104 document . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 C.2. Changes between version -00 and version -01 . . . . . . . 21 106 C.3. Changes between version -01 and version -02 . . . . . . . 21 107 C.4. Changes between version -02 and version -03 . . . . . . . 21 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 110 1. Introduction 112 SMTP [SMTP-MTA] was defined as a message *transfer* protocol, that 113 is, a means to route (if needed) and deliver finished (complete) 114 messages. 116 Message Transfer Agents (MTAs) are not supposed to alter the message 117 text, except to add 'Received', 'Return-Path', and other header 118 fields as required by [SMTP-MTA]. However, SMTP is now also widely 119 used as a message *submission* protocol, that is, a means for Message 120 User Agents (MUAs) to introduce new messages into the MTA routing 121 network. The process that accepts message submissions from MUAs is 122 termed a Message Submission Agent (MSA). 124 In order to permit unconstrained communications, SMTP is not often 125 authenticated during message relay. 127 Authentication and authorization of initial submissions have become 128 increasingly important, driven by changes in security requirements 129 and rising expectations that submission servers take responsibility 130 for the message traffic they originate. 132 For example, due to the prevalence of machines that have worms, 133 viruses, or other malicious software that generate large amounts of 134 spam, many sites now prohibit outbound traffic on the standard SMTP 135 port (port 25), funneling all mail submissions through submission 136 servers. 138 In addition to authentication and authorization issues, messages 139 being submitted are in some cases finished (complete) messages, and 140 in other cases are unfinished (incomplete) in one or more aspects. 141 Unfinished messages may need to be completed to ensure they conform 142 to the Message Format specification [MESSAGE-FORMAT], and related 143 requirements. For example, the message may lack a proper 'Date' 144 header field, and domains might not be fully qualified. In some 145 cases, the MUA may be unable to generate finished messages (e.g., it 146 might not know its time zone). Even when submitted messages are 147 complete, local site policy may dictate that the message text be 148 examined or modified in some way, e.g., to conceal local name or 149 address spaces. Such completions or modifications have been shown to 150 cause harm when performed by downstream MTAs -- that is, MTAs after 151 the first-hop submission MTA -- and are in general considered to be 152 outside the province of standardized MTA functionality. 154 Separating messages into submissions and transfers allows developers 155 and network administrators to more easily do the following: 157 o Implement security policies and guard against unauthorized mail 158 relaying or injection of unsolicited bulk mail 160 o Implement authenticated submission, including off-site submission 161 by authorized users such as travelers 163 o Separate the relevant software code differences, thereby making 164 each code base more straightforward and allowing for different 165 programs for relay and submission 167 o Detect configuration problems with a site's mail clients 169 o Provide a basis for adding enhanced submission services. 171 This memo describes a low-cost, deterministic means for messages to 172 be identified as submissions, and specifies what actions are to be 173 taken by a submission server. 175 1.1. Discussion List 177 [[anchor3: RFC Editor: Please remove this section before 178 publication.]] 180 This document is being discussed in the IETF YAM Working Group. 182 1.2. Note to IESG and/or Document Shepherd 184 [[anchor5: RFC Editor: Please remove this section before 185 publication.]] 187 RFC 4409 was published in April 2006, so the "time in place" 188 requirement of RFC 2026 has been satisfied. 190 Message Submission on port 587 has seen significant deployment over 191 the past 8-10 years, becoming widespread in the past 2-3 years. 192 There are several reasons for this, such as decisions by many ISPs 193 and organizations in general to block outbound port 25 (except by 194 their own border MTAs), and consequently to support 587 with 195 authentication, as well as recognition of the need to apply different 196 policies to submission and relay. 198 The effort required to reissue and process this document is justified 199 by the need to update and clarify several references and by 200 additional clarifying text to support email internationalization 201 work. 203 2. Document Information 205 2.1. Definitions of Terms Used in This Memo 207 Many of the concepts and terms used in this document are defined in 208 [SMTP-MTA]; familiarity with those documents is assumed here. 210 Fully-Qualified 212 Containing or consisting of a domain that can be globally resolved 213 using the Domain Name Service; that is, not a local alias or partial 214 specification. 216 Message Submission Agent (MSA) 218 A process that conforms to this specification. An MSA acts as a 219 submission server to accept messages from MUAs, and either delivers 220 them or acts as an SMTP client to relay them to an MTA. 222 Message Transfer Agent (MTA) 224 A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server 225 to accept messages from an MSA or another MTA, and either delivers 226 them or acts as an SMTP client to relay them to another MTA. 228 Message User Agent (MUA) 230 A process that acts (often on behalf of a user and with a user 231 interface) to compose and submit new messages, and process delivered 232 messages. 234 For delivered messages, the receiving MUA may obtain and process the 235 message according to local conventions or, in what is commonly 236 referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP 237 [IMAP4] is used to access delivered messages, whereas the protocol 238 defined here (or SMTP) is used to submit messages. 240 2.2. Conventions Used in This Document 242 Examples use the 'example.net' domain. 244 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 245 in this document are to be interpreted as defined in [KEYWORDS]. 247 3. Message Submission 248 3.1. Submission Identification 250 Port 587 is reserved for email message submission as specified in 251 this document. Messages received on this port are defined to be 252 submissions. The protocol used is ESMTP [SMTP-MTA], with additional 253 restrictions or allowances as specified here. 255 Although most email clients and servers can be configured to use port 256 587 instead of 25, there are cases where this is not possible or 257 convenient. A site MAY choose to use port 25 for message submission, 258 by designating some hosts to be MSAs and others to be MTAs. 260 3.2. Message Rejection and Bouncing 262 MTAs and MSAs MAY implement message rejection rules that rely in part 263 on whether the message is a submission or a relay. 265 For example, some sites might configure their MTAs to reject all RCPT 266 commands for messages that do not reference local users, and 267 configure their MSA to reject all message submissions that do not 268 come from authorized users, with authorization based either on 269 authenticated identity or the submitting endpoint being within a 270 protected IP environment. 272 NOTE: It is better to reject a message than to risk sending one that 273 is damaged. This is especially true for problems that are 274 correctable by the MUA, for example, an invalid 'From' field. 276 If an MSA is not able to determine a return path to the submitting 277 user, from a valid MAIL FROM, a valid source IP address, or based on 278 authenticated identity, then the MSA SHOULD immediately reject the 279 message. A message can be immediately rejected by returning a 550 280 code to the MAIL command. 282 Note that a null return path, that is, MAIL FROM:<>, is permitted and 283 MUST NOT in itself be cause for rejecting a message. (MUAs need to 284 generate null return-path messages for a variety of reasons, 285 including disposition notifications.) 287 Except in the case where the MSA is unable to determine a valid 288 return path for the message being submitted, text in this 289 specification that instructs an MSA to issue a rejection code MAY be 290 complied with by accepting the message and subsequently generating a 291 bounce message. (That is, if the MSA is going to reject a message 292 for any reason except being unable to determine a return path, it can 293 optionally do an immediate rejection or accept the message and then 294 mail a bounce.) 295 NOTE: In the normal case of message submission, immediately rejecting 296 the message is preferred, as it gives the user and MUA direct 297 feedback. To properly handle delayed bounces, the client MUA needs 298 to maintain a queue of messages it has submitted, and match bounces 299 to them. Note that many contemporary MUAs do not have this 300 capability. 302 3.3. Authorized Submission 304 Numerous methods have been used to ensure that only authorized users 305 are able to submit messages. These methods include authenticated 306 SMTP, IP address restrictions, secure IP and other tunnels, and prior 307 POP authentication. 309 Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It 310 allows the MSA to determine an authorization identity for the message 311 submission, one that is not tied to other protocols. 313 IP address restrictions are very widely implemented, but do not allow 314 for travelers and similar situations, and can be easily spoofed 315 unless all transport paths between the MUA and MSA are trustworthy. 317 Secure IP [IPSEC], and other encrypted and authenticated tunneling 318 techniques, can also be used and provide additional benefits of 319 protection against eavesdropping and traffic analysis. 321 Requiring a POP [POP3] authentication (from the same IP address) 322 within some amount of time (e.g., 20 minutes) prior to the start of a 323 message submission session has also been used, but this does impose 324 restrictions on clients as well as servers, which may cause 325 difficulties. Specifically, the client must do a POP authentication 326 before an SMTP submission session, and not all clients are capable 327 and configured for this. Also, the MSA must coordinate with the POP 328 server, which may be difficult. There is also a window during which 329 an unauthorized user can submit messages and appear to be a 330 previously authorized user. Since it is dependent on the MUA's IP 331 addresses, this technique is substantially as subject to IP address 332 spoofing as validation based on known IP addresses alone (see above). 334 4. Mandatory Actions 336 An MSA MUST do all of the following: 338 4.1. General Submission Rejection Code 340 Unless covered by a more precise response code, response code 554 is 341 to be used to reject a MAIL, RCPT, or DATA command that contains 342 something improper. 344 4.2. Ensure All Domains Are Fully-Qualified 346 The MSA MUST ensure that all domains in the SMTP envelope are fully- 347 qualified. 349 If the MSA examines or alters the message text in any way, except to 350 add trace header fields [SMTP-MTA], it MUST ensure that all domains 351 in address header fields are fully-qualified. 353 Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command 354 that contains improper domain references. 356 A frequent local convention is to accept single-level domains (e.g., 357 'sales') and then to expand the reference by adding the remaining 358 portion of the domain name (e.g., to 'sales.example.net'). Local 359 conventions that permit single-level domains SHOULD reject, rather 360 than expand, incomplete multi-level domains (e.g., 'squeaky.sales'), 361 since such expansion is particularly risky. 363 4.3. Require Authentication 365 The MSA MUST by default issue an error response to the MAIL command 366 if the session has not been authenticated using [SMTP-AUTH], unless 367 it has already independently established authentication or 368 authorization (such as being within a protected subnetwork). 370 Section 3.3 discusses authentication mechanisms. 372 Reply code 530 [SMTP-AUTH] is used for this purpose. 374 5. Recommended Actions 376 The MSA SHOULD do all of the following: 378 5.1. Enforce Address Syntax 380 An MSA SHOULD reject messages with illegal syntax in a sender or 381 recipient SMTP envelope address. 383 If the MSA examines or alters the message text in way, except to add 384 trace header fields, it SHOULD reject messages with illegal address 385 syntax in address header fields. 387 Reply code 501 is to be used to reject a MAIL or RCPT command that 388 contains a detectably improper address. 390 When addresses are resolved after submission of the message body, 391 reply code 554 (with a suitable enhanced status code from 392 [SMTP-CODES]) is used after end-of-data, if the message contains 393 invalid addresses in the header. 395 5.2. Log Errors 397 The MSA SHOULD log message errors, especially apparent 398 misconfigurations of client software. 400 It can be very helpful to notify the administrator when problems are 401 detected with local mail clients. This is another advantage of 402 distinguishing submission from relay: system administrators might be 403 interested in local configuration problems, but not in client 404 problems at other sites. 406 Note that it is important to impose limits on such logging to prevent 407 certain forms of denial of service (DoS) attacks. 409 5.3. Apply Shorter Timeouts 411 The timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are 412 designed to deal with the many types of situations that can be 413 encountered on the public Internet. The relationship among clients 414 and servers corresponding to this specification is typically much 415 closer and more predictable. Submission clients behave differently 416 from relay client in some areas, especially tolerance for time- outs. 417 In practice, message submission clients tend to have short time-outs 418 (perhaps 2-5 minutes for a reply to any command). Submission servers 419 SHOULD respond to any command (even DATA) in fewer than 2 minutes. 420 When the submission server has a close administrative and/or network 421 relationship with the submission client(s) --e.g., with a webmail 422 interface calling on a tightly-bound submission server-- mutual 423 agreement on much shorter timeouts MAY be appropriate. 425 6. Optional Actions 427 The MSA MAY do any of the following: 429 6.1. Enforce Submission Rights 431 The MSA MAY issue an error response to a MAIL command if the address 432 in MAIL FROM appears to have insufficient submission rights, or is 433 not authorized with the authentication used (if the session has been 434 authenticated). 436 Reply code 550 with an appropriate enhanced status code per 438 [SMTP-CODES], such as 5.7.1, is used for this purpose. 440 6.2. Enforce Permissions 442 The MSA MAY issue an error response to a RCPT command if inconsistent 443 with the permissions given to the user (if the session has been 444 authenticated). 446 Reply code 550 with an appropriate enhanced status code per 447 [SMTP-CODES], such as 5.7.1, is used for this purpose. 449 6.3. Check Message Data 451 The MSA MAY issue an error response to the DATA command or send a 452 failure result after end-of-data if the submitted message is 453 syntactically invalid, or seems inconsistent with permissions given 454 to the user (if known), or violates site policy in some way. 456 Reply code 554 is used for syntactic problems in the data. Reply 457 code 501 is used if the command itself is not syntactically valid. 458 Reply code 550 with an appropriate enhanced status code per 459 [SMTP-CODES] (such as 5.7.1) is used to reject based on the 460 submitting user. Reply code 550 with an appropriate enhanced status 461 code (such as 5.7.0) is used if the message violates site policy. 463 6.4. Support for the Postmaster Address 465 If appropriate under local conditions and to facilitate conformance 466 with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit 467 a reduced degree of authentication for mail addressed to the 468 "postmaster" (or one of its alternate spelling forms, see 469 [SMTP-MTA]), in one or more domains, as compared to requirements 470 enforced for other addresses. Among other benefits, this provides an 471 address of last resort that can be used by authorized users to report 472 problems that otherwise prevent them from submitting mail. 474 6.5. Adjust Character Encodings 476 Subject to limits imposed by other protocols and specifications, the 477 MSA MAY convert among character sets or string encodings to improve 478 message usefulness, likelihood of delivery, or conformance with other 479 specifications or recommendations. Such conversions MAY include, 480 when necessary, replacement of addresses whose encoding does not 481 conform to RFC 5321 with ones that do, using information available 482 out of band. 484 7. Interaction with SMTP Extensions 486 The following table lists standards-track and Experimental SMTP 487 extensions whose documents do not explicitly specify their 488 applicability to this protocol. Listed are the EHLO keyword, name, 489 an indication as to the use of the extension on the submit port, and 490 a reference: 492 [[RFC Editor: Please see if you can do something with the formatting 493 of this table that results in a more readable appearance. Consult 494 the document editors as needed.]] 496 +------------------+------------------+-----------+-----------------+ 497 | Keyword | Name | Submissio | Reference | 498 | | | n | | 499 +------------------+------------------+-----------+-----------------+ 500 | PIPELINING | Pipelining | SHOULD | [PIPELINING] | 501 | ENHANCEDSTATUSCO | Enhanced Status | SHOULD | [CODES-EXTENSIO | 502 | DES | Codes | | N] | 503 | ETRN | Extended Turn | MUST NOT | [ETRN] | 504 | ... | Extended Codes | SHOULD | [SMTP-CODES] | 505 | DSN | Delivery Status | SHOULD | [DSN] | 506 | | Notification | | | 507 | SIZE | Message size | MAY | [SIZE] | 508 | ... | 521 reply code | MUST NOT | [REPLY-521] | 509 | CHECKPOINT | Checkpoint/Resta | MAY | [CHECKPOINT] | 510 | | rt | | | 511 | BINARYMIME | Binary MIME | MAY | [CHUNKING] | 512 | CHUNKING | Chunking | MAY | [CHUNKING] | 513 | 8BITMIME | Use 8-bit data | SHOULD | [RFC6152] | 514 | AUTH | Authentication | MUST | [SMTP-AUTH] | 515 | STARTTLS | Start TLS | MAY | [Start-TLS] | 516 | NO-SOLICITING | Notification of | MAY | [RFC3865] | 517 | | no soliciting | | | 518 | MTRK | Message Tracking | MAY | [Msg-Track] | 519 | ATRN | On-Demand Relay | MUST NOT | [RFC2645] | 520 | DELIVERBY | Deliver By | MAY | [RFC2852] | 521 | CONPERM | Content | MAY | [RFC4141] | 522 | | Conversion | | | 523 | | Permission | | | 524 | CONNEG | Content | MAY | [RFC4141] | 525 | | Conversion | | | 526 | | Negotiation | | | 527 +------------------+------------------+-----------+-----------------+ 529 Table 1 531 Future SMTP extensions SHOULD explicitly specify if they are valid on 532 the Submission port. 534 Some SMTP extensions are especially useful for message submission: 536 Extended Status Codes [SMTP-CODES] SHOULD be supported and used 537 according to [CODES-EXTENSION]. This permits the MSA to notify the 538 client of specific configuration or other problems in more detail 539 than the response codes listed in this memo. Because some rejections 540 are related to a site's security policy, care should be used not to 541 expose more detail to unauthenticated senders than is needed 543 [PIPELINING] SHOULD be supported by the MSA. 545 [SMTP-AUTH] allows the MSA to validate the authority and determine 546 the identity of the submitting user and MUST be supported by the MSA. 548 [Start-TLS] is the most widely used mechanism at the time this is 549 written that allows the MUA and MSA to protect message submission 550 integrity and privacy. 552 Any references to the DATA command in this memo also refer to any 553 substitutes for DATA, such as the BDAT command used with [CHUNKING]. 555 8. Message Modifications 557 Sites MAY modify submissions to ensure compliance with standards and 558 site policy. This section describes a number of such modifications 559 that are often considered useful. 561 NOTE: As a matter of guidance for local decisions to implement 562 message modification, a paramount rule is to limit such actions to 563 remedies for specific problems that have clear solutions. This is 564 especially true with address elements. For example, indiscriminately 565 appending a domain to an address or element that lacks one typically 566 results in more broken addresses. An unqualified address must be 567 verified to be a valid local part in the domain before the domain can 568 be safely added. 570 Any message forwarded or delivered by the MSA MUST conform to the 571 requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements 572 permited by extensions that are supported by the MSA and accepted by 573 the next-hop server. 575 Message modification can affect the validity of an existing message 576 signature, such as by DKIM [DKIM], PGP [RFC4880], or S/MIME 577 [RFC5751], and can render the signature invalid. This, in turn, can 578 affect message handling by later receivers, such as filtering engines 579 that consider the presence or absence of a valid signature. 581 8.1. Add 'Sender' 583 The MSA MAY add or replace the 'Sender' field, if the identity of the 584 sender is known and this is not given in the 'From' field. 586 The MSA MUST ensure that any address it places in a 'Sender' field is 587 in fact a valid mail address. 589 8.2. Add 'Date' 591 The MSA MAY add a 'Date' field to the submitted message, if it lacks 592 it, or correct the 'Date' field if it does not conform to 593 [MESSAGE-FORMAT] syntax. 595 8.3. Add 'Message-ID' 597 The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it, 598 or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note 599 that a number of clients still do not generate Message-ID fields. 601 8.4. Transfer Encode 603 The MSA MAY apply transfer encoding to the message according to MIME 604 conventions, if needed and not harmful to the MIME type. 606 8.5. Sign the Message 608 The MSA MAY (digitally) sign or otherwise add authentication 609 information to the message. 611 8.6. Encrypt the Message 613 The MSA MAY encrypt the message for transport to reflect 614 organizational policies. 616 NOTE: To be useful, the addition of a signature and/or encryption by 617 the MSA generally implies that the connection between the MUA and MSA 618 must itself be secured in some other way, for example, by operating 619 inside of a secure environment, by securing the submission connection 620 at the transport layer, or by using an [SMTP-AUTH] mechanism that 621 provides for session integrity. 623 8.7. Resolve Aliases 625 The MSA MAY resolve and rewrite aliases (e.g., CNAME records) for 626 domain names, in the SMTP envelope and/or in address fields of the 627 header, subject to local policy. 629 NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in 630 addresses and the session-opening announcement. As with other SMTP 631 requirements, RFC 5321 effectively prohibits an MSA from forwarding 632 such messages into the public Internet. Nonetheless, unconditionally 633 resolving aliases could be harmful. For example, if www.example.net 634 and ftp.example.net are both aliases for mail.example.net, rewriting 635 them could lose useful information. 637 8.8. Header Rewriting 639 The MSA MAY rewrite local parts and/or domains in the SMTP envelope, 640 and optionally in address fields of the header, according to local 641 policy. For example, a site may prefer to rewrite 'JRU' as 642 'J.Random.User' in order to hide login names, and/or to rewrite 643 'squeaky.sales.example.net' as 'zyx.example.net' to hide machine 644 names and make it easier to move users. 646 However, only addresses, local-parts, or domains which match specific 647 local MSA configuration settings should be altered. It would be very 648 dangerous for the MSA to apply data-independent rewriting rules, such 649 as always deleting the first element of a domain name. So, for 650 example, a rule that strips the left-most element of the domain, if 651 the complete domain matches '*.foo.example.net', would be acceptable. 653 The MSA MUST NOT rewrite a forward-pointing (destination) address in 654 a way that violates the constraints of [SMTP-MTA] on modifications of 655 local-parts. Addressing and encoding changes carried out in 656 conjunction with the action of Section 6.5 do not violate this 657 principle if the MSA has sufficient information available to 658 successfully and accurately apply the substitution. 660 9. Security Considerations 662 Separation of submission and relay of messages allows a site to 663 implement different policies for the two types of services, including 664 requiring use of additional security mechanisms for one or both. It 665 can do this in a way which is simpler, both technically and 666 administratively. This increases the likelihood that policies will 667 be applied correctly. 669 Separation also can aid in tracking and preventing unsolicited bulk 670 email. 672 For example, a site could configure its mail servers such that the 673 MSA requires authentication before accepting a message, and the MTA 674 rejects all RCPT commands for non-local users. This can be an 675 important element in a site's total email security policy. 677 If a site fails to require any form of authorization for message 678 submissions (see Section 3.3 for discussion), it is allowing open use 679 of its resources and name; unsolicited bulk email can be injected 680 using its facilities. 682 Section 3 includes further discussion of issues with some 683 authentication methods. 685 Section 5.2 includes a cautionary note that unlimited logging can 686 enable certain forms of denial of service attacks. 688 10. IANA Considerations 690 The entries in Table 1 have been corrected (reference for NO- 691 SOLICITING) and extended (ATRN, DELIVERBY, CONPERM, and CONNEG). The 692 SMTP Service Extensions registry should be updated to reflect the 693 changed and new entries. Entries in the registry that do not appear 694 in the table above are correct and should not be altered. 696 The entry in the SMTP Service Extensions registry for RFC 4409 should 697 be updated to reference this document. The original reference for 698 Submit (RFC 2476), which should have been corrected earlier, should 699 be updated to point to this document. 701 The entry in the Service Name and Transport Protocol Port Number 702 Registry for port 587 should be updated to point to this document. 704 [[anchor29: Note to RFC Editor: please change all instances of 705 "should be updated" above to "has been updated" after the changes are 706 made.]] 708 11. Acknowledgments 710 The preparation and development of the current version of this 711 specification was stimulated by discussions in the IETF YAM and EAI 712 Working Groups. Dave Crocker, Subramanian Moonesamy, Barry Leiba, 713 John Levine, and others provide text that appeared in this document 714 or versions leading up to it. 716 Nathaniel Borenstein and Barry Leiba were instrumental in the 717 development of RFC 4409, the update to RFC 2476. 719 The original memo (RFC 2476) was developed in part based on comments 720 and discussions which took place on and off the IETF-Submit mailing 721 list. The help of those who took the time to review that document 722 and make suggestions is appreciated, especially that of Dave Crocker, 723 Ned Freed, Keith Moore, John Myers, and Chris Newman. 725 Special thanks to Harald Alvestrand, who got this effort started. 727 12. References 729 12.1. Normative References 731 [KEYWORDS] 732 Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", RFC 2119, BCP 14, March 1997. 735 [SMTP-AUTH] 736 Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 737 Extension for Authentication", RFC 4954, July 2007. 739 [SMTP-MTA] 740 Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 741 October 2008. 743 An update to RFC 5321 is in progress. This document 744 should be checked just before publication to be sure that 745 references are up-to-date and/or this comment is modified 746 as needed. If the update is issued at Full Standard, the 747 reference to RFC 5321 should also be removed from the RFC 748 4897 statement in Appendix B. 750 12.2. Informative References 752 [CHECKPOINT] 753 Crocker, D., Freed, N., and Cargille, A., "SMTP Service 754 Extension for Checkpoint/Restart", RFC 1845, 755 September 1995. 757 [CHUNKING] 758 Vaudreuil, G,., "SMTP Service Extensions for Transmission 759 of Large and Binary MIME Messages", RFC 3030, 760 December 2000. 762 [CODES-EXTENSION] 763 Freed, N., "SMTP Service Extension for Returning Enhanced 764 Error Codes", RFC 2034, October 1996. 766 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 767 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 768 Signatures", RFC 4871, May 2007. 770 [[RFC Editor: Please change to reference the RFC 771 associated with draft-ietf-dkim-rfc4871bis if it is 772 published before this or consult with editors, WG Chairs, 773 and AD. Neither a hold nor a "work in progress" reference 774 are needed here.]] 776 [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 777 Extension for Delivery Status Notifications (DSNs)", 778 RFC 3461. 780 [ETRN] De Winter, J., "SMTP Service Extension for Remote Message 781 Queue Starting", RFC 1985, August 1996. 783 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 784 4rev1", RFC 3501, March 2003. 786 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 787 Internet Protocol", RFC 4301, December 2005. 789 [MESSAGE-FORMAT] 790 ResnicK, P., Ed., "Internet Message Format", RFC 5322, 791 October 2008. 793 An update to RFC 5322 is in progress. This document 794 should be checked just before publication to be sure that 795 references are up-to-date and/or this comment is modified 796 as needed. 798 [Msg-Track] 799 Allman, E. and T. Hansen, "SMTP Service Extension for 800 Message Tracking", RFC 3885, September 2004. 802 [PIPELINING] 803 Freed, N., "SMTP Service Extension for Command 804 Pipelining", RFC 2920, STD 60, September 2000. 806 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 807 RFC 1939, May 1996. 809 [REPLY-521] 810 Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, 811 September 1995. 813 [RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with 814 Dynamic IP Addresses", RFC 2645, August 1999. 816 [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, 817 June 2000. 819 [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer 820 Protocol (SMTP) Service Extension", RFC 3865, 821 September 2004. 823 [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for 824 Content Conversion", RFC 4141, November 2005. 826 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 827 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 829 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 830 Mail Extensions (S/MIME) Version 3.2 Message 831 Specification", RFC 5751, January 2010. 833 [RFC6152] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 834 Crocker, "SMTP Service Extension for 8-bit MIME 835 transport", RFC 6152, March 2011. 837 [SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service 838 Extension for Message Size Declaration", RFC 1870, STD 10, 839 November 1995. 841 [SMTP-CODES] 842 Vaudreuil, G,., "Enhanced Mail System Status Codes", 843 RFC 3463, January 2003. 845 [Start-TLS] 846 Hoffman, P,., "SMTP Service Extension for Secure SMTP over 847 Transport Layer Security", RFC 3207, February 2002. 849 Appendix A. Major Changes from RFC 4409 851 The protocol specified by this document is not substantively 852 different from that of RFC 4409. However, the present specification 853 contains several clarifications and updates to reflect changes and 854 revisions to other documents subsequent to the publication of RFC 855 4409. The following specific changes may be of interest to some 856 readers. 858 o Updated several references to reflect more recent versions of the 859 various specifications. As part of this, reclassified RFC 4954 to 860 a normative reference (SMTP AUTH is a MUST for 4409 and this 861 specification). 863 o Updated the text in Section 7 to reflect the existence and partial 864 population of the registry and the included table (Table 1) to 865 correct one entry and add others. See Section 10 for more 866 information. 868 o Added new text (Section 5.3 to clarify that Submission Servers 869 should respond quickly. 871 o Added text to make it explicit that character encoding changes are 872 permitted. 874 o Added text to make it clear that modifications to signed messages 875 may cause problems and that they should be carefully considered. 877 Appendix B. Note on References 879 RFCs 4954, 5321, and 5322 are not Full Standards, so their use in 880 citations from this document are downward references (even though the 881 reference to RFC 5322 is a non-normative one). The protocols that 882 they describe are widely-deployed, interoperable, stable, and 883 successful, so the references are justified. 885 Appendix C. Change Log 887 RFC Editor: Please remove this Section 889 C.1. Changes between RFC 4409 and version-00 of this document 891 This subsection identifies changes from RFC 4409 to the first posted 892 version of this document that are of an editorial or procedural 893 nature insufficient to justify inclusion in Appendix A or that may 894 need clarification for the WG. 896 o Changed reference identifiers in 4409 that started with numbers to 897 other forms. Xml2rfc doesn't like leading numbers. 899 o Added an RFC 4897 downgrade statement as an appendix just in case 900 this goes through on a three-step standards process. 902 o Started on upgrade of Acknowledgments section. 904 o Added clarifying language to the first part and last paragraph of 905 Section 8 to be sure that no one thinks the use of an MSA prevents 906 the use of SMTP extensions that extend various permitted 907 properties of messages, or that address rewriting to make message 908 syntax conform to RFC 5321 (or whatever is permitted at the next 909 hop) is prohibited. 911 C.2. Changes between version -00 and version -01 913 o Modified Section 8.7 to reflect an issue with aliases discussed on 914 the YAM list. 916 Editor's note: A perfect solution to the alias issue in this 917 document would require complete clarity about what the alias 918 prohibition of RFC 5321 means, especially for a few edge cases. 919 Lest we end up with inconsistencies down the line, that is really 920 an issue for RFC 5321bis, not this specification. The new text at 921 least makes it clear that 5321 is the authority. 923 o Fixed a typographical error in the contact information. 925 C.3. Changes between version -01 and version -02 927 o Several small editorial and style corrections. 929 o Explicit notes to RFC Editor about formatting of the table and 930 updating the DKIM references. 932 o Added a note about Start TLS per posting from Chris Newman. 934 o New text about timeouts as discussed in the WG meeting at IETF 81. 936 C.4. Changes between version -02 and version -03 938 Version -03 was posted to address changes requested by IESG members 939 during their review after IETF Last Call. 941 o Modified the RFC 4897 statement (xref target="Stmt4897"/>) to 942 note, for the benefit of those who haven't actually read all of 943 the provisions of RFC 4897, that 5322 is only informative in this 944 document. Also modified the Appendix to make it more suitable for 945 publication. 947 o Removed a citation of SMTP from the Abstract and added it to the 948 Introduction. 950 o An annotation about a possible revision in progress has been added 951 to the reference for RFC 5321. This is similar to the earlier one 952 associated with RFC 5322 except that the one for 5321 also 953 contains instructions to update the 4897 list (Appendix B). 955 o Rewritten, more precise, IANA Considerations section inserted, 956 replacing most of the old one. 958 o Removed a useless explanation from Section 2.2. 960 o Replaced the "digital signature" text in Section 8. 962 o Tuned acknowlegments. 964 Authors' Addresses 966 Randall Gellens 967 QUALCOMM Incorporated 968 5775 Morehouse Drive 969 San Diego, CA 92121-2779 970 USA 972 Email: rg+ietf@qualcomm.com 974 John C Klensin 975 1770 Massachusetts Ave, #322 976 Cambridge, MA 02140 977 USA 979 Phone: +1 617 491 5735 980 Email: john-ietf@jck.com