idnits 2.17.1 draft-gellens-submit-bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 766. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 752), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([SMTP-MTA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2476, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2005) is 6974 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) == Missing Reference: 'Checkpoint' is mentioned on line 442, but not defined == Unused Reference: 'ABNF' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'CHECKPOINT' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'HEADERS' is defined on line 659, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP-MTA') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 1652 (ref. '8BITMIME') (Obsoleted by RFC 6152) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2554 (ref. 'SMTP-AUTH') (Obsoleted by RFC 4954) Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Message Submission for Mail R. Gellens 3 Document: draft-gellens-submit-bis-02.txt QUALCOMM 4 Expires: September 2005 J. Klensin 5 Obsoletes: RFC 2476 March 2005 7 Message Submission for Mail 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed 13 and any of which I become aware will be disclosed, in accordance 14 with RFC 3668 (BCP 79). 16 By submitting this Internet-Draft, I accept the provisions of 17 Section 3 of RFC 3667 (BCP 78). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt The list of 31 Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Comments: 36 Public comments should be sent to the IETF Submit mailing list, 37 . To subscribe, send a message containing 38 SUBSCRIBE to . This list will remain 39 active after publication. Private comments may be sent to the 40 authors. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). All Rights Reserved. 46 Abstract 48 This memo splits message submission from message relay, allowing 49 each service to operate according to its own rules (for security, 50 policy, etc.), and specifies what actions are to be taken by a 51 submission server. 53 Message relay is unaffected, and continues to use SMTP [SMTP-MTA] 54 over port 25. 56 When conforming to this document, message submission uses the 57 protocol specified here, normally over port 587. 59 This separation of function offers a number of benefits, including 60 the ability to apply specific security or policy requirements. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Document Information . . . . . . . . . . . . . . . . . . . 5 66 2.1. Definitions of Terms Used in this Memo . . . . . . . . . 5 67 2.2. Conventions Used in this Document . . . . . . . . . . . 5 68 3. Message Submission . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Submission Identification . . . . . . . . . . . . . . . 6 70 3.2. Message Rejection and Bouncing . . . . . . . . . . . . . 6 71 3.3. Authorized Submission . . . . . . . . . . . . . . . . . 7 72 4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . 8 73 4.1. General Submission Rejection Code . . . . . . . . . . . 8 74 4.2. Ensure All Domains are Fully-Qualified . . . . . . . . . 8 75 4.3. Require Authentication . . . . . . . . . . . . . . . . 8 76 5. Recommended Actions . . . . . . . . . . . . . . . . . . . . 9 77 5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . 9 78 5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Optional Actions . . . . . . . . . . . . . . . . . . . . . 9 80 6.1. Enforce Submission Rights . . . . . . . . . . . . . . . 9 81 6.2. Enforce Permissions . . . . . . . . . . . . . . . . . . 10 82 6.3. Check Message Data . . . . . . . . . . . . . . . . . . . 10 83 6.4 Support for the Postmaster Address . . . . . . . . . . . 10 84 7. Interaction with SMTP Extensions . . . . . . . . . . . . . . 10 85 8. Message Modifications . . . . . . . . . . . . . . . . . . . 12 86 8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 12 87 8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . 12 88 8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 12 89 8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . 12 90 8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . 13 91 8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . 13 92 8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . 13 93 8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . 13 94 9. Security Considerations . . . . . . . . . . . . . . . . . . 14 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 97 12. Normative References . . . . . . . . . . . . . . . . . . . 15 98 13. Informative References . . . . . . . . . . . . . . . . . . . 15 99 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17 100 Appendix A: Changes from RFC 2476 . . . . . . . . . . . . . . 17 101 Intellectual Property Statement . . . . . . . . . . . . . . . 17 102 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 103 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 18 105 1. Introduction 106 SMTP was defined as a message *transfer* protocol, that is, a means 107 to route (if needed) and deliver finished (complete) messages. 109 Message Transfer Agents (MTAs) are not supposed to alter the message 110 text, except to add 'Received', 'Return-Path', and other header 111 fields as required by [SMTP-MTA]. 113 However, SMTP is now also widely used as a message *submission* 114 protocol, that is, a means for message user agents (MUAs) to 115 introduce new messages into the MTA routing network. The process 116 which accepts message submissions from MUAs is termed a Message 117 Submission Agent (MSA). 119 In order to permit unconstrained communications, SMTP is not often 120 authenticated during message relay. 122 Authentication and authorization of initial submissions has become 123 increasingly important, driven by changes in security requirements 124 and rising expectations that submission servers take responsibility 125 for the message traffic they originate. For example, many sites now 126 prohibit outbound port 25 traffic, funneling all mail submissions 127 through submission servers, due to the prevalence of machines that 128 have worms, viruses, or other malicious software which generate 129 large amounts of spam. 131 In addition to authentication and authorization issues, messages 132 being submitted are in some cases finished (complete) messages, and 133 in other cases are unfinished (incomplete) in one or more aspects. 134 Unfinished messages may need to be completed to ensure they conform 135 to [MESSAGE-FORMAT], and later requirements. For example, the 136 message may lack a proper 'Date' header field, and domains might not 137 be fully qualified. In some cases, the MUA may be unable to 138 generate finished messages (for example, it might not know its time 139 zone). Even when submitted messages are complete, local site policy 140 may dictate that the message text be examined or modified in some 141 way. Such completions or modifications have been shown to cause 142 harm when performed by downstream MTAs -- that is, MTAs after the 143 first-hop submission MTA -- and are in general considered to be 144 outside the province of standardized MTA functionality. 146 Separating messages into submissions and transfers allows developers 147 and network administrators to more easily: 149 * Implement security policies and guard against unauthorized mail 150 relaying or injection of unsolicited bulk mail 152 * Implement authenticated submission, including off-site 153 submission by authorized users such as travelers 155 * Separate the relevant software code differences, thereby making 156 each code base more straightforward and allowing for 157 different programs for relay and submission 159 * Detect configuration problems with a site's mail clients 161 * Provide a basis for adding enhanced submission services in the 162 future 164 This memo describes a low cost, deterministic means for messages to 165 be identified as submissions, and specifies what actions are to be 166 taken by a submission server. 168 2. Document Information 170 2.1. Definitions of Terms Used in this Memo 172 Fully-Qualified 174 Containing or consisting of a domain which can be globally resolved 175 using the global Domain Name Service; that is, not a local alias or 176 partial specification. 178 Message Submission Agent (MSA) 180 A process which conforms to this specification. An MSA acts as a 181 submission server to accept messages from MUAs, and either delivers 182 them or acts as an SMTP client to relay them to an MTA. 184 Message Transfer Agent (MTA) 186 A process which conforms to [SMTP-MTA]. An MTA acts as an SMTP 187 server to accept messages from an MSA or another MTA, and either 188 delivers them or acts as an SMTP client to relay them to another 189 MTA. 191 Message User Agent (MUA) 193 A process which acts (often on behalf of a user and with a user 194 interface) to compose and submit new messages, and process delivered 195 messages. In what is commonly referred to as a split-MUA model, POP 196 [POP3] or IMAP [IMAP4] is used to access delivered messages while 197 the protocol defined here (or SMTP) is used to submit messages. 199 2.2. Conventions Used in this Document 201 In examples, "C:" is used to indicate lines sent by the client, and 202 "S:" indicates those sent by the server. Line breaks within a 203 command example are for editorial purposes only. 205 Examples use the 'example.net' domain. 207 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 208 in this document are to be interpreted as defined in [KEYWORDS]. 210 3. Message Submission 212 3.1. Submission Identification 214 Port 587 is reserved for email message submission as specified in 215 this document. Messages received on this port are defined to be 216 submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with 217 additional restrictions or allowances as specified here. 219 While most email clients and servers can be configured to use port 220 587 instead of 25, there are cases where this is not possible or 221 convenient. A site MAY choose to use port 25 for message 222 submission, by designating some hosts to be MSAs and others to be 223 MTAs. 225 3.2. Message Rejection and Bouncing 227 MTAs and MSAs MAY implement message rejection rules that rely in 228 part on whether the message is a submission or a relay. 230 For example, some sites might configure their MTAs to reject all 231 RCPT TOs for messages that do not reference local users, and 232 configure their MSA to reject all message submissions that do not 233 come from authorized users, with authorization based either on the 234 submitting endpoint being within a protected IP environment, or 235 authenticated identity. 237 NOTE: It is better to reject a message than to risk sending one 238 that is damaged. This is especially true for problems that are 239 correctable by the MUA, for example, an invalid 'From' field. 241 If an MSA is not able to determine a return path to the submitting 242 user, from a valid MAIL FROM, a valid source IP address, or based on 243 authenticated identity, then the MSA SHOULD immediately reject the 244 message. A message can be immediately rejected by returning a 550 245 code to the MAIL FROM command. 247 Note that a null return path, that is, MAIL FROM:<>, is permitted 248 and MUST NOT in itself be cause for rejecting a message. (MUAs need 249 to generate null return-path messages for a variety of reasons, 250 including disposition notifications.) 252 Except in the case where the MSA is unable to determine a valid 253 return path for the message being submitted, text in this 254 specification which instructs an MSA to issue a rejection code MAY 255 be complied with by accepting the message and subsequently 256 generating a bounce message. (That is, if the MSA is going to reject 257 a message for any reason except being unable to determine a return 258 path, it can optionally do an immediate rejection or accept the 259 message and then mail a bounce.) 261 NOTE: In the normal case of message submission, immediately 262 rejecting the message is preferred, as it gives the user and MUA 263 direct feedback. To properly handle delayed bounces the client MUA 264 needs to maintain a queue of messages it has submitted, and match 265 bounces to them. Note that many contemporary MUAs do not have this 266 capability. 268 3.3. Authorized Submission 270 Numerous methods have been used to ensure that only authorized users 271 are able to submit messages. These methods include authenticated 272 SMTP, IP address restrictions, secure IP, and prior POP 273 authentication. 275 Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It 276 allows the MSA to determine an authorization identity for the 277 message submission, which is not tied to other protocols. 279 IP address restrictions are very widely implemented, but do not 280 allow for travelers and similar situations, and can be easily 281 spoofed unless all transport paths between the MUA and MSA are 282 trustworthy. 284 Secure IP [IPSEC] can also be used, and provides additional benefits 285 of protection against eavesdropping and traffic analysis. 287 Requiring a POP [POP3] authentication (from the same IP address) 288 within some amount of time (for example, 20 minutes) prior to the 289 start of a message submission session has also been used, but this 290 does impose restrictions on clients as well as servers which may 291 cause difficulties. Specifically, the client must do a POP 292 authentication before an SMTP submission session, and not all 293 clients are capable and configured for this. Also, the MSA must 294 coordinate with the POP server, which may be difficult. There is 295 also a window during which an unauthorized user can submit messages 296 and appear to be a previously authorized user. Since it is 297 dependent on the MUA's IP addresses, this technique is substantially 298 as subject to IP address spoofing as validation based on known IP 299 addresses alone (see above). 301 4. Mandatory Actions 303 An MSA MUST do all of the following: 305 4.1. General Submission Rejection Code 307 Unless covered by a more precise response code, response code 554 is 308 to be used to reject a MAIL FROM, RCPT TO, or DATA command that 309 contains something improper. 311 4.2. Ensure All Domains are Fully-Qualified 313 The MSA MUST ensure that all domains in the SMTP envelope are 314 fully-qualified. 316 If the MSA examines or alters the message text in any way, except to 317 add trace header fields [SMTP-MTA], it MUST ensure that all domains 318 in address header fields are fully-qualified. 320 Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA 321 command which contains improper domain references. 323 A frequent local convention is to accept single-level domains (for 324 example, 'sales') and then to expand the reference by adding the 325 remaining portion of the domain name (for example, to 326 'sales.example.net'). Local conventions that permit single-level 327 domains SHOULD reject, rather than expand, incomplete multi-level 328 domains, since such expansion is particularly risky. 330 4.3. Require Authentication 332 The MSA MUST by default issue an error response to the MAIL FROM 333 command if the session has not been authenticated using [SMTP-AUTH], 334 unless it has already independently established authentication or 335 authorization (such as being within a protected subnetwork). 337 Section 3.3 discusses authentication mechanisms. 339 Reply code 530 [SMTP-AUTH] is used for this purpose. 341 5. Recommended Actions 343 The MSA SHOULD do all of the following: 345 5.1. Enforce Address Syntax 347 An MSA SHOULD reject messages with illegal syntax in a sender or 348 recipient SMTP envelope address. 350 If the MSA examines or alters the message text in way, except to add 351 trace header fields, it SHOULD reject messages with illegal address 352 syntax in address header fields. 354 Reply code 501 is to be used to reject a MAIL FROM or RCPT TO 355 command that contains a detectably improper address. 357 When addresses are resolved after submission of the message body, 358 reply code 554 (with a suitable enhanced status code from 359 [SMTP-CODES]) is used after end-of-data, if the message contains 360 invalid addresses in the header. 362 5.2. Log Errors 364 The MSA SHOULD log message errors, especially apparent 365 misconfigurations of client software. 367 It can be very helpful to notify the administrator when problems are 368 detected with local mail clients. This is another advantage of 369 distinguishing submission from relay: system administrators might be 370 interested in local configuration problems, but not in client 371 problems at other sites. 373 Note that it is important to impose limits on such logging to 374 prevent certain forms of DOS attacks. 376 6. Optional Actions 378 The MSA MAY do any of the following: 380 6.1. Enforce Submission Rights 382 The MSA MAY issue an error response to the MAIL FROM command if the 383 address in MAIL FROM appears to have insufficient submission rights, 384 or is not authorized with the authentication used (if the session 385 has been authenticated). 387 Reply code 550 with an appropriate enhanced status code per 388 [SMTP-CODES], such as 5.7.1, is used for this purpose. 390 6.2. Enforce Permissions 392 The MSA MAY issue an error response to the RCPT TO command if 393 inconsistent with the permissions given to the user (if the session 394 has been authenticated). 396 Reply code 550 with an appropriate enhanced status code per 397 [SMTP-CODES], such as 5.7.1, is used for this purpose. 399 6.3. Check Message Data 401 The MSA MAY issue an error response to the DATA command or send a 402 failure result after end-of-data if the submitted message is 403 syntactically invalid, or seems inconsistent with permissions given 404 to the user (if known), or violates site policy in some way. 406 Reply code 554 is used for syntactic problems in the data. Reply 407 code 501 is used if the command itself is not syntactically valid. 408 Reply code 550 with an appropriate enhanced status code per 409 [SMTP-CODES] (such as 5.7.1) is used to reject based on the 410 submitting user. Reply code 550 with an appropriate enhanced status 411 code (such as 5.7.0) is used if the message violates site policy. 413 6.4 Support for the Postmaster Address 415 If appropriate under local conditions and to facilitate conformance 416 with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit 417 a reduced degree of authentication for mail addressed to the 418 "postmaster" (or one of its alternate spelling forms, see 419 [SMTP-MTA]), in one or more domains, as compared to requirements 420 enforced for other addresses. Among other benefits, this provides 421 an address of last resort that can be used by authorized users to 422 report problems that otherwise prevent them from submitting mail. 424 7. Interaction with SMTP Extensions 426 The following table lists the current standards-track and 427 Experimental SMTP extensions. Listed are the EHLO keyword, name, an 428 indication as to the use of the extension on the submit port, and a 429 reference: 431 Keyword Name Submission Reference 432 ---------- --------------------- ---------- ------------------ 433 PIPELINING Pipelining SHOULD [PIPELINING] 434 ENHANCEDSTATUSCODES 435 Enhanced Status Codes SHOULD [CODES-EXTENSION] 436 ETRN Extended Turn MUST NOT [ETRN] 437 ... Extended Codes SHOULD [SMTP-CODES] 438 DSN Delivery Status Notification 439 SHOULD [DSN] 440 SIZE Message size MAY [SIZE] 441 ... 521 reply code MUST NOT [521REPLY] 442 CHECKPOINT Checkpoint/Restart MAY [Checkpoint] 443 BINARYMIME Binary MIME MAY [CHUNKING] 444 CHUNKING Chunking MAY [CHUNKING] 445 8BITMIME Use 8-bit data SHOULD [8BITMIME] 446 AUTH Authentication MUST [SMTP-AUTH] 447 STARTTLS Start TLS MAY [Start-TLS] 448 NO-SOLICITING 449 Notification of no soliciting 450 MAY [Msg-Track] 451 MTRK Message Tracking MAY [Msg-Track] 453 Future SMTP extensions SHOULD explicitly specify if they are valid 454 on the Submission port. 456 Some SMTP extensions are especially useful for message submission: 458 Extended Status Codes [SMTP-CODES] SHOULD be supported and used 459 according to [CODES-EXTENSION]. This permits the MSA to notify the 460 client of specific configuration or other problems in more detail 461 than the response codes listed in this memo. Because some 462 rejections are related to a site's security policy, care should be 463 used not to expose more detail than is needed to correct the 464 problem. 466 [PIPELINING] SHOULD be supported by the MSA. 468 [SMTP-AUTH] allows the MSA to validate the authority and determine 469 the identity of the submitting user and MUST be supported by the 470 MSA. 472 Any references to the DATA command in this memo also refer to any 473 substitutes for DATA, such as the BDAT command used with [CHUNKING]. 475 8. Message Modifications 477 Sites MAY modify submissions to ensure compliance with standards and 478 site policy. This section describes a number of such modifications 479 that are often considered useful. 481 NOTE: As a matter of guidance for local decisions to implement 482 message modification, a paramount rule is to limit such actions to 483 remedies for specific problems that have clear solutions. This is 484 especially true with address elements. For example, 485 indiscriminately appending a domain to an address or element which 486 lacks one typically results in more broken addresses. An 487 unqualified address must be verified to be a valid local part in the 488 domain before the domain can be safely added. 490 8.1. Add 'Sender' 492 The MSA MAY add or replace the 'Sender' field, if the identity of 493 the sender is known and this is not given in the 'From' field. 495 The MSA MUST ensure that any address it places in a 'Sender' field 496 is in fact a valid mail address. 498 8.2. Add 'Date' 500 The MSA MAY add a 'Date' field to the submitted message, if it lacks 501 it, or correct the 'Date' field if it does not conform to 502 [MESSAGE-FORMAT] syntax. 504 8.3. Add 'Message-ID' 506 The MSA SHOULD add or replace the 'Message-ID' field, if it lacks 507 it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]). 508 Note that a number of clients still do not generate Message-Id 509 fields. 511 8.4. Transfer Encode 512 The MSA MAY apply transfer encoding to the message according to MIME 513 conventions, if needed and not harmful to the MIME type. 515 8.5. Sign the Message 517 The MSA MAY (digitally) sign or otherwise add authentication 518 information to the message. 520 8.6. Encrypt the Message 522 The MSA MAY encrypt the message for transport to reflect 523 organizational policies. 525 NOTE: To be useful, the addition of a signature and/or encryption 526 by the MSA generally implies that the connection between the MUA and 527 MSA must itself be secured in some other way, e.g., by operating 528 inside of a secure environment, by securing the submission 529 connection at the transport layer, or by using an [SMTP-AUTH] 530 mechanism that provides for session integrity. 532 8.7. Resolve Aliases 534 The MSA MAY resolve aliases (CNAME records) for domain names, in the 535 SMTP envelope and optionally in address fields of the header, 536 subject to local policy. 538 NOTE: Unconditionally resolving aliases could be harmful. For 539 example, if www.example.net and ftp.example.net are both aliases for 540 mail.example.net, rewriting them could lose useful information. 542 8.8. Header Rewriting 544 The MSA MAY rewrite local parts and/or domains in the SMTP envelope, 545 and optionally in address fields of the header, according to local 546 policy. For example, a site may prefer to rewrite 'JRU' as 547 'J.Random.User' in order to hide login names, and/or to rewrite 548 'squeaky.sales.example.net' as 'zyx.example.net' to hide machine 549 names and make it easier to move users. 551 However, only addresses, local-parts, or domains which match 552 specific local MSA configuration settings should be altered. It 553 would be very dangerous for the MSA to apply data-independent 554 rewriting rules, such as always deleting the first element of a 555 domain name. So, for example, a rule which strips the left-most 556 element of the domain if the complete domain matches 557 '*.foo.example.net' would be acceptable. 559 9. Security Considerations 561 Separation of submission and relay of messages can allow a site to 562 implement different policies for the two types of services, 563 including requiring use of additional security mechanisms for one or 564 both. It can do this in a way which is simpler, both technically 565 and administratively. This increases the likelihood that policies 566 will be applied correctly. 568 Separation also can aid in tracking and preventing unsolicited bulk 569 email. 571 For example, a site could configure its mail servers such that the 572 MSA requires authentication before accepting a message, and the MTA 573 rejects all RCPT TOs for non-local users. This can be an important 574 element in a site's total email security policy. 576 If a site fails to require any form of authorization for message 577 submissions (see section 3.3 for discussion), it is allowing open 578 use of its resources and name; unsolicited bulk email can be 579 injected using its facilities. 581 Section 3 includes further discussion of issues with some 582 authentication methods. 584 Section 5.2 includes a cautionary note that unlimited logging can 585 enable certain forms of denial of service attacks. 587 10. IANA Considerations 589 The registration for port 587 should be updated to refer to this 590 memo rather than RFC 2476. 592 11. Acknowledgments 594 Nathaniel Borenstein and Barry Leiba were instrumental in the 595 development of this update to RFC 2476. 597 The original memo (RFC 2476) was developed in part based on comments 598 and discussions which took place on and off the IETF-Submit mailing 599 list. The help of those who took the time to review that draft and 600 make suggestions is appreciated, especially that of Dave Crocker, 601 Ned Freed, Keith Moore, John Myers, and Chris Newman. 603 Special thanks to Harald Alvestrand, who got this effort started. 605 12. Normative References 607 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 608 Specifications: ABNF", November 1997, RFC 2234, 609 611 [ESMTP] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker, 612 "SMTP Service Extensions", November 1995, STD 10, RFC 1869, 613 615 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 616 Requirement Levels", March 1997, BCP 14, RFC 2119, 617 619 [SMTP-MTA] J. Postel, "Simple Mail Transfer Protocol", August 1982, 620 STD 10, RFC 821, ; C. 621 Partridge, "Mail Routing and the Domain System", January 1986, STD 622 14, RFC 974, ; R. Braden, 623 Editor, "Requirements for Internet Hosts -- Application and 624 Support", October 1989, STD 3, RFC 1123, 625 ; note that an updated 626 document which unifies and clarifies material has been published as: 627 J. Klensin, "Simple Mail Transfer Protocol", April 2001, RFC 2821, 628 630 13. Informative References 632 [521REPLY] A. Durand, and F. Dupont, "SMTP 521 Reply Code", 633 September 1995, 635 [8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. 636 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", July 1994, 637 639 [CHECKPOINT] D. Crocker, N. Freed, and A. Cargille, "SMTP Service 640 Extension for Checkpoint/Restart, September 1995, RFC 1845, 641 643 [CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission 644 of Large and Binary MIME Messages", December 2000, RFC 3030, 645 647 [CODES-EXTENSION] N. Freed, "SMTP Service Extension for Returning 648 Enhanced Error Codes", October 1996, RFC 2034, 649 651 [DSN] K. Moore, "Simple Mail Transfer Protocol (SMTP) Service 652 Extension for Delivery Status Notifications (DSNs)", January 2003, 653 RFC 3461, 655 [ETRN] J. De Winter, "SMTP Service Extension for Remote Message 656 Queue Starting", August 1996, RFC 1985, 657 659 [HEADERS] J. Palme, "Common Internet Message Headers", February 660 1997, RFC 2076, 662 [IMAP4] M. Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 663 4rev1", March 2003, RFC 3501, 664 666 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the 667 Internet Protocol", November 1998, RFC 2401, 668 670 [MESSAGE-FORMAT] D. Crocker, "Standard for the format of ARPA 671 Internet text messages", August 1982, STD 11, RFC 822, 672 ; R. Braden, Editor, 673 "Requirements for Internet Hosts -- Application and Support", 674 October 1989, STD 3, RFC 1123, 675 677 [Msg-Track] E. Allman, T. Hansen, "SMTP Service Extension for 678 Message Tracking", September 2004, RFC 3885, 679 681 [PIPELINING] N. Freed, "SMTP Service Extension for Command 682 Pipelining", September 2000, RFC 2920, STD 60, 683 685 [POP3] J. Myers, M. Rose, "Post Office Protocol -- Version 3", STD 686 53, May 1996, RFC 1939, 688 [SIZE] J. Klensin, N. Freed, and K. Moore, "SMTP Service Extension 689 for Message Size Declaration, November 1995, RFC 1870, STD 10, 690 692 [SMTP-AUTH] J. Myers, "SMTP Service Extension for Authentication", 693 March 1999, RFC 2554, 695 [SMTP-CODES] G. Vaudreuil, "Enhanced Mail System Status Codes", 696 January 2003, RFC 3463, 698 [Start-TLS] P. Hoffman, "SMTP Service Extension for Secure SMTP over 699 Transport Layer Security", February 2002, RFC 3207, 700 702 14. Authors' Addresses 704 Randall Gellens 705 QUALCOMM Incorporated 706 6455 Lusk Blvd. 707 San Diego, CA 92121-2779 708 USA 709 randy@qualcomm.Com 711 John C. Klensin 712 1770 Massachusetts Ave, #322 713 Cambridge, MA 02140 714 USA 715 john+ietf@jck.com 717 Appendix A: Changes from RFC 2476 719 o Support for [SMTP-AUTH] is now mandatory 720 o Message-ID changed from MAY to SHOULD 721 o Added NO-SOLICITING and MTRK (RFC 3885) to list of SMTP 722 extensions 723 o Deleted normative use of specific enhanced status codes, to 724 avoid conflicting with [SMTP-CODES] 725 o Section 4.2 text no longer in a note 726 o Fixed a few typographical errors 728 Intellectual Property Statement 730 The IETF takes no position regarding the validity or scope of any 731 intellectual property or other rights that might be claimed to 732 pertain to the implementation or use of the technology described in 733 this document or the extent to which any license under such rights 734 might or might not be available; neither does it represent that it 735 has made any effort to identify any such rights. Information on the 736 IETF's procedures with respect to rights in standards-track and 737 standards-related documentation can be found in BCP-11. Copies of 738 claims of rights made available for publication and any assurances 739 of licenses to be made available, or the result of an attempt made 740 to obtain a general license or permission for the use of such 741 proprietary rights by implementors or users of this specification 742 can be obtained from the IETF Secretariat. 744 The IETF invites any interested party to bring to its attention any 745 copyrights, patents or patent applications, or other proprietary 746 rights which may cover technology that may be required to practice 747 this standard. Please address the information to the IETF Executive 748 Director. 750 Full Copyright Statement 752 Copyright (C) The Internet Society (2005). 754 This document is subject to the rights, licenses and restrictions 755 contained in BCP 78, and except as set forth therein, the authors 756 retain all their rights. 758 Disclaimer 760 This document and the information contained herein are provided on 761 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 762 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 763 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 764 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 765 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 766 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.