idnits 2.17.1 draft-gellens-submit-12.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([MESSAGE-FORMAT], [SMTP-MTA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (4 September 1998) is 9360 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 421, but not defined == Unused Reference: 'ABNF' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'CHECKPOINT' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'HEADERS' is defined on line 609, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1846 (ref. '521REPLY') ** Obsolete normative reference: RFC 1652 (ref. '8BITMIME') (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Experimental RFC: RFC 1845 (ref. 'CHECKPOINT') ** Obsolete normative reference: RFC 1830 (ref. 'CHUNKING') (Obsoleted by RFC 3030) ** Obsolete normative reference: RFC 1891 (ref. 'DSN') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) ** Downref: Normative reference to an Informational RFC: RFC 2076 (ref. 'HEADERS') ** Obsolete normative reference: RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 2197 (ref. 'PIPELINING') (Obsoleted by RFC 2920) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMTP-AUTH' ** Obsolete normative reference: RFC 1893 (ref. 'SMTP-CODES') (Obsoleted by RFC 3463) -- Duplicate reference: RFC1123, mentioned in 'SMTP-MTA', was also mentioned in 'MESSAGE-FORMAT'. Summary: 23 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Message Submission R. Gellens 3 Document: draft-gellens-submit-12.txt QUALCOMM 4 Expires: 4 March 1999 J. Klensin 5 MCI 6 4 September 1998 8 Message Submission 10 Status of this Memo: 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 "working draft" or "work in progress." 23 To learn the current status of any Internet Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet Drafts shadow 25 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Comments: 31 Public comments should be sent to the IETF Submit mailing list, 32 . To subscribe, send a message containing 33 SUBSCRIBE to . This list will remain 34 active after publication. Private comments may be sent to the 35 authors. 37 Copyright Notice 39 Copyright (C) The Internet Society 1998. All Rights Reserved. 41 Gellens & Klensin Expires March 1999 [Page 42 1998 44 Table of Contents 46 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 2. Document Information . . . . . . . . . . . . . . . . . . . 3 48 2.1. Definitions of Terms Used in this Memo . . . . . . . . . 3 49 2.2. Conventions Used in this Document . . . . . . . . . . . 4 50 3. Message Submission . . . . . . . . . . . . . . . . . . . . . 4 51 3.1. Submission Identification . . . . . . . . . . . . . . . 4 52 3.2. Message Rejection and Bouncing . . . . . . . . . . . . . 4 53 3.3. Authorized Submission . . . . . . . . . . . . . . . . . 5 54 3.4. Enhanced Status Codes . . . . . . . . . . . . . . . . . 6 55 4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. General Submission Rejection Code . . . . . . . . . . . 6 57 4.2. Ensure All Domains are Fully-Qualified . . . . . . . . 6 58 5. Recommended Actions . . . . . . . . . . . . . . . . . . . . 7 59 5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . 7 60 5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Optional Actions . . . . . . . . . . . . . . . . . . . . . 7 62 6.1. Enforce Submission Rights . . . . . . . . . . . . . . . 7 63 6.2. Require Authentication . . . . . . . . . . . . . . . . 8 64 6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . 8 65 6.4. Check Message Data . . . . . . . . . . . . . . . . . . 8 66 7. Interaction with SMTP Extensions . . . . . . . . . . . . . . 8 67 8. Message Modifications . . . . . . . . . . . . . . . . . . . 9 68 8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 10 69 8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . 10 70 8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10 71 8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . 10 72 8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . 10 73 8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . 10 74 8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . 10 75 8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . 11 76 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 12. Full Copyright Statement . . . . . . . . . . . . . . . . . 13 80 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 82 1. Abstract 84 SMTP was defined as a message *transfer* protocol, that is, a means 85 to route (if needed) and deliver finished (complete) messages. 86 Message Transfer Agents (MTAs) are not supposed to alter the message 87 text, except to add 'Received', 'Return-Path', and other header 88 fields as required by [SMTP-MTA]. 90 However, SMTP is now also widely used as a message *submission* 91 protocol, that is, a means for message user agents (MUAs) to 92 introduce new messages into the MTA routing network. The process 93 which accepts message submissions from MUAs is termed a Message 94 Submission Agent (MSA). 96 Gellens & Klensin Expires March 1999 [Page 97 1998 99 Messages being submitted are in some cases finished (complete) 100 messages, and in other cases are unfinished (incomplete) in some 101 aspect or other. Unfinished messages need to be completed to ensure 102 they conform to [MESSAGE-FORMAT], and later requirements. For 103 example, the message may lack a proper 'Date' header field, and 104 domains might not be fully qualified. In some cases, the MUA may be 105 unable to generate finished messages (for example, it might not know 106 its time zone). Even when submitted messages are complete, local 107 site policy may dictate that the message text be examined or 108 modified in some way. Such completions or modifications have been 109 shown to cause harm when performed by downstream MTAs -- that is, 110 MTAs after the first-hop submission MTA -- and are in general 111 considered to be outside the province of standardized MTA 112 functionality. 114 Separating messages into submissions and transfers allows developers 115 and network administrators to more easily: 117 * Implement security policies and guard against unauthorized mail 118 relaying or injection of unsolicited bulk mail 120 * Implement authenticated submission, including off-site 121 submission by authorized users such as travelers 123 * Separate the relevant software code differences, thereby making 124 each code base more straightforward and allowing for 125 different programs for relay and submission 127 * Detect configuration problems with a site's mail clients 129 * Provide a basis for adding enhanced submission services in the 130 future 132 This memo describes a low cost, deterministic means for messages to 133 be identified as submissions, and specifies what actions are to be 134 taken by a submission server. 136 2. Document Information 138 2.1. Definitions of Terms Used in this Memo 140 Fully-Qualified 142 Containing or consisting of a domain which can be globally resolved 143 using the global Domain Name Service; that is, not a local alias or 144 partial specification. 146 Message Submission Agent (MSA) 148 A process which conforms to this specification, which acts as a 149 submission server to accept messages from MUAs, and either delivers 151 Gellens & Klensin Expires March 1999 [Page 152 1998 154 them or acts as an SMTP client to relay them to an MTA. 156 Message Transfer Agent (MTA) 158 A process which conforms to [SMTP-MTA], which acts as an SMTP server 159 to accept messages from an MSA or another MTA, and either delivers 160 them or acts as an SMTP client to relay them to another MTA. 162 Message User Agent (MUA) 164 A process which acts (usually on behalf of a user) to compose and 165 submit new messages, and process delivered messages. In the 166 split-MUA model, POP or IMAP is used to access delivered messages. 168 2.2. Conventions Used in this Document 170 In examples, "C:" is used to indicate lines sent by the client, and 171 "S:" indicates those sent by the server. Line breaks within a 172 command example are for editorial purposes only. 174 All example domains use "gork" as the top-level domain. 176 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 177 in this document are to be interpreted as defined in [KEYWORDS]. 179 3. Message Submission 181 3.1. Submission Identification 183 Port 587 is reserved for email message submission as specified in 184 this document. Messages received on this port are defined to be 185 submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with 186 additional restrictions as specified here. 188 While most email clients and servers can be configured to use port 189 587 instead of 25, there are cases where this is not possible or 190 convenient. A site MAY choose to use port 25 for message 191 submission, by designating some hosts to be MSAs and others to be 192 MTAs. 194 3.2. Message Rejection and Bouncing 196 MTAs and MSAs MAY implement message rejection rules that rely in 197 part on whether the message is a submission or a relay. 199 For example, some sites might configure their MTA to reject all RCPT 200 TOs for messages that do not reference local users, and configure 201 their MSA to reject all message submissions that do not come from 202 authorized users, based on IP address, or authenticated identity. 204 Gellens & Klensin Expires March 1999 [Page 205 1998 207 NOTE: It is better to reject a message than to risk sending one 208 that is damaged. This is especially true for problems that are 209 correctable by the MUA, for example, an invalid 'From' field. 211 If an MSA is not able to determine a return path to the submitting 212 user, from a valid MAIL FROM, a valid source IP address, or based on 213 authenticated identity, then the MSA SHOULD immediately reject the 214 message. A message can be immediately rejected by returning a 550 215 code to the MAIL FROM command. 217 Note that a null return path, that is, MAIL FROM <>, is permitted 218 and MUST be accepted. (MUAs need to generate null return-path 219 messages for a variety of reasons, including disposition 220 notifications.) 222 Except in the case where the MSA is unable to determine a valid 223 return path for the message being submitted, text in this 224 specification which instructs an MSA to issue a rejection code MAY 225 be complied with by accepting the message and subsequently 226 generating a bounce message. (That is, if the MSA is going to reject 227 a message for any reason except being unable to determine a return 228 path, it can optionally do an immediate rejection or accept the 229 message and then mail a bounce.) 231 NOTE: In the normal case of message submission, immediately 232 rejecting the message is preferred, as it gives the user and MUA 233 direct feedback. To properly handle delayed bounces the client MUA 234 must maintain a queue of messages it has submitted, and match 235 bounces to them. 237 3.3. Authorized Submission 239 Numerous methods have been used to ensure that only authorized users 240 are able to submit messages. These methods include authenticated 241 SMTP, IP address restrictions, secure IP, and prior POP 242 authentication. 244 Authenticated SMTP [SMTP-AUTH] SHOULD be supported. It allows the 245 MSA to determine an authorization identity for the message 246 submission, which is not tied to other protocols. 248 IP address restrictions are very widely implemented, but do not 249 allow for travellers and similar situations, and can be spoofed. 251 Secure IP [IPSEC] can also be used, and provides additional benefits 252 of protection against eavesdropping and traffic analysis. 254 Requiring a POP [POP3] authentication (from the same IP address) 255 within some amount of time (for example, 20 minutes) prior to the 256 start of a message submission session has also been used, but this 257 does impose restrictions on clients as well as servers which may 259 Gellens & Klensin Expires March 1999 [Page 260 1998 262 cause difficulties. Specifically, the client must do a POP 263 authentication before an SMTP submission session, and not all 264 clients are capable and configured for this. Also, the MSA must 265 coordinate with the POP server, which may be difficult. There is 266 also a window during which an unauthorized user can submit messages 267 and appear to be a prior authorized user. 269 3.4. Enhanced Status Codes 271 This memo suggests several enhanced status codes [SMTP-CODES] for 272 submission-specific rejections. The specific codes used are: 274 5.6.0 Bad content. The content of the header or text is improper. 276 5.6.2 Bad domain or address. Invalid or improper domain or address 277 in MAIL FROM, RCPT TO, or DATA. 279 5.7.1 Not allowed. The address in MAIL FROM appears to have 280 insufficient submission rights, or is invalid, or is not 281 authorized with the authentication used; the address in a 282 RCPT TO command is inconsistent with the permissions given 283 to the user; the message data is rejected based on the 284 submitting user. 286 5.7.0 Site policy. The message appears to violate site policy in 287 some way. 289 4. Mandatory Actions 291 An MSA MUST do all of the following: 293 4.1. General Submission Rejection Code 295 Unless covered by a more precise response code, response code 554 is 296 to be used to reject a MAIL FROM, RCPT TO, or DATA command that 297 contains something improper. Enhanced status code 5.6.0 is to be 298 used if no other code is more specific. 300 4.2. Ensure All Domains are Fully-Qualified 302 The MSA MUST ensure that all domains in the envelope are 303 fully-qualified. 305 If the MSA examines or alters the message text in way, except to add 306 trace header fields [SMTP-MTA], it MUST ensure that all domains in 307 address header fields are fully-qualified. 309 Gellens & Klensin Expires March 1999 [Page 310 1998 312 Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA 313 command which contains improper domain references. 315 NOTE: A frequent local convention is to accept single-level domains 316 (for example, 'sales') and then to expand the reference by adding 317 the remaining portion of the domain name (for example, to 318 'sales.foo.gork'). Local conventions that permit single-level 319 domains SHOULD reject, rather than expand, incomplete multi-level 320 domains, since such expansion is particularly risky. 322 5. Recommended Actions 324 The MSA SHOULD do all of the following: 326 5.1. Enforce Address Syntax 328 An MSA SHOULD reject messages with illegal syntax in a sender or 329 recipient envelope address. 331 If the MSA examines or alters the message text in way, except to add 332 trace header fields, it SHOULD reject messages with illegal address 333 syntax in address header fields. 335 Reply code 501 is to be used to reject a MAIL FROM or RCPT TO 336 command that contains a detectably improper address. 338 When addresses are resolved after submission of the message body, 339 reply code 554 with enhanced status code 5.6.2 is to be used after 340 end-of-data, if the message contains invalid addresses in the 341 header. 343 5.2. Log Errors 345 The MSA SHOULD log message errors, especially apparent 346 misconfigurations of client software. 348 Note: It can be very helpful to notify the administrator when 349 problems are detected with local mail clients. This is another 350 advantage of distinguishing submission from relay: system 351 administrators might be interested in local configuration problems, 352 but not in client problems at other sites. 354 6. Optional Actions 356 The MSA MAY do any of the following: 358 Gellens & Klensin Expires March 1999 [Page 359 1998 361 6.1. Enforce Submission Rights 363 The MSA MAY issue an error response to the MAIL FROM command if the 364 address in MAIL FROM appears to have insufficient submission rights, 365 or is not authorized with the authentication used (if the session 366 has been authenticated). 368 Reply code 550 with enhanced status code 5.7.1 is used for this 369 purpose. 371 6.2. Require Authentication 373 The MSA MAY issue an error response to the MAIL FROM command if the 374 session has not been authenticated. 376 Section 3.3 discusses authentication mechanisms. 378 Reply code 530 [SMTP-AUTH] is used for this purpose. 380 6.3. Enforce Permissions 382 The MSA MAY issue an error response to the RCPT TO command if 383 inconsistent with the permissions given to the user (if the session 384 has been authenticated). 386 Reply code 550 with enhanced status code 5.7.1 is used for this 387 purpose. 389 6.4. Check Message Data 391 The MSA MAY issue an error response to the DATA command or send a 392 failure result after end-of-data if the submitted message is 393 syntactically invalid, or seems inconsistent with permissions given 394 to the user (if known), or violates site policy in some way. 396 Reply code 554 is used for syntactic problems in the data. Reply 397 code 501 is used if the command itself is not syntactically valid. 398 Reply code 550 with enhanced status code 5.7.1 is used to reject 399 based on the submitting user. Reply code 550 with enhanced status 400 code 5.7.0 is used if the message violates site policy. 402 7. Interaction with SMTP Extensions 404 The following table lists the current standards-track and 405 Experimental SMTP extensions. Listed are the RFC, name, status, an 406 indication as to the extension's use on the submit port, and a 407 reference: 409 Gellens & Klensin Expires March 1999 [Page 410 1998 412 RFC Name Status Submission Reference 413 ---- --------------- ------ ---------- ------------------ 414 2197 Pipelining DS SHOULD [PIPELINING] 415 2034 Error Codes PS SHOULD [CODES-EXTENSION] 416 1985 ETRN PS MUST NOT [ETRN] 417 1893 Extended Codes PS SHOULD [SMTP-CODES] 418 1891 DSN PS SHOULD [DSN] 419 1870 Size S MAY [SIZE] 420 1846 521 E MUST NOT [521REPLY] 421 1845 Checkpoint E MAY [Checkpoint] 422 1830 Binary E MAY [CHUNKING] 423 1652 8-bit MIME DS SHOULD [8BITMIME] 424 ---- Authentication -- SHOULD [SMTP-AUTH] 426 Future SMTP extensions should explicitly specify if they are valid 427 on the Submission port. 429 Some SMTP extensions are especially useful for message submission: 431 Extended Status Codes [SMTP-CODES], SHOULD be supported and used 432 according to [CODES-EXTENSION]. This permits the MSA to notify the 433 client of specific configuration or other problems in more detail 434 than the response codes listed in this memo. Because some 435 rejections are related to a site's security policy, care should be 436 used not to expose more detail than is needed to correct the 437 problem. 439 [PIPELINING] SHOULD be supported by the MSA. 441 [SMTP-AUTH] SHOULD be supported. It allows the MSA to validate the 442 authority and determine the identity of the submitting user. 444 Any references to the DATA command in this memo also refer to any 445 substitutes for DATA, such as the BDAT command used with [CHUNKING]. 447 8. Message Modifications 449 Sites MAY modify submissions to ensure compliance with standards and 450 site policy. This section describes a number of such modifications 451 that are often considered useful. 453 NOTE: As a matter of guidance for local decisions to implement 454 message modification, a paramount rule is to limit such actions to 455 remedies for specific problems that have clear solutions. This is 456 especially true with address elements. For example, 457 indiscriminately appending a domain to an address or element which 458 lacks one typically results in more broken addresses. An 459 unqualified address must be verified to be a valid local part in the 460 domain before the domain can be safely added. 462 Gellens & Klensin Expires March 1999 [Page 463 1998 465 8.1. Add 'Sender' 467 The MSA MAY add or replace the 'Sender' field, if the identity of 468 the sender is known and this is not given in the 'From' field. 470 The MSA MUST ensure that any address it places in a 'Sender' field 471 is in fact a valid mail address. 473 8.2. Add 'Date' 475 The MSA MAY add a 'Date' field to the submitted message, if it lacks 476 it, or correct the 'Date' field if it does not conform to 477 [MESSAGE-FORMAT] syntax. 479 8.3. Add 'Message-ID' 481 The MSA MAY add or replace the 'Message-ID' field, if it lacks it, 482 or it is not valid syntax (as defined by [MESSAGE-FORMAT]). 484 8.4. Transfer Encode 486 The MSA MAY apply transfer encoding to the message according to MIME 487 conventions, if needed and not harmful to the MIME type. 489 8.5. Sign the Message 491 The MSA MAY (digitally) sign or otherwise add authentication 492 information to the message. 494 8.6. Encrypt the Message 496 The MSA MAY encrypt the message for transport to reflect 497 organizational policies. 499 NOTE: To be useful, the addition of a signature and/or encryption 500 by the MSA generally implies that the connection between the MUA and 501 MSA must itself be secured in some other way, e.g., by operating 502 inside of a secure environment, by securing the submission 503 connection at the transport layer, or by using an [SMTP-AUTH] 504 mechanism that provides for session integrity. 506 8.7. Resolve Aliases 508 The MSA MAY resolve aliases (CNAME records) for domain names, in the 509 envelope and optionally in address fields of the header, subject to 510 local policy. 512 Gellens & Klensin Expires March 1999 [Page 513 1998 515 NOTE: Unconditionally resolving aliases could be harmful. For 516 example, if www.ab.gork and ftp.ab.gork are both aliases for 517 mail.ab.gork, rewriting them could lose useful information. 519 8.8. Header Rewriting 521 The MSA MAY rewrite local parts and/or domains, in the envelope and 522 optionally in address fields of the header, according to local 523 policy. For example, a site may prefer to rewrite 'JRU' as 524 'J.Random.User' in order to hide logon names, and/or to rewrite 525 'squeeky.sales.xyz.gork' as 'zyx.gork' to hide machine names and 526 make it easier to move users. 528 However, only addresses, local-parts, or domains which match 529 specific local MSA configuration settings should be altered. It 530 would be very dangerous for the MSA to apply data-independent 531 rewriting rules, such as always deleting the first element of a 532 domain name. So, for example, a rule which strips the left-most 533 element of the domain if the complete domain matches 534 '*.foo.bar.gork' would be acceptable. 536 9. Security Considerations 538 Separation of submission and relay of messages can allow a site to 539 implement different policies for the two types of services, 540 including requiring use of additional security mechanisms for one or 541 both. It can do this in a way which is simpler, both technically 542 and administratively. This increases the likelihood that policies 543 will be applied correctly. 545 Separation also can aid in tracking and preventing unsolicited bulk 546 email. 548 For example, a site could configure its MSA to require 549 authentication before accepting a message, and could configure its 550 MTA to reject all RCPT TOs for non-local users. This can be an 551 important element in a site's total email security policy. 553 If a site fails to require any form of authorization for message 554 submissions (see section 3.3 for discussion), it is allowing open 555 use of its resources and name; unsolicited bulk email can be 556 injected using its facilities. 558 10. Acknowledgments 560 This updated draft has been revised in part based on comments and 561 discussions which took place on and off the IETF-Submit mailing 562 list. The help of those who took the time to review the draft and 563 make suggestions is appreciated, especially that of Dave Crocker, 565 Gellens & Klensin Expires March 1999 [Page 566 1998 568 Ned Freed, Keith Moore, John Myers, and Chris Newman. 570 Special thanks to Harald Alvestrand, who got this effort started. 572 11. References 574 [521REPLY] A. Durand, and F. Dupont, "SMTP 521 Reply Code", 575 September 1995, 577 [8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. 578 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", July 1994, 579 581 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 582 Specifications: ABNF", November 1997, 583 585 [CHECKPOINT] D. Crocker, N. Freed, and A. Cargille, "SMTP Service 586 Extension for Checkpoint/Restart, September 1995, 587 589 [CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission 590 of Large and Binary MIME Messages", August 1995, 591 593 [CODES-EXTENSION] N. Freed, "SMTP Service Extension for Returning 594 Enhanced Error Codes", RFC 2034, October 1996, 595 597 [DSN] K. Moore, "SMTP Service Extension for Delivery Status 598 Notifications, January 1996, 599 601 [ESMTP] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker, 602 "SMTP Service Extensions", STD 10, RFC 1869, November 1995, 603 605 [ETRN] J. De Winter, "SMTP Service Extension for Remote Message 606 Queue Starting", August 1996, 607 609 [HEADERS] J. Palme, "Common Internet Message Headers", RFC 2076, 610 February 1997, 612 [IPSEC] R. Atkinson, "Security Architecture for the Internet 613 Protocol", RFC 1825, August 1995, 614 616 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997, 618 620 Gellens & Klensin Expires March 1999 [Page 621 1998 623 [MESSAGE-FORMAT] D. Crocker, "Standard for the format of ARPA 624 Internet text messages", STD 11, RFC 822, August 1982, 625 ; R. Braden, Editor, 626 "Requirements for Internet Hosts -- Application and Support", STD 3, 627 RFC 1123, October 1989, 629 [PIPELINING] N. Freed, "SMTP Service Extension for Command 630 Pipelining", RFC 2197, September 1997, 631 633 [POP3] J. Myers, M. Rose, "Post Office Protocol -- Version 3", STD 634 53, RFC 1939, May 1996, 636 [SIZE] J. Klensin, N. Freed, and K. Moore, "SMTP Service Extension 637 for Message Size Declaration, November 1995, 638 640 [SMTP-AUTH] J. Myers, "SMTP Service Extension for Authentication", 641 work in progress, 642 644 [SMTP-CODES] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 645 1893, January 1996, 647 [SMTP-MTA] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 648 821, August 1982, ; C. 649 Partridge, "Mail Routing and the Domain System", STD 14, RFC 974, 650 January 1986, ; R. Braden, 651 Editor, "Requirements for Internet Hosts -- Application and 652 Support", STD 3, RFC 1123, October 1989, 653 655 12. Full Copyright Statement 657 Copyright (C) The Internet Society 1998. All Rights Reserved. 659 This document and translations of it may be copied and furnished to 660 others, and derivative works that comment on or otherwise explain it 661 or assist in its implementation may be prepared, copied, published 662 and distributed, in whole or in part, without restriction of any 663 kind, provided that the above copyright notice and this paragraph 664 are included on all such copies and derivative works. However, this 665 document itself may not be modified in any way, such as by removing 666 the copyright notice or references to the Internet Society or other 667 Internet organizations, except as needed for the purpose of 668 developing Internet standards in which case the procedures for 669 copyrights defined in the Internet Standards process must be 670 followed, or as required to translate it into languages other than 671 English. 673 Gellens & Klensin Expires March 1999 [Page 674 1998 676 The limited permissions granted above are perpetual and will not be 677 revoked by the Internet Society or its successors or assigns. 679 This document and the information contained herein is provided on an 680 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 681 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 682 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 683 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 684 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 686 13. Authors' Addresses 688 Randall Gellens +1 619 651 5115 689 QUALCOMM Incorporated +1 619 651 5334 (fax) 690 6455 Lusk Blvd. Randy@Qualcomm.Com 691 San Diego, CA 92121-2779 692 U.S.A. 694 John C. Klensin +1 617 960 1011 695 MCI Telecommunications klensin@mci.net 696 800 Boylston St, 7th floor 697 Boston, MA 02199 698 USA