idnits 2.17.1 draft-crocker-email-arch-11.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.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2167. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2180. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 411 has weird spacing: '...lly has the s...' == Line 564 has weird spacing: '...cerning exter...' == Line 584 has weird spacing: '...raction highl...' == Line 957 has weird spacing: '... script going...' == Line 991 has weird spacing: '...uctured compo...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (October 31, 2008) is 5655 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 normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2304 (ref. 'RFC3192') (Obsoleted by RFC 3192) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 4550 (Obsoleted by RFC 5550) -- Obsolete informational reference (is this intentional?): RFC 821 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2554 (Obsoleted by RFC 4954) -- Obsolete informational reference (is this intentional?): RFC 3685 (Obsoleted by RFC 5235) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SMTP D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Standards Track October 31, 2008 5 Expires: May 4, 2009 7 Internet Mail Architecture 8 draft-crocker-email-arch-11 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 4, 2009. 35 Abstract 37 Over its thirty-five year history, Internet Mail has changed 38 significantly in scale and complexity, as it has become a global 39 infrastructure service. These changes have been evolutionary, rather 40 than revolutionary, reflecting a strong desire to preserve both its 41 installed base and its usefulness. To collaborate productively on 42 this large and complex system, all participants must work from a 43 common view of it and use a common language to describe its 44 components and the interactions among them. But the many differences 45 in perspective currently make it difficult to know exactly what 46 another participant means. To serve as the necessary common frame of 47 reference, this document describes the enhanced Internet Mail 48 architecture, reflecting the current service. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Document Conventions . . . . . . . . . . . . . . . . . . . 6 55 2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 7 56 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.2. Mail Handling Service (MHS) Actors . . . . . . . . . . . . 10 58 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 13 59 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 16 61 3.2. Scope of Email Address Use . . . . . . . . . . . . . . . . 17 62 3.3. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 17 63 3.4. Message Identifier . . . . . . . . . . . . . . . . . . . . 18 64 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 19 65 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 22 66 4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 27 67 4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 29 68 4.4. Transition Modes . . . . . . . . . . . . . . . . . . . . . 33 69 4.5. Implementation and Operation . . . . . . . . . . . . . . . 33 70 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 34 71 5.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . . . 35 72 5.2. ReSender . . . . . . . . . . . . . . . . . . . . . . . . . 36 73 5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 37 74 5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 39 75 5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 40 76 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 40 77 6.1. Security Considerations . . . . . . . . . . . . . . . . . 40 78 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 41 79 6.3. Internationalization . . . . . . . . . . . . . . . . . . . 41 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 81 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 42 82 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 44 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 45 84 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48 86 Intellectual Property and Copyright Statements . . . . . . . . . . 49 88 1. Introduction 90 Over its thirty-five year history, Internet Mail has changed 91 significantly in scale and complexity, as it has become a global 92 infrastructure service. These changes have been evolutionary, rather 93 than revolutionary, reflecting a strong desire to preserve both its 94 installed base and its usefulness. Today, Internet Mail is 95 distinguished by many independent operators, many different 96 components for providing service to users, as well as many different 97 components that transfer messages. 99 Public collaboration on technical, operations, and policy activities 100 of email, including those that respond to the challenges of email 101 abuse, has brought a much wider range of participants into the 102 technical community. To collaborate productively on this large and 103 complex system, all participants must work from a common view of it 104 and use a common language to describe its components and the 105 interactions among them. But the many differences in perspective 106 currently make it difficult to know exactly what another participant 107 means. 109 It is the need to resolve these differences that motivates this 110 document, which describes the realities of the current system. 111 Internet Mail is the subject of ongoing technical, operations, and 112 policy work, and the discussions often are hindered by different 113 models of email service design and different meanings for the same 114 terms. 116 To serve as the necessary common frame of reference, this document 117 describes the enhanced Internet Mail architecture, reflecting the 118 current service. The document focuses on: 120 * Capturing refinements to the email model 122 * Clarifying functional roles for the architectural components 124 * Clarifying identity-related issues, across the email service 126 * Defining terminology for architectural components and their 127 interactions 129 1.1. History 131 The first standardized architecture for networked email specified a 132 simple split between the user world, in the form of Mail User Agents 133 (MUA), and the transfer world, in the form of the Mail Handling 134 Service (MHS), which is composed of Mail Transfer Agents (MTA). The 135 MHS accepts a message from one User and delivers it to one or more 136 other users, creating a virtual MUA-to-MUA exchange environment. 138 As shown in Figure 1, this defines two logical layers of 139 interoperability. One is directly between Users. The other is among 140 the components along the transfer path. In addition, there is 141 interoperability between the layers, first when a message is posted 142 from the User to the MHS and later when it is delivered from the MHS 143 to the User. 145 The operational service has evolved, although core aspects of the 146 service, such as mailbox addressing and message format style, 147 remaining remarkably constant. The original distinction between the 148 user level and transfer level remains, but with elaborations in each. 149 The term "Internet Mail" is used to refer to the entire collection of 150 user and transfer components and services. 152 For Internet Mail, the term "end-to-end" usually refers to a single 153 posting and the set of deliveries that result from a single transit 154 of the MHS. A common exception is group dialogue that is mediated, 155 through a Mailing List; in this case, two postings occur before 156 intended Recipients receive an Author's message, as discussed in 157 Section 2.1.3. In fact, some uses of email consider the entire email 158 service, including Author and Recipient, as a subordinate component. 159 For these services, "end-to-end" refers to points outside the email 160 service. Examples are voicemail over email "[RFC3801], EDI over 161 email [RFC1767] and facsimile over email [RFC4142]. 163 +--------+ 164 ++================>| User | 165 || +--------+ 166 || ^ 167 +--------+ || +--------+ . 168 | User +==++=========>| User | . 169 +---+----+ || +--------+ . 170 . || ^ . 171 . || +--------+ . . 172 . ++==>| User | . . 173 . +--------+ . . 174 . ^ . . 175 . . . . 176 V . . . 177 +---+-----------------+------+------+---+ 178 | . . . . | 179 | .................>. . . | 180 | . . . | 181 | ........................>. . | 182 | . . | 183 | ...............................>. | 184 | | 185 | Mail Handling Service (MHS) | 186 +---------------------------------------+ 188 Figure 1: Basic Internet Mail Service Model 190 End-to-end Internet Mail exchange is accomplished by using a 191 standardized infrastructure with these components and 192 characteristics: 194 * An email object 196 * Global addressing 198 * An asynchronous sequence of point-to-point transfer mechanisms 200 * No prior arrangement between MTAs or between Authors and 201 Recipients 203 * No prior arrangement between point-to-point transfer services 204 over the open Internet 206 * No requirement for Author, Originator, or Recipients to be 207 online at the same time 209 The end-to-end portion of the service is the email object, called a 210 "message." Broadly, the message itself distinguishes control 211 information, for handling, from the Author's content. 213 A precept to the design of mail over the open Internet is permitting 214 user-to-user and MTA-to-MTA interoperability without prior, direct 215 arrangement between the independent administrative authorities 216 responsible for handling a message. All participants rely on having 217 the core services universally supported and accessible, either 218 directly or through Gateways that act as translators between Internet 219 Mail and email environments conforming to other standards. Given the 220 importance of spontaneity and serendipity in interpersonal 221 communications, not requiring such prearrangement between 222 participants is a core benefit of Internet Mail and remains a core 223 requirement for it. 225 Within localized networks at the edge of the public Internet, prior 226 administrative arrangement often is required and can include access 227 control, routing constraints, and configuration of the information 228 query service. Although recipient authentication has usually been 229 required for message access since the beginning of Internet Mail, in 230 recent years it also has been required for message submission. In 231 these cases, a server validates the client's identity, whether by 232 explicit security protocols or by implicit infrastructure queries to 233 identify "local" participants. 235 1.2. Document Conventions 237 References to structured fields of a message use a two-part dotted 238 notation. The first part cites the document that contains the 239 specification for the field and the second is the name of the field. 240 Hence is the From: header field in an email content 241 header and is the address in the SMTP "Mail From" 242 command. 244 When occurring without the RFC2822 qualifier, header field names are 245 shown with a colon suffix. For example, From:. 247 References to labels for actors, functions or components have the 248 first letter capitalized. 250 Also, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 251 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 252 this document are to be interpreted as described in RFC 2119 253 [RFC2119] [RFC2119]. 255 RFC EDITOR: Remove the following paragraph before publication. 257 Discussion venue: Please direct discussion about this document 258 to the IETF-SMTP mailing list . 260 2. Responsible Actor Roles 262 Internet Mail is a highly distributed service, with a variety of 263 actors playing different roles. These actors fall into three basic 264 types: 266 * User 268 * Mail Handling Service (MHS) 270 * ADministrative Management Domain (ADMD) 272 Although related to a technical architecture, the focus on actors 273 concerns participant responsibilities, rather than functionality of 274 modules. For that reason, the labels used are different from those 275 used in classic email architecture diagrams. 277 2.1. User Actors 279 Users are the sources and sinks of messages. Users can be people, 280 organizations, or processes. They can have an exchange that 281 iterates, and they can expand or contract the set of users that 282 participate in a set of exchanges. In Internet Mail, there are four 283 types of Users: 285 * Authors 287 * Recipients 289 * Return Handlers 291 * Mediators 293 Figure 2 shows the primary and secondary flows of messages among 294 them. 296 ++==========++ 297 || Author ||<..................................<.. 298 ++=++=++=++=++ . 299 || || || ++===========++ . 300 || || ++====>|| Recipient || . 301 || || ++=====+=====++ . 302 || || . . 303 || || ..........................>.+ 304 || || . 305 || || ................... . 306 || || . . . 307 || || V . . 308 || || +-----------+ ++=====+=====++ . 309 || ++========>| Mediator +===>|| Recipient || . 310 || +-----+-----+ ++=====+=====++ . 311 || . . . 312 || ..................+.......>.+ 313 || . 314 || ..............+.................. . 315 || . . . . 316 \/ V V ' . 317 +-----------+ +-----------+ ++=====+=====++ . 318 | Mediator +===>| Mediator +===>|| Recipient || . 319 +-----+-----+ +-----+-----+ ++=====+=====++ . 320 . . . . 321 .................+.................+.......>.. 323 Figure 2: Relationships Among User Actors 325 From the user perspective, all mail transfer activities are performed 326 by a monolithic Mail Handling Service (MHS), even though the actual 327 service can be provided by many independent organizations. Users are 328 customers of this unified service. 330 Whenever any MHS actor sends information to back to an Author or 331 Originator in the sequence of handling a message, that actor is a 332 User. 334 2.1.1. Author 336 The Author is responsible for creating the message, its contents, and 337 its list of recipient addresses. The MHS transfers the message from 338 the Author and delivers it to the Recipients. The MHS has an 339 Originator role (Section 2.2.1) that correlates with the Author role. 341 2.1.2. Recipient 343 The Recipient is a consumer of the delivered message. The MHS has a 344 Receiver role (Section 2.2.4)correlates with the Recipient role. 345 This is labeled Recv in Figure 3. 347 Any Recipient can close the user communication loop by creating and 348 submitting a new message that replies to the Author. An example of 349 an automated form of reply is the Message Disposition Notification 350 (MDN), which informs the Author about the Recipient's handling of the 351 message. (See Section 4.1.) 353 The Return Handler, also called "Bounce Handler," receives and 354 services notifications that the MHS generates, as it transfers or 355 delivers the message. These notices can be about failures or 356 completions and are sent to an address that is specified by the 357 Originator<> . This Return handling address (also known 358 as a Return address) might have no visible characteristics in common 359 with the address of the Author or Originator. 361 2.1.3. Mediator 363 A Mediator receives, aggregates, reformulates, and redistributes 364 messages among Authors and Recipients who are the principals in 365 protracted exchanges. This activity is easily confused with the 366 underlying MHS transfer exchanges. However, each serves very 367 different purposes and operates in very different ways. 369 When mail is delivered to the Mediator specified in the 370 RFC2821.RcptTo command, the MHS handles it the same way as for any 371 other Recipient. The MHS sees each posting and delivery activity 372 between sources and sinks as independent; it does not see subsequent 373 re-posting as a continuation of a process. Because the Mediator 374 originates messages, it can receive replies. Hence, when submitting 375 messages, the Mediator is an Author. So a Mediator really is a full- 376 fledged User. Mediators are considered extensively in Section 5. 378 The distinctive aspects of a Mediator are outside the MHS. A 379 Mediator preserves the Author information of the message it 380 reformulates and is permitted to make meaningful changes to the 381 message content or envelope. The MHS sees a new message, but users 382 receive a message that they interpret as being from, or at least 383 initiated by, the Author of the original message. The role of a 384 Mediator is not limited to merely connecting other participants; the 385 Mediator is responsible for the new message. 387 A Mediator's role is complex and contingent, for example, modifying 388 and adding content or regulating which users are allowed to 389 participate and when. The common example of this role is a group 390 Mailing List. In a more complex use, a sequence of Mediators could 391 perform a sequence of formal steps, such as reviewing, modifying, and 392 approving a purchase request. 394 A Gateway is a particularly interesting form of Mediator. It is a 395 hybrid of User and Relay that connects heterogeneous mail services. 396 Its purpose is to emulate a Relay. For a detailed discussion, see 397 Section 2.2.3. . 399 2.2. Mail Handling Service (MHS) Actors 401 The Mail Handling Service (MHS) performs a single end-to-end transfer 402 on behalf of the Author to reach the Recipient addresses specified in 403 the original RFC2821.RcptTo commands. Exchanges that are either 404 mediated or iterative and protracted, such as those used for 405 collaboration over time are handled by the User actors, not by the 406 MHS actors. 408 Figure 3 shows the relationships among transfer participants in 409 Internet Mail. Although it shows the Originator (labeled Origin) as 410 distinct from the Author and Receiver (labeled Recv) as distinct from 411 Recipient, each pair of roles usually has the same actor. 412 Transfers typically entail one or more Relays. However direct 413 delivery from the Originator to Receiver is possible. Intra- 414 organization mail services usually have only one Relay. 416 ++==========++ ++===========++ 417 || Author || || Recipient || 418 ++====++====++ +--------+ ++===========++ 419 || | Return | /\ 420 || +-+------+ || 421 \/ . ^ || 422 +---------+ . . +---++---+ 423 | | . . | | 424 //==+=========+============================+========+===\\ 425 || | | . . MHS | | || 426 || | Origin +<...... .................+ Recv | || 427 | | ^ | | 428 +---++----+ . +--------+ 429 || . /\ 430 || ..............+.................. || 431 \/ . . . || 432 +-------+-+ +--+------+ +-+--++---+ 433 | Relay +=======>| Relay +=======>| Relay | 434 +---------+ +----++---+ +---------+ 435 || 436 || 437 \/ 438 +---------+ 439 | Gateway +-->... 440 +---------+ 442 Figure 3: Relationships Among MHS Actors 444 2.2.1. Originator 446 The Originator ensures that a message is valid for posting and then 447 submits it to a Relay. A message is valid if it conforms to both 448 Internet Mail standards and local operational policies. The 449 Originator can simply review the message for conformance and reject 450 it if it finds errors, or it can create some or all of the necessary 451 information. In effect, the Originator is responsible for the 452 functions of the Mail Submission Agent. 454 The Originator operates with dual allegiance. It serves the Author 455 and can be the same entity. But its role in assuring validity means 456 that it MUST also represent the local operator of the MHS, that is, 457 the local ADministrative Management Domain (ADMD). 459 The Originator also performs any post-submission, Author-related 460 administrative tasks associated with message transfer and delivery. 461 Notably, these tasks pertain to sending error and delivery notices, 462 enforcing local policies, and dealing with messages from the Author 463 that prove to be problematic for the Internet. The Originator is 464 accountable for the message content, even when it is not responsible 465 for it. The Author creates the message, but the Originator handles 466 any transmission issues with it. 468 2.2.2. Relay 470 The Relay performs MHS-level transfer-service routing and store-and- 471 forward, by transmitting or retransmitting the message to its 472 Recipients. The Relay adds trace information [RFC2505] but does not 473 modify the envelope information or the message content semantics. It 474 can modify message content representation, such as changing the form 475 of transfer encoding from binary to text, but only as required to 476 meet the capabilities of the next hop in the MHS. 478 A Mail Handling Service (MHS) network consists of a set of Relays. 479 This network is above any underlying packet-switching network that 480 might be used and below any Gateways or other Mediators. 482 In other words, email scenarios can involve three distinct 483 architectural layers, each providing its own type of data of store- 484 and-forward service: 486 * User Mediators 488 * MHS Relays 490 * Packet Switches 492 The bottom layer is the Internet's IP service. The most basic email 493 scenarios involve Relays and Switches. 495 Aborting a message transfer makes the Relay an Author because it must 496 send an error message to the Return address. The potential for 497 looping is avoided by omitting a Return address from this message. 499 2.2.3. Gateway 501 A Gateway is a hybrid of User and Relay that connects heterogeneous 502 mail services. Its purpose is to emulate a Relay and the closer it 503 comes to this, the better. A Gateway operates as a User when it 504 needs the ability to modify message content. 506 Differences between mail services can be as small as minor syntax 507 variations, but they usually encompass significant, semantic 508 distinctions. One difference could be email addresses that are 509 hierarchical and machine-specific rather than a flat, global 510 namespace. Another difference could be support for text-only content 511 or multi-media. Hence the Relay function in a Gateway presents a 512 significant design challenge, if the resulting performance is to be 513 seen as nearly seamless. The challenge is to ensure user-to-user 514 functionality between the services, despite differences in their 515 syntax and semantics. 517 The basic test of Gateway design is whether an Author on one side of 518 a Gateway can send a useful message to a Recipient on the other side, 519 without requiring changes to any components in the Author's or 520 Recipient's mail services other than adding the Gateway. To each of 521 these otherwise independent services, the Gateway appears to be a 522 native participant. But the ultimate test of Gateway design is 523 whether the Author and Recipient can sustain a dialogue. In 524 particular, can a Recipient's MUA automatically formulate a valid 525 Reply that will reach the Author? 527 2.2.4. Receiver 529 The Receiver performs final delivery or sends the message to an 530 alternate address. It can also perform filtering and other policy 531 enforcement immediately before or after delivery. 533 2.3. Administrative Actors 535 Administrative actors can be associated with different organizations, 536 each with its own administrative authority. This operational 537 independence, coupled with the need for interaction between groups, 538 provides the motivation to distinguish among ADministrative 539 Management Domains (ADMDs ). Each ADMD can have vastly different 540 operating policies and trust-based decision-making. One obvious 541 example is the distinction between mail that is exchanged within an 542 organization and mail that is exchanged between independent 543 organizations. The rules for handling both types of traffic tend to 544 be quite different. That difference requires defining the boundaries 545 of each, and this requires the ADMD construct. 547 Operation of Internet Mail services is carried out by different 548 providers (or operators). Each can be an independent ADMD. This 549 independence of administrative decision-making defines boundaries 550 that distinguish different portions of the Internet Mail service. A 551 department that operates a local Relay, an IT department that 552 operates an enterprise Relay, and an ISP that operates a public 553 shared email service can be configured into many combinations of 554 administrative and operational relationships. Each is a distinct 555 ADMD, potentially having a complex arrangement of functional 556 components. Figure 4 depicts relationships among ADMDs. The benefit 557 of the ADMD construct is to facilitate discussion about designs, 558 policies and operations that need to distinguish between internal 559 issues and external ones. 561 The architectural impact of the need for boundaries between ADMDs is 562 discussed in [Tussle]. Most significant is that the entities 563 communicating across ADMD boundaries typically have the added burden 564 of enforcing organizational policies concerning external 565 communications. At a more mundane level, routing mail between ADMDs 566 can be an issue, such as needing to route mail for partners over 567 specially trusted paths. 569 These are the basic types of ADMDs: 571 Edge: Independent transfer services in networks at the edge of 572 the open Internet Mail service. 574 Consumer: This might be a type of Edge service, as is common 575 for web-based email access. 577 Transit: Mail Service Providers (MSP) that offer value-added 578 capabilities for Edge ADMDs, such as aggregation and filtering. 580 The mail-level transit service is different from packet-level 581 switching. End-to-end packet transfers usually go through 582 intermediate routers; email exchange across the open Internet can be 583 directly between the Boundary MTAs of Edge ADMDs. This distinction 584 between direct and indirect interaction highlights the differences 585 discussed in Section 2.2.2 586 +--------+ +---------+ +-------+ +-----------+ 587 | ADMD1 |<===>| ADMD2 |<===>| ADMD3 |<===>| ADMD4 | 588 | ----- | | ----- | | ----- | | ----- | 589 | | | | | | | | 590 | Author | | | | | | | 591 | . | | | | | | | 592 | V | | | | | | | 593 | Edge..+....>|.Transit.+....>|-Edge..+....>|.Recipient | 594 | | | | | | | | 595 +--------+ +---------+ +-------+ +-----------+ 597 Figure 4: Administrative Domain (ADMD) Example 599 Edge networks can use proprietary email standards internally. 600 However the distinction between Transit network and Edge network 601 transfer services is significant because it highlights the need for 602 concern over interaction and protection between independent 603 administrations. In particular, this distinction calls for 604 additional care in assessing the transitions of responsibility and 605 the accountability and authorization relationships among participants 606 in message transfer. 608 The interactions of ADMD components are subject to the policies of 609 that domain, which cover concerns such as these: 611 * Reliability 613 * Access control 615 * Accountability 617 * Content evaluation and modification 619 These policies can be implemented in different functional components, 620 according to the needs of the ADMD. For example, see [RFC5068]. 622 Consumer, Edge, and Transit services can be offered by providers that 623 operate component services or sets of services. Further, it is 624 possible for one ADMD to host services for other ADMDs. 626 These are common examples of ADMDs: 628 Enterprise Service Providers: 630 These ADMDs operate the internal data and/or the mail services 631 within an organization. 633 Internet Service Providers (ISP): 635 These ADMDs operate the underlying data communication services, 636 which are used by one or more Relay and User. ISPs are not 637 responsible for performing email functions, but they can 638 provide an environment in which those functions can be 639 performed. 641 Mail Service Providers: 643 These ADMDs operate email services, such as for consumers or 644 client companies. 646 Practical operational concerns demand that providers be involved in 647 administration and enforcement issues. This involvement can extend 648 to operators of lower-level packet services. 650 3. Identities 652 Internet Mail uses three forms of identity: mailbox, domain name, and 653 message-ID. Each must be globally unique. 655 3.1. Mailbox 657 "A mailbox sends and receives mail. It is a conceptual entity 658 which does not necessarily pertain to file storage." [RFC2822] 660 A mailbox is specified as an Internet Mail address . It 661 has two distinct parts, separated by an at-sign (@). The right side 662 is a globally interpreted domain name associated with an ADMD. 663 Domain names are discussed in Section 3.3. Formal Internet Mail 664 addressing syntax can support source routes, to indicate the path 665 through which a message ought to be sent. The use of source routes 666 is not common and has been deprecated in [RFC2821]. 668 The portion to the left of the at-sign contains a string that is 669 globally opaque and is called the . It is to be 670 interpreted only by the entity specified by the address's domain 671 name. Except as noted later in this section all other entities MUST 672 treat the as an uninterpreted literal string and MUST 673 preserve all of its original details. As such its public 674 distribution is equivalent to sending a Web browser "cookie" that is 675 only interpreted upon being returned to its creator. 677 Some local-part values have been standardized, for contacting 678 personnel at an organization. These names cover common operations 679 and business functions. [RFC2142] 681 It is common for sites to have local structuring conventions for the 682 left-hand side of an . This permits sub- 683 addressing, such as for distinguishing different discussion groups 684 used by the same participant. However it is worth stressing that 685 these conventions are strictly private to the user's organization and 686 MUST NOT be interpreted by any domain except the one listed in the 687 right side of the . The exceptions are those specialized 688 services that conform to public, standardized conventions, as noted 689 below. 691 A few types of addresses elaborate on basic email addressing, with a 692 standardized, global schema for the , Include are 693 conventions between authoring systems and Gateways. They are 694 invisible to the public email transfer infrastructure. When an 695 Author is explicitly sending through a Gateway out of the Internet, 696 coding conventions for the allow the Author to formulate 697 instructions for the Gateway. Standardized examples of such 698 conventions are the telephone numbering formats for VPIM [RFC3801], 699 such as: 701 +16137637582@vpim.example.com 703 and iFax [RFC3192], such as: 705 FAX=+12027653000/T33S=1387@ifax.example.com 707 3.2. Scope of Email Address Use 709 Email addresses are being used far beyond their original role in 710 email transfer and delivery. In practical terms, an email address 711 string has become the common identifier for representing online 712 identity. Hence, it is essential to be clear about both the nature 713 and role of an identity string in a particular context and the entity 714 responsible for setting that string. For example, see Section 4.1.4, 715 Section 4.3.3 and Section 5. 717 3.3. Domain Names 719 A domain name is a global reference to an Internet resource, such as 720 a host, a service, or a network. A domain name usually maps to one 721 or more IP Addresses. Conceptually, the name can encompass an 722 organization, a collection of machines integrated into a homogeneous 723 service, or a single machine. A domain name can be administered to 724 refer to individual users, but this is not common practice. The name 725 is structured as a hierarchical sequence of names, separated by dots 726 (.), with the top of the hierarchy being on the right end of the 727 sequence. Domain names are defined and operated through the Domain 728 Name System (DNS) [RFC1034], [RFC1035], [RFC2181]. 730 When not part of a mailbox address, a domain name is used in Internet 731 Mail to refer to the ADMD or to the host that took action upon the 732 message, such as providing the administrative scope for a message 733 identifier or performing transfer processing. 735 3.4. Message Identifier 737 There are two standardized tags for identifying messages: Message-ID: 738 and ENVID. A Message-ID: pertains to content, and an ENVID pertains 739 to transfer. 741 3.4.1. Message-ID 743 Internet Mail standards provide for, at most, a single Message-ID:. 744 The Message-ID: for a single message, which is a user-level tag, has 745 a variety of uses including threading, aiding identification of 746 duplicates, and DSN tracking. [RFC2822]. The Originator assigns the 747 Message-ID:. The Recipient's ADMD is the intended consumer of the 748 Message-ID:, although any actor along the transfer path can use it. 750 Message-ID: MUST be globally unique. Its format is similar to that 751 of a mailbox, with two distinct parts, separated by an at-sign (@). 752 Typically, the right side specifies the ADMD or host that assigns the 753 identifier, and the left side contains a string that is globally 754 opaque and serves to uniquely identify the message within the domain 755 referenced on the right side. The duration of uniqueness for the 756 message identifier is undefined. 758 When a message is revised in any way, the decision whether to assign 759 a new Message-ID: requires a subjective assessment to determine 760 whether the editorial content has been changed enough to constitute a 761 new message. [RFC2822] states that "a message identifier pertains to 762 exactly one instantiation of a particular message; subsequent 763 revisions to the message each receive new message identifiers." Yet 764 experience suggests that some flexibility is needed. An impossible 765 test is whether the recipient will consider the new message to be 766 equivalent to the old one. For most components of Internet Mail, 767 there is no way to predict a specific recipient's preferences on this 768 matter. Both creating and failing to create a new Message-ID: have 769 their downsides. 771 Here are some guidelines and examples: 773 * If a message is changed only in form, such as character- 774 encoding, it is still the same message. 776 * If a message has minor additions to the content, such as a 777 mailing list tag at the beginning of the RFC2822.Subject header 778 field, or some mailing list administrative information added to 779 the end of the primary body-part text, it is probably the same 780 message. 782 * If a message has viruses deleted from it, it is probably the 783 same message. 785 * If a message has offensive words deleted from it, some 786 recipients will consider it the same message, but some will 787 not. 789 * If a message is translated into a different language, some 790 recipients will consider it the same message, but some will 791 not. 793 * If a message is included in a digest of messages, the digest 794 constitutes a new message. 796 * If a message is forwarded by a recipient, what is forwarded is 797 a new message. 799 * If a message is "redirected", such as using RFC2822 "Resent-*" 800 header fields, some recipients will consider it the same 801 message, but some will not. 803 The absence of both objective, precise criteria for re-generating a 804 Message-ID: and strong protection associated with the string means 805 that the presence of an ID can permit an assessment that is 806 marginally better than a heuristic, but the ID certainly has no value 807 on its own for strict formal reference or comparison. For that 808 reason, the Message-ID: SHOULD NOT be used for any function that has 809 security implications. 811 3.4.2. ENVID 813 The ENVID (envelope identifier) can be used for message-tracking 814 purposes [RFC3885] concerning a single posting/delivery transfer. 815 The ENVID labels a single transit of the MHS by a specific message. 816 So, the ENVID is used for one message posting, until that message is 817 delivered. A re-posting of the message, such as by a Mediator, does 818 not re-use that ENVID, but can use a new one, even though the message 819 might legitimately retain its original Message-ID:. 821 The format of an ENVID is free form. Although its creator might 822 choose to impose structure on the string, none is imposed by Internet 823 standards. By implication, the scope of the string is defined by the 824 domain name of the Return Address. 826 4. Services and Standards 828 The Internet Mail architecture comprises six basic types of 829 functionality, which are arranged to support a store-and-forward 830 service. As shown in Figure 5, each type can have multiple 831 instances, some of which represent specialized roles. This section 832 considers the activities and relationships among these components, 833 and the Internet Mail standards that apply to them. 835 Message 837 Mail User Agent (MUA) 839 Author MUA (aMUA) 841 Recipient MUA (rMUA) 843 Message Submission Agent (MSA) 845 Author-focused MSA functions (aMSA) 847 MHS-focused MSA functions (hMSA) 849 Message Transfer Agent (MTA) 851 Message Delivery Agent (MDA) 853 Recipient-focused MDA functions (rMDA) 855 MHS-focused MDA functions (hMDA) 857 Message Store (MS) 859 Author MS (aMS) 861 Recipient MS (rMS) 863 This figure shows function modules and the standardized protocols 864 used between them. 866 ++========++ 867 || || +-------+ 868 ...........++ aMUA ||<............................+ Disp | 869 . || || +-------+ 870 . ++=+==+===++ ^ 871 . local,imap}| |{smtp,submission . 872 . +-----+ | | +--------+ . 873 . | aMS |<---+ | ........................>| Return | . 874 . +-----+ | . +--------+ . 875 . | . ***************** ^ . 876 . +-----V-.----*------------+ * . . 877 . MSA | +-------+ * +------+ | * . . 878 . | | aMSA +-(S)->| hMSA | | * . . 879 . | +-------+ * +--+---+ | * . . 880 V +------------*------+-----+ * . . 881 //==========\\ * V {smtp * . . 882 || MESSAGE || * +------+ * //===+===\\ . 883 ||----------|| MHS * | MTA | * || dsn || . 884 || Envelope || * +--+---+ * \\=======// . 885 || SMTP || * V {smtp * ^ ^ . 886 || Content || * +------+ * . . //==+==\\ 887 || RFC2822 || * | MTA +....*...... . || mdn || 888 || MIME || * +--+---+ * . \\=====// 889 \\==========// * smtp}| {local * . ^ 890 . MDA * | {lmtp * . . 891 . +----------------+------V-----+ * . . 892 . | +----------+ * +------+ | * . . 893 . | | | * | | +..*.......... . 894 . | | rMDA |<-(D)--+ hMDA | | * . 895 . | | | * | | |<.*........ . 896 . | +-+------+-+ * +------+ | * . . 897 . +------+---------*------------+ * . . 898 . | ***************** . . 899 . V{smtp,imap,pop,local . . 900 . +-----+ //===+===\\ . 901 . | rMS | || sieve || . 902 . +--+--+ \\=======// . 903 . |{imap,pop,local ^ . 904 . V . . 905 . ++==========++ . . 906 . || || . . 907 .......>|| rMUA ++........................... . 908 || ++................................... 909 ++==========++ 911 Figure 5: Protocols and Services 913 4.1. Message Data 915 The purpose of the Mail Handling Service (MHS) is to exchange a 916 message object among participants [RFC2822], [RFC0822]. All of its 917 underlying mechanisms serve to deliver that message from its Author 918 to its Recipients. A message can be explicitly labeled as to its 919 nature [RFC3458]. 921 A message comprises a transit-handling envelope and the message 922 content. The envelope contains information used by the MHS. The 923 content is divided into a structured header and the body. The header 924 comprises transit handling trace information and structured fields 925 that are part of the Author's message content. The body can be 926 unstructured lines of text or a tree of multi-media subordinate 927 objects, called "body-parts" or attachments [RFC2045], [RFC2046], 928 [RFC2047], [RFC4288], [RFC4289], [RFC2049]. 930 In addition, Internet Mail has a few conventions for special control 931 data, notably: 933 Delivery Status Notification (DSN): 935 A Delivery Status Notification (DSN) is a message that can be 936 generated by the MHS (MSA, MTA, or MDA) and sent to the 937 RFC2821.MailFrom address. An MDA and MTA are shown as sources 938 of DSNs in Figure 5, and the destination is shown as Returns. 939 DSNs provide information about message transit, such as 940 transfer errors or successful delivery. [RFC3461] 942 Message Disposition Notification (MDN): 944 A Message Disposition Notification (MDN) is a message that 945 provides information about post-delivery processing, such as 946 indicating that the message has been displayed [RFC3798] or the 947 form of content that can be supported [RFC3297]. It can be 948 generated by an rMUA and is sent to the Disposition- 949 Notification-To addresses. The mailbox for this is shown as 950 Disp in Figure 5. 952 Message Filtering (SIEVE): 954 Sieve is a scripting language used to specify conditions for 955 differential handling of mail, typically at the time of 956 delivery [RFC5228]. Scripts can be conveyed in a variety of 957 ways, as a MIME part. Figure 5 shows a Sieve script going 958 from the rMUA to the MDA. However, filtering can be done at 959 many different points along the transit path, and any one or 960 more of them might be subject to Sieve directives, especially 961 within a single ADMD. the Figure 5 shows only one relationship, 962 for (relative) simplicity. 964 4.1.1. Envelope 966 Internet Mail has a fragmented framework for transit-related handling 967 information. Information that is used directly by the MHS is called 968 the "envelope." It directs handling activities by the transfer 969 service and is carried in transfer service commands. That is, the 970 envelope exists in the transfer protocol SMTP. [RFC2821] 972 Trace information, such as RFC2822.Received, is recorded in the 973 message header and is not subsequently altered. [RFC2822] 975 4.1.2. Header Fields 977 Header fields are attribute name/value pairs that cover an extensible 978 range of email service parameters, structured user content, and user 979 transaction meta-information. The core set of header fields is 980 defined in [RFC2822], [RFC0822]. It is common practice to extend 981 this set for different applications. Procedures for registering 982 header fields are defined in [RFC3864]. An extensive set of existing 983 header field registrations is provided in [RFC4021]. 985 One danger of placing additional information in header fields is that 986 Gateways often alter or delete them. 988 4.1.3. Body 990 The body of a message might be lines of ASCII text or a 991 hierarchically structured composition of multi-media body-part 992 attachments, using MIME. [RFC2045], [RFC2046], [RFC2047], [RFC4288], 993 [RFC2049] 995 4.1.4. Identity References in a Message 997 Table 1 lists the core identifiers present in a message during 998 transit. 1000 +----------------------+----------------+---------------------------+ 1001 | Layer | Field | Set By | 1002 +----------------------+----------------+---------------------------+ 1003 | Message Body | MIME Header | Author | 1004 | Message header | From: | Author | 1005 | fields | | | 1006 | | Sender: | Originator | 1007 | | Reply-To: | Author | 1008 | | To:, CC:, BCC: | Author | 1009 | | Message-ID: | Originator | 1010 | | Received: | Originator, Relay, | 1011 | | | Receiver | 1012 | | Return-Path: | MDA, from MailFrom | 1013 | | Resent-*: | Mediator | 1014 | | List-Id: | Mediator | 1015 | | List-*: | Mediator | 1016 | SMTP | HELO/EHLO | Latest Relay Client | 1017 | | ENVID | Originator | 1018 | | MailFrom | Originator | 1019 | | RcptTo | Author | 1020 | | ORCPT | Author | 1021 | IP | Source Address | Latest Relay Client | 1022 +----------------------+----------------+---------------------------+ 1024 Table 1: Layered Identities 1026 These are the most common address-related fields: 1028 RFC2822.From: Set by - Author 1030 Names and addresses for authors of the message content are 1031 listed in the From: field. 1033 RFC2822.Reply-To: Set by - Author 1035 If a Recipient sends a reply message that would otherwise use 1036 the RFC2822.From field addresses in the original message, the 1037 addresses in the RFC2822.Reply-To field are used instead. In 1038 other words, this field overrides the From: field for responses 1039 from Recipients. 1041 RFC2822.Sender: Set by - Originator 1042 This field specifies the address responsible for submitting the 1043 message to the transfer service. This field can be omitted if 1044 it contains the same address as RFC2822.From. However, 1045 omitting this field does not mean that no Sender is specified; 1046 it means that that header field is virtual and that the address 1047 in the From: field MUST be used. 1049 Specification of the notifications Return addresses, which are 1050 contained in RFC2821.MailFrom, is made by the RFC2822.Sender. 1051 Typically the Return address is the same as the Sender address. 1052 However, some usage scenarios require it to be different. 1054 RFC2822.To/.CC: Set by - Author 1056 These fields specify MUA Recipient addresses. However, some or 1057 all of the addresses in these fields might not be present in 1058 the RFC2821.RcptTo commands. 1060 The distinction between To and CC is subjective. Generally, a 1061 To addressee is considered primary and is expected to take 1062 action on the message. A CC addressee typically receives a 1063 copy as a courtesy. 1065 RFC2822.BCC: Set by - Author 1067 A copy of the message might be sent to an addressee whose 1068 participation is not to be disclosed to the RFC2822.To or 1069 RFC2822.CC Recipients and, usually, not to the other BCC 1070 Recipients. The BCC: header field indicates a message copy to 1071 such a Recipient. Use of this field is discussed in [RFC2822]. 1073 RFC2821.HELO/.EHLO: Set by - Originator, MSA, MTA 1075 Any SMTP client -- including Originator, MSA, or MTA -- can 1076 specify its hosting domain identity for the SMTP HELO or EHLO 1077 command operation. 1079 RFC3461.ENVID: Set by - Originator 1081 The MSA can specify an opaque string, to be included in a DSN, 1082 as a means of assisting the Return address recipient in 1083 identifying the message that produced a DSN or message 1084 tracking. 1086 RFC2821.MailFrom: Set by - Originator 1087 This field is an end-to-end string that specifies an email 1088 address for receiving return control information, such as 1089 returned messages. The name of this field is misleading, 1090 because it is not required to specify either the Author or the 1091 actor responsible for submitting the message. Rather, the 1092 actor responsible for submission specifies the RFC2821.MailFrom 1093 address. Ultimately, the simple basis for deciding which 1094 address needs to be in the RFC2821.MailFrom field is to 1095 determine which address must be informed about transfer-level 1096 problems (and possibly successes.) 1098 RFC2821.RcptTo: Set by - Author, Final MTA, MDA. 1100 This field specifies the MUA mailbox address of a Recipient. 1101 The string might not be visible in the message content header. 1102 For example, the message destination address header fields, 1103 such as RFC2822.To, might specify a mailing list mailbox, while 1104 the RFC2821.RcptTo address specifies a member of that list. 1106 RFC2821.ORCPT: Set by - Author. 1108 This is an optional parameter to the RCPT command, indicating 1109 the original address to which the current RCPT TO address 1110 corresponds, after a mapping was performed during transit. An 1111 ORCPT is the only reliable way to correlate a DSN from a multi- 1112 recipient message transfer with the intended recipient. 1114 RFC2821.Received: Set by - Originator, Relay, Mediator, Dest 1116 This field contains trace information, including originating 1117 host, Relays, Mediators, and MSA host domain names and/or IP 1118 Addresses. 1120 RFC2821.Return-Path: Set by - Originator 1122 The MDA records the RFC2821.MailFrom address into the 1123 RFC2822.Return-Path field. 1125 RFC2919.List-Id: Set by - Mediator Author 1127 This field provides a globally unique mailing list naming 1128 framework that is independent of particular hosts. [RFC2919] 1130 The identifier is in the form of a domain name; however, the 1131 string usually is constructed by combining the two parts of an 1132 email address. The result is rarely a true domain name, listed 1133 in the domain name service, although it can be. 1135 RFC2369.List-*: Set by - Mediator Author 1137 [RFC2369] defines a collection of message header fields for use 1138 by mailing lists. In effect, they supply list-specific 1139 parameters for common mailing list user operations. The 1140 identifiers for these operations are for the list itself and 1141 the user-as-subscriber. [RFC2369] 1143 RFC0791.SourceAddr: Set by - The Client SMTP sending host 1144 immediately preceding the current receiving SMTP server. 1146 [RFC0791] defines the basic unit of data transfer for the 1147 Internet: the IP Datagram. It contains a Source Address field 1148 that specifies the IP Address for the host (interface) from 1149 which the datagram was sent. This information is set and 1150 provided by the IP layer, which makes it independent of mail- 1151 level mechanisms. As such, it is often taken to be 1152 authoritative, although it is possible to provide false 1153 addresses. 1155 4.2. User-Level Services 1157 Interactions at the user level entail protocol exchanges, distinct 1158 from those that occur at lower layers of the Internet Mail MHS 1159 architecture that is, in turn, above the Internet Transport layer. 1160 Because the motivation for email, and much of its use, is for 1161 interaction among people, the nature and details of these protocol 1162 exchanges often are determined by the needs of interpersonal and 1163 group communication. To accommodate the idiosyncratic behavior 1164 inherent in such communication, only subjective guidelines, rather 1165 than strict rules, can be offered for some aspects of system 1166 behavior. Mailing Lists provide particularly salient examples. 1168 4.2.1. Mail User Agent (MUA) 1170 A Mail User Agent (MUA) works on behalf of User actors and User 1171 applications. It is their representative within the email service. 1173 The Author MUA (aMUA) creates a message and performs initial 1174 submission into the transfer infrastructure via a Mail Submission 1175 Agent (MSA). It can also perform any creation- and posting-time 1176 archival in its Message Store (aMS). An MUA aMS can organize 1177 messages in many different ways. A common model uses aggregations, 1178 called "folders". This model allows a folder for messages under 1179 development (Drafts), a folder for messages waiting to be sent 1180 (Queued or Unsent), and a folder for messages that have been 1181 successfully posted for transfer (Sent). But none of these folders 1182 is required. For example, IMAP allows drafts to be stored in any 1183 folder; so no Drafts folder is present. 1185 The Recipient MUA (rMUA) works on behalf of the Recipient to process 1186 received mail. This processing includes generating user-level 1187 disposition control messages, displaying and disposing of the 1188 received message, and closing or expanding the user communication 1189 loop by initiating replies and forwarding new messages. 1191 NOTE: Although not shown in Figure 5, an MUA itself can have a 1192 distributed implementation, such as a "thin" user interface 1193 module on a constrained device such as a smartphone, with most 1194 of the MUA functionality running remotely on a more capable 1195 server. An example of such an architecture might use IMAP 1196 [RFC3501] for most of the interactions between an MUA client 1197 and an MUA server. An approach for such scenarios is defined 1198 by [RFC4550]. 1200 A Mediator is special class of MUA. It performs message re-posting, 1201 as discussed in Section 2.1. 1203 An MUA can be automated, on behalf of a user who is not present at 1204 the time the MUA is active. One example is a bulk sending service 1205 that has a timed-initiation feature. These services are not to be 1206 confused with a mailing list Mediator, since there is no incoming 1207 message triggering the activity of the automated service. 1209 A popular and problematic MUA is an automatic responder, such as one 1210 that sends out-of-office notices. This behavior might be confused 1211 with that of a Mediator, but this MUA is generating a new message. 1212 Automatic responders can annoy users of mailing lists unless they 1213 follow [RFC3834]. ****** The recommendations in RFC 3834 are an 1214 important consequence of the addressing architecture of Internet Mail 1215 so they do help illustrate the architecture. ***** 1217 These identity fields are relevant to a typical MUA: 1219 RFC2822.From 1221 RFC2822.Reply-To 1223 RFC2822.Sender 1224 RFC2822.To, RFC2822.CC 1226 RFC2822.BCC 1228 4.2.2. Message Store (MS) 1230 An MUA can employ a long-term Message Store (MS). Figure 5 depicts 1231 an Author's MS (aMS) and a Recipient's MS (rMS). An MS can be 1232 located on a remote server or on the same machine as the MUA. 1234 An MS acquires messages from an MDA either by a local mechanism or by 1235 using POP or IMAP. The MUA accesses the MS either by a local 1236 mechanism or by using POP or IMAP. Using POP for message access, 1237 rather than bulk transfer, is rare, awkward, and largely non- 1238 standard. 1240 4.3. MHS-Level Services 1242 4.3.1. Mail Submission Agent (MSA) 1244 A Mail Submission Agent (MSA) accepts the message submitted by the 1245 aMUA and enforces the policies of the hosting ADMD and the 1246 requirements of Internet standards. An MSA represents an unusual 1247 functional dichotomy. It represents the interests of the Author 1248 (aMUA) during message posting, to facilitate posting success; it also 1249 represents the interests of the MHS. In the architecture, these 1250 responsibilities are modeled, as shown in Figure 5, by dividing the 1251 MSA into two sub-components, aMSA and hMSA, respectively. Transfer 1252 of responsibility for a single message, from an Author's environment 1253 to the MHS, is called "posting". In Figure 5 it is marked as the (S) 1254 transition, within the MSA. 1256 The hMSA takes transit responsibility for a message that conforms to 1257 the relevant Internet standards and to local site policies. It 1258 rejects messages that are not in conformance. The MSA performs final 1259 message preparation for submission and effects the transfer of 1260 responsibility to the MHS, via the hMSA. The amount of preparation 1261 depends upon the local implementations. Examples of oMSA tasks 1262 include adding header fields, such as Date: and Message-ID:, and 1263 modifying portions of the message from local notations to Internet 1264 standards, such as expanding an address to its formal RFC2822 1265 representation. 1267 Historically, standards-based MUA/MSA message postings have used 1268 SMTP. [RFC2821] The standard currently preferred is SUBMISSION. 1269 [RFC4409] Although SUBMISSION derives from SMTP, it uses a separate 1270 TCP port and imposes distinct requirements, such as access 1271 authorization. 1273 These identities are relevant to the MSA: 1275 RFC2821.HELO/.EHLO 1277 RFC3461.ENVID 1279 RFC2821.MailFrom 1281 RFC2821.RcptTo 1283 RFC2821.Received 1285 RFC0791.SourceAddr 1287 4.3.2. Mail Transfer Agent (MTA) 1289 A Mail Transfer Agent (MTA) relays mail for one application-level 1290 "hop." It is like a packet-switch or IP router in that its job is to 1291 make routing assessments and to move the message closer to the 1292 Recipients. Of course, email objects are typically much larger than 1293 the payload of a packet or datagram, and the end-to-end latencies are 1294 typically much higher. Relaying is performed by a sequence of MTAs, 1295 until the message reaches a destination MDA. Hence, an MTA 1296 implements both client and server MTA functionality; it does not 1297 change addresses in the envelope or reformulate the editorial 1298 content. A change in data form, such as to MIME Content-Transfer- 1299 Encoding, is within the purview of an MTA, but removal or replacement 1300 of body content is not. An MTA also adds trace information. 1301 [RFC2505] 1303 NOTE: Within a destination ADMD, email relaying modules can 1304 make a variety of changes to the message, prior to delivery. 1305 In such cases, these modules are acting as Gateways, rather 1306 than MTAs. 1308 Internet Mail uses SMTP [RFC2821], [RFC0821] primarily to effect 1309 point-to-point transfers between peer MTAs. Other transfer 1310 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1311 most network layer mechanisms, the Internet Mail SMTP supports a 1312 basic level of reliability, by virtue of providing for retransmission 1313 after a temporary transfer failure. Unlike typical packet switches 1314 (and Instant Messaging services), Internet Mail MTAs are expected to 1315 store messages in a manner that allows recovery across service 1316 interruptions, such as host system shutdown. The degree of such 1317 robustness and persistence by an MTA can vary. The base SMTP 1318 specification provides a framework for protocol response codes. An 1319 extensible enhancement to this framework is defined in [RFC5248] 1321 The primary routing mechanism for Internet Mail is the DNS MX record 1322 [RFC1035], which specifies an MTA through which the queried domain 1323 can be reached. This mechanism presumes a public, or at least a 1324 common, backbone that permits any attached MTA to connect to any 1325 other. 1327 MTAs can perform any of these well-established roles: 1329 Boundary MTA: An MTA that is part of an ADMD and interacts with 1330 MTAs in other ADMDs. This is also called a Border MTA. There 1331 can be different Boundary MTAs, according to the direction of 1332 mail-flow. 1334 Outbound MTA: An MTA that relays messages to other ADMDs. 1336 Inbound MTA: An MTA that receives inbound SMTP messages from 1337 MTA Relays in other ADMDs, for example, an MTA running on 1338 the host listed as the target of an MX record. 1340 Final MTA: The MTA that transfers a message to the MDA. 1342 These identities are relevant to the MTA: 1344 RFC2821.HELO/.EHLO 1346 RFC3461.ENVID 1348 RFC2821.MailFrom 1350 RFC2821.RcptTo 1352 RFC2822.Received: Set by - Relay Server 1354 RFC0791.SourceAddr 1356 4.3.3. Mail Delivery Agent (MDA) 1358 A transfer of responsibility from the MHS to a Recipient's 1359 environment (mailbox) is called "delivery." In the architecture, as 1360 depicted in Figure 5, delivery takes place within a Mail Delivery 1361 Agent (MDA) and is shown as the (D) transition from the MHS-oriented 1362 MDA component (hMDA) to the Recipient-oriented MDA component (rMDA). 1364 An MDA can provide distinctive, address-based functionality, made 1365 possible by its detailed information about the properties of the 1366 destination address. This information might also be present 1367 elsewhere in the Recipient's ADMD, such as at an organizational 1368 border (Boundary) Relay. However, it is required for the MDA, if 1369 only because the MDA is required to know where to deliver the 1370 message. 1372 Like an MSA, an MDA serves two roles, as depicted in Figure 5. 1373 Formal transfer of responsibility, called "delivery", is effected 1374 between the two components that embody these roles as shows as "(D)" 1375 in Figure 5. The MHS portion (hMDA) primarily functions as a server 1376 SMTP engine. A common additional role is to re-direct the message to 1377 an alternative address, as specified by the recipient addressee's 1378 preferences. The job of the recipient portion of the MDA (rMDA) is 1379 to perform any delivery actions that the Recipient specifies. 1381 Transfer into the MDA is accomplished by a normal MTA transfer 1382 mechanism. Transfer from an MDA to an MS uses an access protocol, 1383 such as POP or IMAP. 1385 NOTE: The term "delivery" can refer to the formal, MHS function 1386 specified here or to the first time a message is displayed to a 1387 Recipient. A simple, practical test for whether the MHS-based 1388 definition applies is whether a DSN can be generated. 1390 These identities are relevant to the MDA: 1392 RFC2821.Return-Path: Set by - Author Originator or Mediator 1393 Originator 1395 The MDA records the RFC2821.MailFrom address into the 1396 RFC2822.Return-Path field. 1398 RFC2822.Received: Set by - MDA server 1400 An MDA can record a Received: header field to indicate trace 1401 information, including source host and receiving host domain 1402 names and/or IP Addresses. 1404 4.4. Transition Modes 1406 From the origination site to the point of delivery, Internet Mail 1407 usually follows a "push" model. That is, the actor that holds the 1408 message initiates transfer to the next venue, typically with SMTP 1409 [RFC2821] or LMTP [RFC2033]. With a "pull" model, the actor that 1410 holds the message waits for the actor in the next venue to initiate a 1411 request for transfer. Standardized mechanisms for pull-based MHS 1412 transfer are ETRN [RFC1985] and ODMR [RFC2645]. 1414 After delivery, the Recipient's MUA (or MS) can gain access by having 1415 the message pushed to it or by having the receiver of access pull the 1416 message, such as by using POP [RFC1939] and IMAP [RFC3501]. 1418 4.5. Implementation and Operation 1420 A discussion of any interesting system architecture often bogs down 1421 when architecture and implementation are confused. An architecture 1422 defines the conceptual functions of a service, divided into discrete 1423 conceptual modules. An implementation of that architecture can 1424 combine or separate architectural components, as needed for a 1425 particular operational environment. For example, a software system 1426 that primarily performs message relaying is an MTA, yet it might 1427 also include MDA functionality. That same MTA system might be able 1428 to interface with non-Internet email services and thus perform both 1429 as an MTA and as a Gateway. 1431 Similarly, implemented modules might be configured to form 1432 elaborations of the architecture. An interesting example is a 1433 distributed MS. One portion might be a remote server and another 1434 might be local to the MUA. As discussed in [RFC1733], there are 1435 three operational relationships among such MSs: 1437 Online: The MS is remote, and messages are accessible only when 1438 the MUA is attached to the MS so that the MUA will re-fetch all 1439 or part of a message, from one session to the next. 1441 Offline: The MS is local to the user, and messages are 1442 completely moved from any remote store, rather than (also) 1443 being retained there. 1445 Disconnected: An rMS and a uMS are kept synchronized, for all or 1446 part of their contents, while they are connected. When they 1447 are disconnected, mail can arrive at the rMS and the user can 1448 make changes to the uMS. The two stores are re-synchronized 1449 when they are reconnected. 1451 5. Mediators 1453 Basic message transfer from Author to Recipients is accomplished by 1454 using an asynchronous store-and-forward communication infrastructure 1455 in a sequence of independent transmissions through some number of 1456 MTAs. A very different task is a sequence of postings and deliveries 1457 through Mediators. A Mediator forwards a message, through a re- 1458 posting process. The Mediator shares some functionality with basic 1459 MTA relaying, but has greater flexibility in both addressing and 1460 content than is available to MTAs. 1462 This is the core set of message information that is commonly set by 1463 all types of Mediators: 1465 RFC2821.HELO/.EHLO: Set by - Mediator Originator 1467 RFC3461.ENVID: Set by - Mediator Originator 1469 RFC2821.RcptTo: Set by - Mediator Author 1471 RFC2821.Received: Set by - Mediator Dest 1473 The Mediator can record received information, to indicate the 1474 delivery to the original address and submission to the alias 1475 address. The trace of Received: header fields can include 1476 everything from original posting, through relaying, to final 1477 delivery. 1479 The aspect of a Mediator that distinguishes it from any other MUA 1480 creating a message is that a Mediator preserves the integrity and 1481 tone of the original message, including the essential aspects of its 1482 origination information. The Mediator might also add commentary. 1484 Examples of MUA messages that a Mediator does not create include: 1486 New message that forwards an existing message: 1488 Although this action provides a basic template for a class of 1489 Mediators, its typical occurrence is not, itself, an example of 1490 a Mediator. The new message is viewed as being from the actor 1491 that is doing the forwarding, rather than from the original 1492 Author. 1494 A new message encapsulates the original message and is seen as 1495 from the new Originator. This Mediator Originator might add 1496 commentary and can modify the original message content. 1498 Because the forwarded message is a component of the message 1499 sent by the new Originator, the new message creates a new 1500 dialogue. However the final Recipient still sees the contained 1501 message as from the original Author. 1503 Reply: 1505 When a Recipient responds to the Author of a message, the new 1506 message is not typically viewed as a forwarding of the 1507 original. Its focus is the new content, although it might 1508 contain all or part of the material from the original message. 1509 The earlier material is merely contextual and secondary. This 1510 includes automated replies, such as vacation out-of-office 1511 notices, as discussed in Section 4.2.1. 1513 Annotation: 1515 The integrity of the original message is usually preserved, but 1516 one or more comments about the message are added in a manner 1517 that distinguishes commentary from original text. The primary 1518 purpose of the new message is to provide commentary from a new 1519 Author, similar to a Reply. 1521 The remainder of this section describes common examples of 1522 Mediators. 1524 5.1. Alias 1526 One function of an MDA is to determine the internal location of a 1527 mailbox in order to perform delivery. An Alias is a simple re- 1528 addressing facility that provides one or more new Internet Mail 1529 addresses, rather than a single, internal one; the message continues 1530 through the transfer service, for delivery to one or more alternate 1531 addresses. Although typically implemented as part of an MDA, this 1532 facility is a Recipient function. It resubmits the message, although 1533 all handling information except the envelope recipient 1534 (rfc2821.RcptTo) address is retained. In particular, the Return 1535 address (rfc2821.MailFrom) is unchanged. 1537 What is distinctive about this forwarding mechanism is how closely it 1538 resembles normal MTA store-and-forward relaying. Its only 1539 significant difference is that it changes the RFC2821.RcptTo value. 1540 Because this change is so small, aliasing can be viewed as a part of 1541 the lower-level mail relaying activity. However, this small change 1542 has a large semantic impact: The designated recipient has chosen a 1543 new recipient. 1545 NOTE: When the replacement list includes more than one address, 1546 the alias is increasingly likely to have delivery problems. 1547 Any problem reports go to the original Author, not the 1548 administrator of the alias entry. This makes it more difficult 1549 to resolve the problem, because the original Author has no 1550 knowledge of the Alias mechanism. 1552 Alias typically changes only envelope information: 1554 RFC2822.To/.CC/.BCC: Set by - Author 1556 These fields retain their original addresses. 1558 RFC2821.MailFrom: Set by - Author 1560 The benefit of retaining the original MailFrom value is to 1561 ensure that an actor related to the originating ADMD knows 1562 there has been a delivery problem. On the other hand, the 1563 responsibility for handling problems, when transiting from the 1564 original recipient mailbox to the alias mailbox usually lies 1565 with that original Recipient, because the Alias mechanism is 1566 strictly under that Recipient's control. Retaining the 1567 original MailFrom address prevents this. 1569 5.2. ReSender 1571 Also called the ReDirector, the ReSender's actions differ from 1572 forwarding because the Mediator "splices" a message's addressing 1573 information to connect the Author of the original message with the 1574 Recipient of the new message. This connection permits them to have 1575 direct exchange, using their normal MUA Reply functions, while also 1576 recording full reference information about the Recipient who served 1577 as a Mediator. Hence, the new Recipient sees the message as being 1578 from the original Author, even if the Mediator adds commentary. 1580 These identities are relevant to a resent message: 1582 RFC2822.From: Set by - original Author 1583 Names and addresses for the original Author of the message 1584 content are retained. The free-form (display-name) portion of 1585 the address might be modified to provide informal reference to 1586 the ReSender. 1588 RFC2822.Reply-To: Set by - original Author 1590 If this field is present in the original message, it is 1591 retained in the resent message. 1593 RFC2822.Sender: Set by - Author's Originator or Mediator 1594 Originator. 1596 RFC2822.To/.CC/.BCC: Set by - original Author 1598 These fields specify the original message Recipients. 1600 RFC2822.Resent-From: Set by - Mediator Author 1602 This address is of the original Recipient who is redirecting 1603 the message. Otherwise, the same rules apply to the Resent- 1604 From: field as to an original RFC2822.From field. 1606 RFC2822.Resent-Sender: Set by - Mediator Originator 1608 The address of the actor responsible for resubmitting the 1609 message. As with RFC2822.Sender, this field can be omitted 1610 when it contains the same address as RFC2822.Resent-From. 1612 RFC2822.Resent-To/-CC/-BCC: Set by: Mediator Author 1614 The addresses of the new Recipients who are now able to reply 1615 to the original author. 1617 RFC2821.MailFrom: Set by - Mediator Originator 1619 The actor responsible for resubmission (RFC2822.Resent-Sender) 1620 is also responsible for specifying the new MailFrom address. 1622 5.3. Mailing Lists 1624 A Mailing List receives messages as an explicit addressee and then 1625 re-posts them to a list of subscribed members. The Mailing List 1626 performs a task that can be viewed as an elaboration of the ReSender. 1627 In addition to sending the new message to a potentially large number 1628 of new Recipients, the Mailing List can modify content, for example, 1629 by deleting attachments, converting the format, and adding list- 1630 specific comments. Mailing Lists also archive messages posted by 1631 Authors. Still the message retains characteristics of being from the 1632 original Author. 1634 These identities are relevant to a mailing list processor, when 1635 submitting a message: 1637 RFC2919.List-Id: Set by - Mediator Author 1639 RFC2369.List-*: Set by - Mediator Author 1641 RFC2822.From: Set by - original Author 1643 Names and email addresses for the original Author of the 1644 message content are retained. 1646 RFC2822.Reply-To: Set by - Mediator or original Author 1648 Although problematic, it is common for a Mailing List to assign 1649 its own addresses to the Reply-To: header field of messages 1650 that it posts. This assignment is intended to ensure that 1651 replies go to all list members, rather than to only the 1652 original Author. As a User actor, a Mailing List is the Author 1653 of the new message and can legitimately set the Reply-To: 1654 value. As a Mediator attempting to represent the message on 1655 behalf of its original Author, creating or modifying a 1656 Reply-To: field can be viewed as violating that Author's 1657 intent. Modifying the field to include the list address can 1658 send to the entire list replies that are meant only for the 1659 original Author. When the Mailing List does not set the field, 1660 a reply meant for the entire list can instead go only to the 1661 original Author. At best, either choice is a matter of group 1662 culture for the particular list. 1664 RFC2822.Sender: Set by - Author Originator or Mediator 1665 Originator 1667 This field usually specifies the address of the actor 1668 responsible for Mailing List operations. Mailing Lists that 1669 operate in a manner similar to a simple MTA Relay preserve as 1670 much of the original handling information as possible, 1671 including the original RFC2822.Sender field. (Note that this 1672 mode of operation causes the Mailing List to behave much like 1673 an Alias, with a possible difference in number of new 1674 addressees.) 1676 RFC2822.To/.CC: Set by - original Author 1678 These fields usually contain the original list of Recipient 1679 addresses. 1681 RFC2821.MailFrom: Set by - Mediator Originator 1683 Because a Mailing List can modify the content of a message in 1684 any way, it is responsible for that content; that is, it is an 1685 Author. As such, the Return Address is specified by the 1686 Mailing List. Although it is plausible for the Mailing List to 1687 re-use the Return Address employed by the original Originator, 1688 notifications sent to that address after a message has been 1689 processed by a Mailing List could be problematic. 1691 5.4. Gateways 1693 A Gateway performs the basic routing and transfer work of message 1694 relaying, but it also is permitted to modify content, structure, 1695 address, or attributes as needed to send the message into a messaging 1696 environment that operates under different standards or potentially 1697 incompatible policies. When a Gateway connects two differing 1698 messaging services, its role is easy to identify and understand. 1699 When it connects environments that follow similar technical 1700 standards, but significantly different administrative policies, it is 1701 easy to view a Gateway as merely an MTA. 1703 The critical distinction between an MTA and a Gateway is that a 1704 Gateway can make substantive changes to a message to map between the 1705 standards. In virtually all cases, this mapping results in some 1706 degree of semantic loss. The challenge of Gateway design is to 1707 minimize this loss. Standardized gateways to Internet Mail are 1708 facsimile [RFC4143], voicemail [RFC3801], and MMS [RFC4356] 1710 A Gateway can set any identity field available to an MUA. These 1711 identities are typically relevant to Gateways: 1713 RFC2822.From: Set by - original Author 1715 Names and addresses for the original Author of the message 1716 content are retained. As for all original addressing 1717 information in the message, the Gateway can translate addresses 1718 as required to continue to be useful in the target environment. 1720 RFC2822.Reply-To: Set by - original Author 1722 The Gateway SHOULD retain this information, if it is present. 1723 The ability to perform a successful reply by a Recipient is a 1724 typical test of Gateway functionality. 1726 RFC2822.Sender: Set by - Author Originator or Mediator 1727 Originator 1729 This field can retain the original value or can be set to a new 1730 address. 1732 RFC2822.To/.CC/.BCC: Set by - original Recipient 1734 These fields usually retain their original addresses. 1736 RFC2821.MailFrom: Set by - Author Originator or Mediator 1737 Originator 1739 The actor responsible for handling the message can specify a 1740 new address to receive handling notices. 1742 5.5. Boundary Filter 1744 To enforce security boundaries, organizations can subject messages to 1745 analysis, for conformance with its safety policies. An example is 1746 detection of content classed as spam or a virus. A filter might 1747 alter the content, to render it safe, such as by removing content 1748 deemed unacceptable. Typically, these actions add content to the 1749 message that records the actions. 1751 6. Considerations 1753 6.1. Security Considerations 1755 This document describes the existing Internet Mail architecture. It 1756 introduces no new capabilities. The security considerations of this 1757 deployed architecture are documented extensively in the technical 1758 specifications referenced by this document. These specifications 1759 cover classic security topics, such as authentication and privacy. 1760 For example, email transfer protocols can use standardized mechanisms 1761 for operation over authenticated and/or encrypted links, and message 1762 content has similar protection standards available. Examples of such 1763 mechanisms include SMTP-TLS [RFC3207], SMTP-Auth [RFC2554], OpenPGP 1764 [RFC4880], and S/MIME [RFC3851]. 1766 The core of the Internet Mail architecture does not impose any 1767 security requirements or functions on the end-to-end or hop-by-hop 1768 components. For example, it does not require participant 1769 authentication and does not attempt to prevent data disclosure. 1771 Particular message attributes might expose specific security 1772 considerations. For example, the blind carbon copy feature of the 1773 architecture invites disclosure concerns, as discussed in section 7.2 1774 of [RFC2821] and section 5 of [RFC2822]. Transport of text or non- 1775 text content in this architecture has security considerations that 1776 are discussed in [RFC2822], [RFC2045], [RFC2046], and [RFC4288] as 1777 well as the security considerations present in the IANA media types 1778 registry for the respective types. 1780 Agents that automatically respond to email raise significant security 1781 considerations, as discussed in [RFC3834]. Gateway behaviors affect 1782 end-to-end security services, as discussed in [RFC2480]. Security 1783 considerations for boundary filters are discussed in [RFC5228]. 1785 See section 7.1 of [RFC2821] for a discussion of the topic of 1786 origination validation. As mentioned in Section 4.1.4, it is common 1787 practice for components of this architecture to use the 1788 [RFC0791].SourceAddr to make policy decisions [RFC2505], although the 1789 address can be "spoofed". It is possible to use it without 1790 authorization. SMTP and Submission authentication [RFC2554], 1791 [RFC4409] provide more secure alternatives. 1793 The discussion of trust boundaries, ADMDs, actors, roles, and 1794 responsibilities in this document highlights the relevance and 1795 potential complexity of security factors for operation of an Internet 1796 mail service. The core design of Internet Mail to encourage open and 1797 casual exchange of messages has met with scaling challenges, as the 1798 population of email participants has grown to include those with 1799 problematic practices. For example, spam, as defined in [RFC2505], 1800 is a by-product of this architecture. A number of standards track or 1801 BCP documents on the subject have been issued. [RFC2505], [RFC5068], 1802 [RFC3685] 1804 6.2. IANA Considerations 1806 This document has no actions for IANA. 1808 6.3. Internationalization 1810 Because its origins date back to the use of ASCII, Internet Mail has 1811 had an ongoing challenge to support the wide range of necessary 1812 international data representations. For a discussion of this topic, 1813 see [MAIL-I18N]. 1815 7. References 1817 7.1. Normative 1819 [RFC0791] Postel, J., "Internet Protocol", RFC 791, 1981 September. 1821 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1822 STD 13, RFC 1034, November 1987. 1824 [RFC1035] Mockapetris, P., "Domain names - implementation and 1825 specification", STD 13, RFC 1035, November 1987. 1827 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1828 STD 53, RFC 1939, May 1996. 1830 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1831 Extensions (MIME) Part One: Format of Internet Message 1832 Bodies", RFC 2045, November 1996. 1834 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1835 Extensions (MIME) Part Two: Media Types", RFC 2046, 1836 November 1996. 1838 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1839 Part Three: Message Header Extensions for Non-ASCII Text", 1840 RFC 2047, November 1996. 1842 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1843 Extensions (MIME) Part Five: Conformance Criteria and 1844 Examples", RFC 2049, November 1996. 1846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1847 Requirement Levels", BCP 14, RFC 2119, March 1997. 1849 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1850 Specification", RFC 2181, July 1997. 1852 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1853 for Core Mail List Commands and their Transport through 1854 Message Header Fields", RFC 2369, July 1998. 1856 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1857 Addresses", RFC 2645, August 1999. 1859 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1860 April 2001. 1862 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1863 April 2001. 1865 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1866 and Namespace for the Identification of Mailing Lists", 1867 RFC 2919, March 2001. 1869 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet 1870 Mail", RFC 2304, October 2001. 1872 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 1873 Negotiation for Messaging Services based on Email", 1874 RFC 3297, July 2002. 1876 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1877 Context for Internet Mail", RFC 3458, January 2003. 1879 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1880 Extension for Delivery Status Notifications (DSNs)", 1881 RFC 3461, January 2003. 1883 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1884 4rev1", RFC 3501, March 2003. 1886 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1887 Notification", RFC 3798, May 2004. 1889 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 1890 Electronic Mail", RFC 3834, August 2004. 1892 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1893 Procedures for Message Header Fields", RFC 3864, 1894 September 2004. 1896 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 1897 Header Fields", RFC 4021, March 2005. 1899 [RFC4288] Freed, N., Klensin, J., and J. Postel, "Media Type 1900 Specifications and Registration Procedures", BCP 13, 1901 RFC 4288, December 2005. 1903 [RFC4289] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1904 Internet Mail Extensions (MIME) Part Four: Registration 1905 Procedures", BCP 13, RFC 4289, December 2005. 1907 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1908 RFC 4409, April 2006. 1910 [RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support 1911 Diverse Service Environments (Lemonade) Profile", 1912 June 2006. 1914 [RFC5228] Showalter, T., "Sieve: A Mail Filtering Language", 1915 RFC 5228. 1917 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 1918 Mail System Status Codes", RFC 5248, June 2008. 1920 7.2. Informative 1922 [MAIL-I18N] 1923 Internet Mail Consortium, "Using International Characters 1924 in Internet Mail", IMC IMCR-010, August 1998. 1926 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 1927 RFC 821, August 1982. 1929 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1930 text messages", STD 11, RFC 822, August 1982. 1932 [RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4", 1933 December 1994. 1935 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 1936 RFC 1767, March 1995. 1938 [RFC1985] De Winter, J., "SMTP Service Extension for Remote 1939 Message Queue Starting", August 1996. 1941 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1942 October 1996. 1944 [RFC2142] Crocker, D., "Mailbox Names for Common services, Roles and 1945 Functions", RFC 2142, May 1997. 1947 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1949 [RFC2480] Freed, N., "Gateways and MIME Security Multiparts", 1950 RFC 2480, January 1999. 1952 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 1953 RFC 2505, February 1999. 1955 [RFC2554] Myers, J., "SMTP Service Extension for Authentication", 1956 RFC 2554, March 1999. 1958 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1959 Transport Layer Security", RFC 3207, February 2002. 1961 [RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest 1962 Extensions", RFC 3685, February 2004. 1964 [RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 1965 Mail - version 2 (VPIMv2)", RFC 3801, June 2004. 1967 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 1968 Extensions (S/MIME) Version 3.1 Message Specification", 1969 RFC 3851, July 2004. 1971 [RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for 1972 Message Tracking", RFC 3885, September 2004. 1974 [RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for 1975 Internet Mail: FFPIM", December 2005. 1977 [RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail 1978 (IFAX) Service of ENUM", RFC 4143, November 2005. 1980 [RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging 1981 Service (MMS) and Internet Mail", RFC 4356, January 2006. 1983 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1984 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1986 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 1987 E. Allman, "Email Submission Operations: Access and 1988 Accountability Requirements", RFC 5068, BCP 134, Nov 2007. 1990 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 1991 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1992 ACM SIGCOMM, 2002. 1994 Appendix A. Acknowledgements 1996 This work derives from a section in an early version of [RFC5068]. 1997 Discussion of the Originator actor role was greatly clarified during 1998 discussions in the IETF's Marid working group. 2000 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 2001 insight on the framework and details of the original drafts, as did 2002 Chris Newman for the final versions, while also serving as cognizant 2003 Area Director for the document. Tony Hansen served as document 2004 shepherd, through the IETF process. 2006 Later reviews and suggestions were provided by Eric Allman, Nathaniel 2007 Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, 2008 Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John 2009 Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, 2010 Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. 2011 Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg 2012 Vaudreuil. 2014 Diligent early proof-reading was performed by Bruce Lilly. Diligent 2015 technical editing was provided by Susan Hunziker 2017 Index 2018 10 2020 A 2021 accountability 11 2022 accountable 12-13 2023 Actor 2024 Administrative 13 2025 Author 8 2026 Consumer 14 2027 Edge 14 2028 Gateway 12 2029 Originator 11 2030 Recipient 9 2031 Return Handler 9 2032 Transit 14 2033 Actors 2034 MHS 10 2035 ADMD 11, 13-14, 18, 23, 29, 36 2036 Administrative Actors 13 2037 Administrative Management Domain 11 2038 aMSA 29 2039 Author 8, 10 2040 author 33 2042 B 2043 body-parts 22 2044 bounce handler 9 2045 boundary 14 2047 C 2048 Consumer Actor 14 2049 content 10, 12-13, 18, 22, 30 2051 D 2052 delivery 4, 9-10, 12-13, 17, 22-23, 33, 35-36 2053 Discussion of document 7 2055 E 2056 Edge Actor 14 2057 end-to-end 4 2058 envelope 9, 12, 19, 22-23, 30, 35-36 2059 ETRN 33 2061 G 2062 Gateway 10, 12 2064 H 2065 header 22 2066 hMSA 29 2068 I 2069 Internet Mail 4 2071 L 2072 LMTP 33 2073 local-part 16 2075 M 2076 Mail 4 2077 Mail User Agent 4 2078 Mail From 35 2079 Mail Handling Service 4, 10 2080 Mail Submission Agent 11 2081 Mail Transfer Agent 4 2082 mailbox 35 2083 MDA 35 2084 MDN 9 2085 message 6, 22 2086 Message Disposition Notification 9 2087 MHS 4, 9-12, 19-20, 22-23 2088 Actors 10 2089 MSA 11, 29 2090 MTA 4, 14 2091 boundary 14 2092 MUA 4, 13, 28-29 2094 O 2095 ODMR 33 2096 Originator 10-11 2098 P 2099 posting 4, 9, 11, 19, 28-29, 33, 36 2100 pull 33 2101 push 33 2103 R 2104 RcptTo 10 2105 Receiver 10 2106 Recipient 9-10, 35 2107 recipient 33 2108 relay 10 2109 responsibility 29 2110 responsible 12-13 2111 Return address 35 2112 Return Handler 9 2113 role 9, 17 2114 Author 8 2115 Originator 11 2116 Recipient 9 2118 S 2119 SIEVE 22 2120 SMTP 33 2122 T 2123 transfer 10, 12-13 2124 Transit Actor 14 2125 transition 29 2127 U 2128 UA 4 2129 User Agent 4 2131 Author's Address 2133 Dave Crocker 2134 Brandenburg InternetWorking 2135 675 Spruce Drive 2136 Sunnyvale, CA 94086 2137 USA 2139 Phone: +1.408.246.8253 2140 Email: dcrocker@bbiw.net 2142 Full Copyright Statement 2144 Copyright (C) The IETF Trust (2008). 2146 This document is subject to the rights, licenses and restrictions 2147 contained in BCP 78, and except as set forth therein, the authors 2148 retain all their rights. 2150 This document and the information contained herein are provided on an 2151 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2152 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2153 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2154 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2155 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2156 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2158 Intellectual Property 2160 The IETF takes no position regarding the validity or scope of any 2161 Intellectual Property Rights or other rights that might be claimed to 2162 pertain to the implementation or use of the technology described in 2163 this document or the extent to which any license under such rights 2164 might or might not be available; nor does it represent that it has 2165 made any independent effort to identify any such rights. Information 2166 on the procedures with respect to rights in RFC documents can be 2167 found in BCP 78 and BCP 79. 2169 Copies of IPR disclosures made to the IETF Secretariat and any 2170 assurances of licenses to be made available, or the result of an 2171 attempt made to obtain a general license or permission for the use of 2172 such proprietary rights by implementers or users of this 2173 specification can be obtained from the IETF on-line IPR repository at 2174 http://www.ietf.org/ipr. 2176 The IETF invites any interested party to bring to its attention any 2177 copyrights, patents or patent applications, or other proprietary 2178 rights that may cover technology that may be required to implement 2179 this standard. Please address the information to the IETF at 2180 ietf-ipr@ietf.org.