idnits 2.17.1 draft-crocker-email-arch-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 8, 2009) is 5437 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3462 (Obsoleted by RFC 6522) ** 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 733 (Obsoleted by RFC 822) -- 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 1652 (Obsoleted by RFC 6152) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3685 (Obsoleted by RFC 5235) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 5335 (Obsoleted by RFC 6532) -- Obsolete informational reference (is this intentional?): RFC 5336 (Obsoleted by RFC 6531) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 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: Informational June 8, 2009 5 Expires: December 10, 2009 7 Internet Mail Architecture 8 draft-crocker-email-arch-14 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on December 10, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 Over its thirty-five year history, Internet Mail has changed 57 significantly in scale and complexity, as it has become a global 58 infrastructure service. These changes have been evolutionary, rather 59 than revolutionary, reflecting a strong desire to preserve both its 60 installed base and its usefulness. To collaborate productively on 61 this large and complex system, all participants need to work from a 62 common view of it and use a common language to describe its 63 components and the interactions among them. But the many differences 64 in perspective currently make it difficult to know exactly what 65 another participant means. To serve as the necessary common frame of 66 reference, this document describes the enhanced Internet Mail 67 architecture, reflecting the current service. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2. The Role of This Architecture . . . . . . . . . . . . . . 7 74 1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 8 75 2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 8 76 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 9 77 2.2. Message Handling Service (MHS) Actors . . . . . . . . . . 12 78 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 15 79 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 3.2. Scope of Email Address Use . . . . . . . . . . . . . . . . 19 82 3.3. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 20 83 3.4. Message Identifier . . . . . . . . . . . . . . . . . . . . 20 84 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 22 85 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 25 86 4.1.4. Identity References in a Message . . . . . . . . . . . 27 87 4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 30 88 4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 32 89 4.4. Transition Modes . . . . . . . . . . . . . . . . . . . . . 36 90 4.5. Implementation and Operation . . . . . . . . . . . . . . . 36 91 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 5.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . . . 38 93 5.2. ReSender . . . . . . . . . . . . . . . . . . . . . . . . . 39 94 5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 41 95 5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 42 96 5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 43 97 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 43 98 6.1. Security Considerations . . . . . . . . . . . . . . . . . 44 99 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 45 100 6.3. Internationalization . . . . . . . . . . . . . . . . . . . 45 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 102 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 46 103 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 48 104 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 50 105 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 54 108 1. Introduction 110 Over its thirty-five year history, Internet Mail has changed 111 significantly in scale and complexity, as it has become a global 112 infrastructure service. These changes have been evolutionary, rather 113 than revolutionary, reflecting a strong desire to preserve both its 114 installed base and its usefulness. Today, Internet Mail is 115 distinguished by many independent operators, many different 116 components for providing service to users, as well as many different 117 components that transfer messages. 119 The underlying technical standards for Internet Mail comprise a rich 120 array of functional capabilities. These specifications form the 121 core: 123 * Simple Mail Transfer Protocol (SMTP) [RFC0821], [RFC2821], 124 [RFC5321] moves a message through the Internet. 126 * Internet Mail Format (IMF) [RFC0733], [RFC0822], [RFC2822], 127 [RFC5322] defines a message object. 129 * Multipurpose Internet Mail Extensions (MIME) [RFC2045] defines 130 an enhancement to the message object that permits using multi- 131 media attachments. 133 Public collaboration on technical, operations, and policy activities 134 of email, including those that respond to the challenges of email 135 abuse, has brought a much wider range of participants into the 136 technical community. To collaborate productively on this large and 137 complex system, all participants need to work from a common view of 138 it and use a common language to describe its components and the 139 interactions among them. But the many differences in perspective 140 currently make it difficult to know exactly what another participant 141 means. 143 It is the need to resolve these differences that motivates this 144 document, which describes the realities of the current system. 145 Internet Mail is the subject of ongoing technical, operations, and 146 policy work, and the discussions often are hindered by different 147 models of email service design and different meanings for the same 148 terms. 150 To serve as the necessary common frame of reference, this document 151 describes the enhanced Internet Mail architecture, reflecting the 152 current service. The document focuses on: 154 * Capturing refinements to the email model 156 * Clarifying functional roles for the architectural components 158 * Clarifying identity-related issues, across the email service 160 * Defining terminology for architectural components and their 161 interactions 163 1.1. History 165 The first standardized architecture for networked email specified a 166 simple split between the user world, in the form of Message User 167 Agents (MUA), and the transfer world, in the form of the Message 168 Handling Service (MHS), which is composed of Message Transfer Agents 169 (MTA) [RFC1506]. The MHS accepts a message from one User and 170 delivers it to one or more other users, creating a virtual MUA-to-MUA 171 exchange environment. 173 As shown in Figure 1, this defines two logical layers of 174 interoperability. One is directly between Users. The other is among 175 the components along the transfer path. In addition, there is 176 interoperability between the layers, first when a message is posted 177 from the User to the MHS and later when it is delivered from the MHS 178 to the User. 180 The operational service has evolved, although core aspects of the 181 service, such as mailbox addressing and message format style, remain 182 remarkably constant. The original distinction between the user level 183 and transfer level remains, but with elaborations in each. The term 184 "Internet Mail" is used to refer to the entire collection of user and 185 transfer components and services. 187 For Internet Mail, the term "end-to-end" usually refers to a single 188 posting and the set of deliveries that result from a single transit 189 of the MHS. A common exception is group dialogue that is mediated, 190 through a Mailing List; in this case, two postings occur before 191 intended Recipients receive an Author's message, as discussed in 192 Section 2.1.4. In fact, some uses of email consider the entire email 193 service, including Author and Recipient, as a subordinate component. 194 For these services, "end-to-end" refers to points outside the email 195 service. Examples are voicemail over email [RFC3801], EDI over email 196 [RFC1767] and facsimile over email [RFC4142]. 198 +--------+ 199 ++================>| User | 200 || +--------+ 201 || ^ 202 +--------+ || +--------+ . 203 | User +==++=========>| User | . 204 +---+----+ || +--------+ . 205 . || ^ . 206 . || +--------+ . . 207 . ++==>| User | . . 208 . +--------+ . . 209 . ^ . . 210 . . . . 211 V . . . 212 +---+-----------------+------+------+---+ 213 | . . . . | 214 | .................>. . . | 215 | . . . | 216 | ........................>. . | 217 | . . | 218 | ...............................>. | 219 | | 220 | Message Handling Service (MHS) | 221 +---------------------------------------+ 223 Legend: === lines indicate primary (possibly indirect) 224 transfers or roles 225 ... lines indicate supporting transfers or roles 227 Figure 1: Basic Internet Mail Service Model 229 End-to-end Internet Mail exchange is accomplished by using a 230 standardized infrastructure with these components and 231 characteristics: 233 * An email object 235 * Global addressing 237 * An asynchronous sequence of point-to-point transfer mechanisms 239 * No requirement for prior arrangement between MTAs or between 240 Authors and Recipients 242 * No requirement for prior arrangement between point-to-point 243 transfer services over the open Internet 245 * No requirement for Author, Originator, or Recipients to be 246 online at the same time 248 The end-to-end portion of the service is the email object, called a 249 "message." Broadly, the message itself distinguishes control 250 information, for handling, from the Author's content. 252 A precept to the design of mail over the open Internet is permitting 253 user-to-user and MTA-to-MTA interoperability without prior, direct 254 arrangement between the independent administrative authorities 255 responsible for handling a message. All participants rely on having 256 the core services universally supported and accessible, either 257 directly or through Gateways that act as translators between Internet 258 Mail and email environments conforming to other standards. Given the 259 importance of spontaneity and serendipity in interpersonal 260 communications, not requiring such prearrangement between 261 participants is a core benefit of Internet Mail and remains a core 262 requirement for it. 264 Within localized networks at the edge of the public Internet, prior 265 administrative arrangement often is required and can include access 266 control, routing constraints, and configuration of the information 267 query service. Although recipient authentication has usually been 268 required for message access since the beginning of Internet Mail, in 269 recent years it also has been required for message submission. In 270 these cases, a server validates the client's identity, whether by 271 explicit security protocols or by implicit infrastructure queries to 272 identify "local" participants. 274 1.2. The Role of This Architecture 276 An Internet service is an integration of related capabilities among 277 two or more participating nodes. The capabilities are accomplished 278 across the Internet by one or more protocols. What connects a 279 protocol to a service is an architecture. An architecture specifies 280 how the protocols implement the service by defining the logical 281 components of a service and the relationships among them. From that 282 logical view, a service defines what is being done, an architecture 283 defines where the pieces are (in relation to each other) and a 284 protocol defines how particular capabilities are performed. 286 As such, an architecture will more formally describe a service at a 287 relatively high level. A protocol which implements some portion of a 288 service will conform to the architecture to a greater or lesser 289 extent, depending on the pragmatic tradeoffs they make when trying to 290 implement the architecture in the context of real-world constraints. 291 Failure to precisely follow an architecture is not a failure of the 292 protocol, nor is failure to precisely cast a protocol a failure of 293 the architecture. Where a protocol varies from the architecture, it 294 will of course be appropriate for it to explain the reason for the 295 variance. However, such variance is not a mark against a protocol: 296 Happily, the IETF prefers running code to architectural purity. 298 In this particular case, this architecture attempts to define the 299 logical components of Internet email and does so post hoc, trying to 300 capture the architectural principles that the current email protocols 301 embody. To different extents, email protocols will conform to this 302 architecture more or less well. Insofar as this architecture differs 303 from those protocols, the reasons are generally well understood and 304 are required for interoperation. The differences are not a sign that 305 protocols need to be fixed. However, this architecture is a best 306 attempt at a logical model of Internet email, and insofar as new 307 protocol development varies from this architecture, it is necessary 308 for designers to understand those differences and explain them 309 carefully. 311 1.3. Document Conventions 313 References to structured fields of a message use a two-part dotted 314 notation. The first part cites the document that contains the 315 specification for the field and the second is the name of the field. 316 Hence is the IMF From: header field in an email 317 content header and is the address in the SMTP 318 "Mail From" command. 320 When occurring without the IMF (RFC 5322) qualifier, header field 321 names are shown with a colon suffix. For example, From:. 323 References to labels for actors, functions or components have the 324 first letter capitalized. 326 RFC EDITOR: Remove the following paragraph before publication. 328 Discussion venue: Please direct discussion about this document 329 to the IETF-SMTP mailing list . 331 2. Responsible Actor Roles 333 Internet Mail is a highly distributed service, with a variety of 334 actors playing different roles. These actors fall into three basic 335 types: 337 * User 339 * Message Handling Service (MHS) 341 * ADministrative Management Domain (ADMD) 343 Although related to a technical architecture, the focus on actors 344 concerns participant responsibilities, rather than functionality of 345 modules. For that reason, the labels used are different from those 346 used in classic email architecture diagrams. 348 2.1. User Actors 350 Users are the sources and sinks of messages. Users can be people, 351 organizations, or processes. They can have an exchange that 352 iterates, and they can expand or contract the set of users that 353 participate in a set of exchanges. In Internet Mail, there are four 354 types of Users: 356 * Authors 358 * Recipients 360 * Return Handlers 362 * Mediators 364 Figure 2 shows the primary and secondary flows of messages among 365 them. As a pragmatic heuristic: User Actors can generate, modify or 366 look at the whole message. 368 ++==========++ 369 || Author ||<..................................<.. 370 ++=++=++=++=++ . 371 || || || ++===========++ . 372 || || ++====>|| Recipient || . 373 || || ++=====+=====++ . 374 || || . . 375 || || ..........................>.+ 376 || || . 377 || || ................... . 378 || || . . . 379 || || V . . 380 || || +-----------+ ++=====+=====++ . 381 || ++========>| Mediator +===>|| Recipient || . 382 || +-----+-----+ ++=====+=====++ . 383 || . . . 384 || ..................+.......>.+ 385 || . 386 || ..............+.................. . 387 || . . . . 388 \/ V V ' . 389 +-----------+ +-----------+ ++=====+=====++ . 390 | Mediator +===>| Mediator +===>|| Recipient || . 391 +-----+-----+ +-----+-----+ ++=====+=====++ . 392 . . . . 393 .................+.................+.......>.. 395 Legend: === lines indicate primary (possibly indirect) 396 transfers or roles 397 ... lines indicate supporting transfers or roles 399 Figure 2: Relationships Among User Actors 401 From the user perspective, all message transfer activities are 402 performed by a monolithic Message Handling Service (MHS), even though 403 the actual service can be provided by many independent organizations. 404 Users are customers of this unified service. 406 Whenever any MHS actor sends information to back to an Author or 407 Originator in the sequence of handling a message, that actor is a 408 User. 410 2.1.1. Author 412 The Author is responsible for creating the message, its contents, and 413 its list of recipient addresses. The MHS transfers the message from 414 the Author and delivers it to the Recipients. The MHS has an 415 Originator role (Section 2.2.1) that correlates with the Author role. 417 2.1.2. Recipient 419 The Recipient is a consumer of the delivered message. The MHS has a 420 Receiver role (Section 2.2.4) that correlates with the Recipient 421 role. This is labeled Recv in Figure 3. 423 Any Recipient can close the user communication loop by creating and 424 submitting a new message that replies to the Author. An example of 425 an automated form of reply is the Message Disposition Notification 426 (MDN), which informs the Author about the Recipient's handling of the 427 message. (See Section 4.1.) 429 2.1.3. Return Handler 431 Also called "Bounce Handler", the Return Handler is a special form of 432 Recipient tasked with servicing notifications that the MHS generates, 433 as it transfers or delivers the message. (See Figure 3.) These 434 notices can be about failures or completions and are sent to an 435 address that is specified by the Originator. This Return Handling 436 address (also known as a Return address) might have no visible 437 characteristics in common with the address of the Author or 438 Originator. 440 2.1.4. Mediator 442 A Mediator receives, aggregates, reformulates, and redistributes 443 messages among Authors and Recipients who are the principals in 444 (potentially) protracted exchanges. This activity is easily confused 445 with the underlying MHS transfer exchanges. However, each serves 446 very different purposes and operates in very different ways. 448 When mail is delivered to the Mediator specified in the 449 RFC5321.RcptTo command for the original message, the MHS handles it 450 the same way as for any other Recipient. In particular, the MHS sees 451 each posting and delivery activity between sources and sinks as 452 independent; it does not see subsequent re-posting as a continuation 453 of a process. Because the Mediator originates messages, it can 454 receive replies. Hence, when submitting a reformulated message, the 455 Mediator is an Author, albeit an author actually serving as an agent 456 of one or more other authors. So a Mediator really is a full-fledged 457 User. Mediators are considered extensively in Section 5. 459 A Mediator attempts to preserve the original Author's information in 460 the message it reformulates but is permitted to make meaningful 461 changes to the message content or envelope. The MHS sees a new 462 message, but users receive a message that they interpret as being 463 from, or at least initiated by, the Author of the original message. 464 The role of a Mediator is not limited to merely connecting other 465 participants; the Mediator is responsible for the new message. 467 A Mediator's role is complex and contingent, for example, modifying 468 and adding content or regulating which users are allowed to 469 participate and when. The common example of this role is a group 470 Mailing List. In a more complex use, a sequence of Mediators could 471 perform a sequence of formal steps, such as reviewing, modifying, and 472 approving a purchase request. 474 A Gateway is a particularly interesting form of Mediator. It is a 475 hybrid of User and Relay that connects heterogeneous mail services. 476 Its purpose is to emulate a Relay. For a detailed discussion, see 477 Section 2.2.3. 479 2.2. Message Handling Service (MHS) Actors 481 The Message Handling Service (MHS) performs a single end-to-end 482 transfer on behalf of the Author to reach the Recipient addresses 483 specified in the original RFC5321.RcptTo commands. Exchanges that 484 are either mediated or iterative and protracted, such as those used 485 for collaboration over time are handled by the User actors, not by 486 the MHS actors. As a pragmatic heuristic MHS actors actors generate, 487 modify or look at only transfer data, rather than the entire message. 489 Figure 3 shows the relationships among transfer participants in 490 Internet Mail. Although it shows the Originator (labeled Origin) as 491 distinct from the Author and Receiver (labeled Recv) as distinct from 492 Recipient, each pair of roles usually has the same actor. Transfers 493 typically entail one or more Relays. However direct delivery from 494 the Originator to Receiver is possible. Intra-organization mail 495 services usually have only one Relay. 497 ++==========++ ++===========++ 498 || Author || || Recipient || 499 ++====++====++ +--------+ ++===========++ 500 || | Return | /\ 501 || +-+------+ || 502 \/ . ^ || 503 +---------+ . . +---++---+ 504 | | . . | | 505 /--+---------+----------------------------+--------+----\ 506 | | | . . MHS | | | 507 | | Origin +<...... .................+ Recv | | 508 | | | ^ | | | 509 | +---++----+ . +--------+ | 510 | || . /\ | 511 | || ..............+.................. || | 512 | \/ . . . || | 513 | +-------+-+ +--+------+ +-+--++---+ | 514 | | Relay +=======>| Relay +=======>| Relay | | 515 | +---------+ +----++---+ +---------+ | 516 | || | 517 | || | 518 | \/ | 519 | +---------+ | 520 | | Gateway +-->... | 521 | +---------+ | 522 \-------------------------------------------------------/ 524 Legend: === and || lines indicate primary (possibly 525 indirect) transfers or roles 526 ... lines indicate supporting transfers or roles 528 Figure 3: Relationships Among MHS Actors 530 2.2.1. Originator 532 The Originator ensures that a message is valid for posting and then 533 submits it to a Relay. A message is valid if it conforms to both 534 Internet Mail standards and local operational policies. The 535 Originator can simply review the message for conformance and reject 536 it if it finds errors, or it can create some or all of the necessary 537 information. In effect, the Originator is responsible for the 538 functions of the Mail Submission Agent. 540 The Originator operates with dual allegiance. It serves the Author 541 and can be the same entity. But its role in assuring validity means 542 that it also represents the local operator of the MHS, that is, the 543 local ADministrative Management Domain (ADMD). 545 The Originator also performs any post-submission, Author-related 546 administrative tasks associated with message transfer and delivery. 547 Notably, these tasks pertain to sending error and delivery notices, 548 enforcing local policies, and dealing with messages from the Author 549 that prove to be problematic for the Internet. The Originator is 550 accountable for the message content, even when it is not responsible 551 for it. The Author creates the message, but the Originator handles 552 any transmission issues with it. 554 2.2.2. Relay 556 The Relay performs MHS-level transfer-service routing and store-and- 557 forward, by transmitting or retransmitting the message to its 558 Recipients. The Relay adds trace information [RFC2505] but does not 559 modify the envelope information or the message content semantics. It 560 can modify message content representation, such as changing the form 561 of transfer encoding from binary to text, but only as required to 562 meet the capabilities of the next hop in the MHS. 564 A Message Handling System (MHS) network consists of a set of Relays. 565 This network is above any underlying packet-switching network that 566 might be used and below any Gateways or other Mediators. 568 In other words, email scenarios can involve three distinct 569 architectural layers, each providing its own type of data of store- 570 and-forward service: 572 * User Mediators 574 * MHS Relays 576 * Packet Switches 578 The bottom layer is the Internet's IP service. The most basic email 579 scenarios involve Relays and Switches. 581 When a Relay stops attempting to transfer a message, it becomes an 582 Author because it sends an error message to the Return address. The 583 potential for looping is avoided by omitting a Return address from 584 this message. 586 2.2.3. Gateway 588 A Gateway is a hybrid of User and Relay that connects heterogeneous 589 mail services. Its purpose is to emulate a Relay and the closer it 590 comes to this, the better. A Gateway operates as a User when it 591 needs the ability to modify message content. 593 Differences between mail services can be as small as minor syntax 594 variations, but they usually encompass significant, semantic 595 distinctions. One difference could be email addresses that are 596 hierarchical and machine-specific rather than a flat, global 597 namespace. Another difference could be support for text-only content 598 or multi-media. Hence the Relay function in a Gateway presents a 599 significant design challenge, if the resulting performance is to be 600 seen as nearly seamless. The challenge is to ensure user-to-user 601 functionality between the services, despite differences in their 602 syntax and semantics. 604 The basic test of Gateway design is whether an Author on one side of 605 a Gateway can send a useful message to a Recipient on the other side, 606 without requiring changes to any components in the Author's or 607 Recipient's mail services other than adding the Gateway. To each of 608 these otherwise independent services, the Gateway appears to be a 609 native participant. But the ultimate test of Gateway design is 610 whether the Author and Recipient can sustain a dialogue. In 611 particular, can a Recipient's MUA automatically formulate a valid 612 Reply that will reach the Author? 614 2.2.4. Receiver 616 The Receiver performs final delivery or sends the message to an 617 alternate address. It can also perform filtering and other policy 618 enforcement immediately before or after delivery. 620 2.3. Administrative Actors 622 Administrative actors can be associated with different organizations, 623 each with its own administrative authority. This operational 624 independence, coupled with the need for interaction between groups, 625 provides the motivation to distinguish among ADministrative 626 Management Domains (ADMDs ). Each ADMD can have vastly different 627 operating policies and trust-based decision-making. One obvious 628 example is the distinction between mail that is exchanged within an 629 organization and mail that is exchanged between independent 630 organizations. The rules for handling both types of traffic tend to 631 be quite different. That difference requires defining the boundaries 632 of each, and this requires the ADMD construct. 634 Operation of Internet Mail services is carried out by different 635 providers (or operators). Each can be an independent ADMD. This 636 independence of administrative decision-making defines boundaries 637 that distinguish different portions of the Internet Mail service. A 638 department that operates a local Relay, an IT department that 639 operates an enterprise Relay, and an ISP that operates a public 640 shared email service can be configured into many combinations of 641 administrative and operational relationships. Each is a distinct 642 ADMD, potentially having a complex arrangement of functional 643 components. Figure 4 depicts relationships among ADMDs. The 644 benefit of the ADMD construct is to facilitate discussion about 645 designs, policies and operations that need to distinguish between 646 internal issues and external ones. 648 The architectural impact of the need for boundaries between ADMDs is 649 discussed in [Tussle]. Most significant is that the entities 650 communicating across ADMD boundaries typically have the added burden 651 of enforcing organizational policies concerning external 652 communications. At a more mundane level, routing mail between ADMDs 653 can be an issue, such as needing to route mail between organizational 654 partners over specially trusted paths. 656 These are three basic types of ADMDs: 658 Edge: Independent transfer services in networks at the edge of 659 the open Internet Mail service. 661 Consumer: This might be a type of Edge service, as is common 662 for web-based email access. 664 Transit: Mail Service Providers (MSP) that offer value-added 665 capabilities for Edge ADMDs, such as aggregation and filtering. 667 The mail-level transit service is different from packet-level 668 switching. End-to-end packet transfers usually go through 669 intermediate routers; email exchange across the open Internet can be 670 directly between the Boundary MTAs of Edge ADMDs. This distinction 671 between direct and indirect interaction highlights the differences 672 discussed in Section 2.2.2 673 +--------+ +---------+ +-------+ +-----------+ 674 | ADMD1 |<===>| ADMD2 |<===>| ADMD3 |<===>| ADMD4 | 675 | ----- | | ----- | | ----- | | ----- | 676 | | | | | | | | 677 | Author | | | | | | Recipient | 678 | . | | | | | | ^ | 679 | V | | | | | | . | 680 | Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer | 681 | | | | | | | | 682 +--------+ +---------+ +-------+ +-----------+ 684 Legend: === lines indicate primary (possibly indirect) 685 transfers or roles 686 ... lines indicate supporting transfers or roles 688 Figure 4: Administrative Domain (ADMD) Example 690 Edge networks can use proprietary email standards internally. 691 However the distinction between Transit network and Edge network 692 transfer services is significant because it highlights the need for 693 concern over interaction and protection between independent 694 administrations. In particular, this distinction calls for 695 additional care in assessing the transitions of responsibility and 696 the accountability and authorization relationships among participants 697 in message transfer. 699 The interactions of ADMD components are subject to the policies of 700 that domain, which cover concerns such as these: 702 * Reliability 704 * Access control 706 * Accountability 708 * Content evaluation and modification 710 These policies can be implemented in different functional components, 711 according to the needs of the ADMD. For example, see [RFC5068]. 713 Consumer, Edge, and Transit services can be offered by providers that 714 operate component services or sets of services. Further, it is 715 possible for one ADMD to host services for other ADMDs. 717 These are common examples of ADMDs: 719 Enterprise Service Providers: 721 These ADMDs operate the internal data and/or the mail services 722 within an organization. 724 Internet Service Providers (ISP): 726 These ADMDs operate the underlying data communication services, 727 which are used by one or more Relay and User. ISPs are not 728 responsible for performing email functions, but they can 729 provide an environment in which those functions can be 730 performed. 732 Mail Service Providers: 734 These ADMDs operate email services, such as for consumers or 735 client companies. 737 Practical operational concerns demand that providers be involved in 738 administration and enforcement issues. This involvement can extend 739 to operators of lower-level packet services. 741 3. Identities 743 The forms of identity used by Internet Mail are: mailbox, domain 744 name, message-ID and ENVID. Each is globally unique. 746 3.1. Mailbox 748 "A mailbox receives mail. It is a conceptual entity that does not 749 necessarily pertain to file storage." [RFC5322] 751 A mailbox is specified as an Internet Mail address . It 752 has two distinct parts, separated by an at-sign (@). The right side 753 is a globally interpreted domain name associated with an ADMD. 754 Domain names are discussed in Section 3.3. Formal Internet Mail 755 addressing syntax can support source routes, to indicate the path 756 through which a message ought to be sent. The use of source routes 757 is not common and has been deprecated in [RFC5321]. 759 The portion to the left of the at-sign contains a string that is 760 globally opaque and is called the . It is interpreted 761 only by the entity specified by the address's domain name. Except as 762 noted later in this section all other entities treat the 763 as an uninterpreted literal string and preserve all of its original 764 details. As such its public distribution is equivalent to sending a 765 Web browser "cookie" that is only interpreted upon being returned to 766 its creator. 768 Some local-part values have been standardized, for contacting 769 personnel at an organization. These names cover common operations 770 and business functions. [RFC2142] 772 It is common for sites to have local structuring conventions for the 773 left-hand side of an . This permits sub- 774 addressing, such as for distinguishing different discussion groups 775 used by the same participant. However it is worth stressing that 776 these conventions are strictly private to the user's organization and 777 are not interpreted by any domain except the one listed in the right 778 side of the . The exceptions are those specialized 779 services that conform to public, standardized conventions, as noted 780 below. 782 Basic email addressing defines the as being globally 783 opaque. However there are some uses of email that add a 784 standardized, global schema to the value, such as between an author 785 and a Gateway. The details remain invisible to the 786 public email transfer infrastructure, but provide addressing and 787 handling instructions for further processing by the Gateway. 788 Standardized examples of these conventions are the telephone 789 numbering formats for VPIM [RFC3801], such as: 791 +16137637582@vpim.example.com 793 and iFax [RFC3192], such as: 795 FAX=+12027653000/T33S=1387@ifax.example.com 797 3.2. Scope of Email Address Use 799 Email addresses are being used far beyond their original role in 800 email transfer and delivery. In practical terms, an email address 801 string has become the common identifier for representing online 802 identity. Hence, it is essential to be clear about both the nature 803 and role of an identity string in a particular context and the entity 804 responsible for setting that string. For example, see Section 4.1.4, 805 Section 4.3.3 and Section 5. 807 3.3. Domain Names 809 A domain name is a global reference to an Internet resource, such as 810 a host, a service, or a network. A domain name usually maps to one 811 or more IP Addresses. Conceptually, the name can encompass an 812 organization, a collection of machines integrated into a homogeneous 813 service, or a single machine. A domain name can be administered to 814 refer to an individual user, but this is not common practice. The 815 name is structured as a hierarchical sequence of labels, separated by 816 dots (.), with the top of the hierarchy being on the right end of the 817 sequence. There can be many names in the sequence -- that is, the 818 depth of the hierarchy can be substantial. Domain names are defined 819 and operated through the Domain Name System (DNS) [RFC1034], 820 [RFC1035], [RFC2181]. 822 When not part of a mailbox address, a domain name is used in Internet 823 Mail to refer to the ADMD or to the host that took action upon the 824 message, such as providing the administrative scope for a message 825 identifier or performing transfer processing. 827 3.4. Message Identifier 829 There are two standardized tags for identifying messages: Message-ID: 830 and ENVID. A Message-ID: pertains to content, and an ENVID pertains 831 to transfer. 833 3.4.1. Message-ID 835 IMF provides for, at most, a single Message-ID:. The Message-ID: for 836 a single message, which is a user-level IMF tag, has a variety of 837 uses including threading, aiding identification of duplicates, and 838 DSN tracking. The Originator assigns the Message-ID:. The 839 Recipient's ADMD is the intended consumer of the Message-ID:, 840 although any actor along the transfer path can use it. 842 Message-ID: is be globally unique. Its format is similar to that of 843 a mailbox, with two distinct parts, separated by an at-sign (@). 844 Typically, the right side specifies the ADMD or host that assigns the 845 identifier, and the left side contains a string that is globally 846 opaque and serves to uniquely identify the message within the domain 847 referenced on the right side. The duration of uniqueness for the 848 message identifier is undefined. 850 When a message is revised in any way, the decision whether to assign 851 a new Message-ID: requires a subjective assessment to determine 852 whether the editorial content has been changed enough to constitute a 853 new message. [RFC5322] states that "a message identifier pertains to 854 exactly one instantiation of a particular message; subsequent 855 revisions to the message each receive new message identifiers." Yet 856 experience suggests that some flexibility is needed. An impossible 857 test is whether the recipient will consider the new message to be 858 equivalent to the old one. For most components of Internet Mail, 859 there is no way to predict a specific recipient's preferences on this 860 matter. Both creating and failing to create a new Message-ID: have 861 their downsides. 863 Here are some guidelines and examples: 865 * If a message is changed only in form, such as character 866 encoding, it is still the same message. 868 * If a message has minor additions to the content, such as a 869 mailing list tag at the beginning of the RFC5322.Subject header 870 field, or some mailing list administrative information added to 871 the end of the primary body-part text, it is probably the same 872 message. 874 * If a message has viruses deleted from it, it is probably the 875 same message. 877 * If a message has offensive words deleted from it, some 878 recipients will consider it the same message, but some will 879 not. 881 * If a message is translated into a different language, some 882 recipients will consider it the same message, but some will 883 not. 885 * If a message is included in a digest of messages, the digest 886 constitutes a new message. 888 * If a message is forwarded by a recipient, what is forwarded is 889 a new message. 891 * If a message is "redirected", such as using IMF "Resent-*" 892 header fields, some recipients will consider it the same 893 message, but some will not. 895 The absence of both objective, precise criteria for regenerating a 896 Message-ID: and strong protection associated with the string means 897 that the presence of an ID can permit an assessment that is 898 marginally better than a heuristic, but the ID certainly has no value 899 on its own for strict formal reference or comparison. For that 900 reason, the Message-ID: is not intended to be used for any function 901 that has security implications. 903 3.4.2. ENVID 905 The ENVID (envelope identifier) can be used for message-tracking 906 purposes ([RFC3885], [RFC3464]) concerning a single posting/delivery 907 transfer. The ENVID labels a single transit of the MHS by a specific 908 message. So, the ENVID is used for one message posting, until that 909 message is delivered. A re-posting of the message, such as by a 910 Mediator, does not reuse that ENVID, but can use a new one, even 911 though the message might legitimately retain its original 912 Message-ID:. 914 The format of an ENVID is free form. Although its creator might 915 choose to impose structure on the string, none is imposed by Internet 916 standards. By implication, the scope of the string is defined by the 917 domain name of the Return Address. 919 4. Services and Standards 921 The Internet Mail architecture comprises six basic types of 922 functionality, which are arranged to support a store-and-forward 923 service. As shown in Figure 5, each type can have multiple 924 instances, some of which represent specialized roles. This section 925 considers the activities and relationships among these components, 926 and the Internet Mail standards that apply to them. 928 Message 930 Message User Agent (MUA) 932 Author MUA (aMUA) 934 Recipient MUA (rMUA) 936 Message Submission Agent (MSA) 938 Author-focused MSA functions (aMSA) 940 MHS-focused MSA functions (hMSA) 942 Message Transfer Agent (MTA) 944 Message Delivery Agent (MDA) 945 Recipient-focused MDA functions (rMDA) 947 MHS-focused MDA functions (hMDA) 949 Message Store (MS) 951 Author MS (aMS) 953 Recipient MS (rMS) 955 This figure shows function modules and the standardized protocols 956 used between them. 958 ++========++ 959 || || +-------+ 960 ...........++ aMUA ||<............................+ Disp | 961 . || || +-------+ 962 . ++=+==+===++ ^ 963 . local,imap}| |{smtp,submission . 964 . +-----+ | | +--------+ . 965 . | aMS |<---+ | ........................>| Return | . 966 . +-----+ | . +--------+ . 967 . | . ***************** ^ . 968 . +-----V-.----*------------+ * . . 969 . MSA | +-------+ * +------+ | * . . 970 . | | aMSA +-(S)->| hMSA | | * . . 971 . | +-------+ * +--+---+ | * . . 972 V +------------*------+-----+ * . . 973 //==========\\ * V {smtp * . . 974 || MESSAGE || * +------+ * //===+===\\ . 975 ||----------|| MHS * | MTA | * || dsn || . 976 || ENVELOPE || * +--+---+ * \\=======// . 977 || smtp || * V {smtp * ^ ^ . 978 || CONTENT || * +------+ * . . //==+==\\ 979 || imf || * | MTA +....*...... . || mdn || 980 || mime || * +--+---+ * . \\=====// 981 \\==========// * smtp}| {local * . ^ 982 . MDA * | {lmtp * . . 983 . +----------------+------V-----+ * . . 984 . | +----------+ * +------+ | * . . 985 . | | | * | | +..*.......... . 986 . | | rMDA |<-(D)--+ hMDA | | * . 987 . | | | * | | |<.*........ . 988 . | +-+------+-+ * +------+ | * . . 989 . +------+---------*------------+ * . . 990 . smtp,local}| ***************** . . 991 . V . . 992 . +-----+ //===+===\\ . 993 . | rMS | || sieve || . 994 . +--+--+ \\=======// . 995 . |{imap,pop,local ^ . 996 . V . . 997 . ++==========++ . . 998 . || || . . 999 .......>|| rMUA ++........................... . 1000 || ++................................... 1001 ++==========++ 1003 Legend: --- lines indicate primary (possibly indirect) 1004 transfers or roles 1005 === boxes indicate data objects 1006 ... lines indicate supporting transfers or roles 1007 *** lines indicate aggregated service 1009 Figure 5: Protocols and Services 1011 4.1. Message Data 1013 The purpose of the Message Handling System (MHS) is to exchange an 1014 IMF message object among participants [RFC5322]. All of its 1015 underlying mechanisms serve to deliver that message from its Author 1016 to its Recipients. A message can be explicitly labeled as to its 1017 nature [RFC3458]. 1019 A message comprises a transit-handling envelope and the message 1020 content. The envelope contains information used by the MHS. The 1021 content is divided into a structured header and the body. The header 1022 comprises transit handling trace information and structured fields 1023 that are part of the Author's message content. The body can be 1024 unstructured lines of text or a tree of multi-media subordinate 1025 objects, called "body-parts" or attachments [RFC2045], [RFC2046], 1026 [RFC2047], [RFC4288], [RFC4289], [RFC2049]. 1028 In addition, Internet Mail has a few conventions for special control 1029 data, notably: 1031 Delivery Status Notification (DSN): 1033 A Delivery Status Notification (DSN) is a message that can be 1034 generated by the MHS (MSA, MTA, or MDA) and sent to the 1035 RFC5321.MailFrom address. An MDA and MTA are shown as sources 1036 of DSNs in Figure 5, and the destination is shown as Returns. 1037 DSNs provide information about message transit, such as 1038 transfer errors or successful delivery. [RFC3461] 1040 Message Disposition Notification (MDN): 1042 A Message Disposition Notification (MDN) is a message that 1043 provides information about post-delivery processing, such as 1044 indicating that the message has been displayed [RFC3798] or the 1045 form of content that can be supported [RFC3297]. It can be 1046 generated by an rMUA and is sent to the Disposition- 1047 Notification-To addresses. The mailbox for this is shown as 1048 Disp in Figure 5. 1050 Message Filtering (SIEVE): 1052 Sieve is a scripting language used to specify conditions for 1053 differential handling of mail, typically at the time of 1054 delivery [RFC5228]. Scripts can be conveyed in a variety of 1055 ways, such as a MIME part in a message. Figure 5 shows a Sieve 1056 script going from the rMUA to the MDA. However, filtering can 1057 be done at many different points along the transit path, and 1058 any one or more of them might be subject to Sieve directives, 1059 especially within a single ADMD. the Figure 5 shows only one 1060 relationship, for (relative) simplicity. 1062 4.1.1. Envelope 1064 Internet Mail has a fragmented framework for transit-related handling 1065 information. Information that is used directly by the MHS is called 1066 the "envelope." It directs handling activities by the transfer 1067 service and is carried in transfer service commands. That is, the 1068 envelope exists in the transfer protocol SMTP. [RFC5321] 1070 Trace information, such as RFC5322.Received, is recorded in the 1071 message header and is not subsequently altered. [RFC5322] 1073 4.1.2. Header Fields 1075 Header fields are attribute name/value pairs that cover an extensible 1076 range of email service parameters, structured user content, and user 1077 transaction meta-information. The core set of header fields is 1078 defined in [RFC5322]. It is common practice to extend this set for 1079 different applications. Procedures for registering header fields are 1080 defined in [RFC3864]. An extensive set of existing header field 1081 registrations is provided in [RFC4021]. 1083 One danger of placing additional information in header fields is that 1084 Gateways often alter or delete them. 1086 4.1.3. Body 1088 The body of a message might be lines of ASCII text or a 1089 hierarchically structured composition of multi-media body-part 1090 attachments, using MIME. [RFC2045], [RFC2046], [RFC2047], [RFC4288], 1091 [RFC2049] 1093 4.1.4. Identity References in a Message 1095 Table 1 lists the core identifiers present in a message during 1096 transit. 1098 +----------------------+----------------+---------------------------+ 1099 | Layer | Field | Set By | 1100 +----------------------+----------------+---------------------------+ 1101 | Message Body | MIME Header | Author | 1102 | Message header | From: | Author | 1103 | fields | | | 1104 | | Sender: | Originator | 1105 | | Reply-To: | Author | 1106 | | To:, CC:, BCC: | Author | 1107 | | Message-ID: | Originator | 1108 | | Received: | Originator, Relay, | 1109 | | | Receiver | 1110 | | Return-Path: | MDA, from MailFrom | 1111 | | Resent-*: | Mediator | 1112 | | List-Id: | Mediator | 1113 | | List-*: | Mediator | 1114 | SMTP | HELO/EHLO | Latest Relay Client | 1115 | | ENVID | Originator | 1116 | | MailFrom | Originator | 1117 | | RcptTo | Author | 1118 | | ORCPT | Originator | 1119 | IP | Source Address | Latest Relay Client | 1120 +----------------------+----------------+---------------------------+ 1122 Legend: Layer - The part of the email architecture that uses the 1123 identifier; Field - The protocol construct that contains the 1124 identifier; Set By - The actor role responsible for specifying the 1125 identifier value (and this can be different from the actor that 1126 performs the fill-in function for the protocol construct) 1128 Table 1: Layered Identities 1130 These are the most common address-related fields: 1132 RFC5322.From: Set by - Author 1134 Names and addresses for authors of the message content are 1135 listed in the From: field. 1137 RFC5322.Reply-To: Set by - Author 1139 If a Recipient sends a reply message that would otherwise use 1140 the RFC5322.From field addresses in the original message, the 1141 addresses in the RFC5322.Reply-To field are used instead. In 1142 other words, this field overrides the From: field for responses 1143 from Recipients. 1145 RFC5322.Sender: Set by - Originator 1147 This field specifies the address responsible for submitting the 1148 message to the transfer service. This field can be omitted if 1149 it contains the same address as RFC5322.From. However, 1150 omitting this field does not mean that no Sender is specified; 1151 it means that that header field is virtual and that the address 1152 in the From: field is to be used. 1154 Specification of the notifications Return addresses, which are 1155 contained in RFC5321.MailFrom, is made by the RFC5322.Sender. 1156 Typically the Return address is the same as the Sender address. 1157 However, some usage scenarios require it to be different. 1159 RFC5322.To/.CC: Set by - Author 1161 These fields specify MUA Recipient addresses. However, some or 1162 all of the addresses in these fields might not be present in 1163 the RFC5321.RcptTo commands. 1165 The distinction between To and CC is subjective. Generally, a 1166 To addressee is considered primary and is expected to take 1167 action on the message. A CC addressee typically receives a 1168 copy as a courtesy. 1170 RFC5322.BCC: Set by - Author 1172 A copy of the message might be sent to an addressee whose 1173 participation is not to be disclosed to the RFC5322.To or 1174 RFC5322.CC Recipients and, usually, not to the other BCC 1175 Recipients. The BCC: header field indicates a message copy to 1176 such a Recipient. Use of this field is discussed in [RFC5322]. 1178 RFC5321.HELO/.EHLO: Set by - Originator, MSA, MTA 1180 Any SMTP client -- including Originator, MSA, or MTA -- can 1181 specify its hosting domain identity for the SMTP HELO or EHLO 1182 command operation. 1184 RFC3461.ENVID: Set by - Originator 1186 The MSA can specify an opaque string, to be included in a DSN, 1187 as a means of assisting the Return address recipient in 1188 identifying the message that produced a DSN or message 1189 tracking. 1191 RFC5321.MailFrom: Set by - Originator 1193 This field is an end-to-end string that specifies an email 1194 address for receiving return control information, such as 1195 returned messages. The name of this field is misleading, 1196 because it is not required to specify either the Author or the 1197 actor responsible for submitting the message. Rather, the 1198 actor responsible for submission specifies the RFC5321.MailFrom 1199 address. Ultimately, the simple basis for deciding which 1200 address needs to be in the RFC5321.MailFrom field is to 1201 determine which address is to be informed about transfer-level 1202 problems (and possibly successes.) 1204 RFC5321.RcptTo: Set by - Author, Final MTA, MDA. 1206 This field specifies the MUA mailbox address of a Recipient. 1207 The string might not be visible in the message content header. 1208 For example, the IMF destination address header fields, such as 1209 RFC5322.To, might specify a mailing list mailbox, while the 1210 RFC5321.RcptTo address specifies a member of that list. 1212 RFC5321.ORCPT: Set by - Originator. 1214 This is an optional parameter to the RCPT command, indicating 1215 the original address to which the current RCPT TO address 1216 corresponds, after a mapping was performed during transit. An 1217 ORCPT is the only reliable way to correlate a DSN from a multi- 1218 recipient message transfer with the intended recipient. 1220 RFC5321.Received: Set by - Originator, Relay, Mediator, Dest 1222 This field contains trace information, including originating 1223 host, Relays, Mediators, and MSA host domain names and/or IP 1224 Addresses. 1226 RFC5321.Return-Path: Set by - Originator 1228 The MDA records the RFC5321.MailFrom address into the 1229 RFC5321.Return-Path field. 1231 RFC2919.List-Id: Set by - Mediator Author 1233 This field provides a globally unique mailing list naming 1234 framework that is independent of particular hosts. [RFC2919] 1236 The identifier is in the form of a domain name; however, the 1237 string usually is constructed by combining the two parts of an 1238 email address. The result is rarely a true domain name, listed 1239 in the domain name service, although it can be. 1241 RFC2369.List-*: Set by - Mediator Author 1243 [RFC2369] defines a collection of message header fields for use 1244 by mailing lists. In effect, they supply list-specific 1245 parameters for common mailing list user operations. The 1246 identifiers for these operations are for the list itself and 1247 the user-as-subscriber. [RFC2369] 1249 RFC0791.SourceAddr: Set by - The Client SMTP sending host 1250 immediately preceding the current receiving SMTP server. 1252 [RFC0791] defines the basic unit of data transfer for the 1253 Internet: the IP Datagram. It contains a Source Address field 1254 that specifies the IP Address for the host (interface) from 1255 which the datagram was sent. This information is set and 1256 provided by the IP layer, which makes it independent of mail- 1257 level mechanisms. As such, it is often taken to be 1258 authoritative, although it is possible to provide false 1259 addresses. 1261 4.2. User-Level Services 1263 Interactions at the user level entail protocol exchanges, distinct 1264 from those that occur at lower layers of the Internet Mail MHS 1265 architecture that is, in turn, above the Internet Transport layer. 1266 Because the motivation for email, and much of its use, is for 1267 interaction among people, the nature and details of these protocol 1268 exchanges often are determined by the needs of interpersonal and 1269 group communication. To accommodate the idiosyncratic behavior 1270 inherent in such communication, only subjective guidelines, rather 1271 than strict rules, can be offered for some aspects of system 1272 behavior. Mailing Lists provide particularly salient examples. 1274 4.2.1. Message User Agent (MUA) 1276 A Message User Agent (MUA) works on behalf of User actors and User 1277 applications. It is their representative within the email service. 1279 The Author MUA (aMUA) creates a message and performs initial 1280 submission into the transfer infrastructure via a Mail Submission 1281 Agent (MSA). It can also perform any creation- and posting-time 1282 archival in its Message Store (aMS). An MUA aMS can organize 1283 messages in many different ways. A common model uses aggregations, 1284 called "folders"; in IMAP they are called "mailboxes". This model 1285 allows a folder for messages under development (Drafts), a folder for 1286 messages waiting to be sent (Queued or Unsent), and a folder for 1287 messages that have been successfully posted for transfer (Sent). But 1288 none of these folders is required. For example, IMAP allows drafts 1289 to be stored in any folder; so no Drafts folder needs to be present. 1291 The Recipient MUA (rMUA) works on behalf of the Recipient to process 1292 received mail. This processing includes generating user-level 1293 disposition control messages, displaying and disposing of the 1294 received message, and closing or expanding the user communication 1295 loop by initiating replies and forwarding new messages. 1297 NOTE: Although not shown in Figure 5, an MUA itself can have a 1298 distributed implementation, such as a "thin" user interface 1299 module on a constrained device such as a smartphone, with most 1300 of the MUA functionality running remotely on a more capable 1301 server. An example of such an architecture might use IMAP 1302 [RFC3501] for most of the interactions between an MUA client 1303 and an MUA server. An approach for such scenarios is defined 1304 by [RFC4550]. 1306 A Mediator is special class of MUA. It performs message re-posting, 1307 as discussed in Section 2.1. 1309 An MUA can be automated, on behalf of a user who is not present at 1310 the time the MUA is active. One example is a bulk sending service 1311 that has a timed-initiation feature. These services are not to be 1312 confused with a mailing list Mediator, since there is no incoming 1313 message triggering the activity of the automated service. 1315 A popular and problematic MUA is an automatic responder, such as one 1316 that sends out-of-office notices. This behavior might be confused 1317 with that of a Mediator, but this MUA is generating a new message. 1318 Automatic responders can annoy users of mailing lists unless they 1319 follow [RFC3834]. 1321 The identity fields are relevant to a typical MUA: 1323 RFC5322.From 1325 RFC5322.Reply-To 1327 RFC5322.Sender 1329 RFC5322.To, RFC5322.CC 1331 RFC5322.BCC 1333 4.2.2. Message Store (MS) 1335 An MUA can employ a long-term Message Store (MS). Figure 5 depicts 1336 an Author's MS (aMS) and a Recipient's MS (rMS). An MS can be 1337 located on a remote server or on the same machine as the MUA. 1339 An MS acquires messages from an MDA either proactively by a local 1340 mechanism or even with a standardized mechanism such as SMTP(!) or 1341 reactively by using POP or IMAP. The MUA accesses the MS either by a 1342 local mechanism or by using POP or IMAP. Using POP for individual 1343 message accesses, rather than for bulk transfer, is relatively rare 1344 and inefficient. 1346 4.3. MHS-Level Services 1348 4.3.1. Mail Submission Agent (MSA) 1350 A Mail Submission Agent (MSA) accepts the message submitted by the 1351 aMUA and enforces the policies of the hosting ADMD and the 1352 requirements of Internet standards. An MSA represents an unusual 1353 functional dichotomy. It represents the interests of the Author 1354 (aMUA) during message posting, to facilitate posting success; it also 1355 represents the interests of the MHS. In the architecture, these 1356 responsibilities are modeled, as shown in Figure 5, by dividing the 1357 MSA into two sub-components, aMSA and hMSA, respectively. Transfer 1358 of responsibility for a single message, from an Author's environment 1359 to the MHS, is called "posting". In Figure 5 it is marked as the (S) 1360 transition, within the MSA. 1362 The hMSA takes transit responsibility for a message that conforms to 1363 the relevant Internet standards and to local site policies. It 1364 rejects messages that are not in conformance. The MSA performs final 1365 message preparation for submission and effects the transfer of 1366 responsibility to the MHS, via the hMSA. The amount of preparation 1367 depends upon the local implementations. Examples of oMSA tasks 1368 include adding header fields, such as Date: and Message-ID:, and 1369 modifying portions of the message from local notations to Internet 1370 standards, such as expanding an address to its formal IMF 1371 representation. 1373 Historically, standards-based MUA/MSA message postings have used 1374 SMTP. [RFC5321] The standard currently preferred is SUBMISSION. 1375 [RFC4409] Although SUBMISSION derives from SMTP, it uses a separate 1376 TCP port and imposes distinct requirements, such as access 1377 authorization. 1379 These identities are relevant to the MSA: 1381 RFC5321.HELO/.EHLO 1383 RFC3461.ENVID 1385 RFC5321.MailFrom 1387 RFC5321.RcptTo 1389 RFC5321.Received 1391 RFC0791.SourceAddr 1393 4.3.2. Message Transfer Agent (MTA) 1395 A Message Transfer Agent (MTA) relays mail for one application-level 1396 "hop." It is like a packet-switch or IP router in that its job is to 1397 make routing assessments and to move the message closer to the 1398 Recipients. Of course, email objects are typically much larger than 1399 the payload of a packet or datagram, and the end-to-end latencies are 1400 typically much higher. Relaying is performed by a sequence of MTAs, 1401 until the message reaches a destination MDA. Hence, an MTA 1402 implements both client and server MTA functionality; it does not 1403 change addresses in the envelope or reformulate the editorial 1404 content. A change in data form, such as to MIME Content-Transfer- 1405 Encoding, is within the purview of an MTA, but removal or replacement 1406 of body content is not. An MTA also adds trace information. 1407 [RFC2505] 1409 NOTE: Within a destination ADMD, email relaying modules can 1410 make a variety of changes to the message, prior to delivery. 1411 In such cases, these modules are acting as Gateways, rather 1412 than MTAs. 1414 Internet Mail uses SMTP [RFC5321], [RFC2821], [RFC0821] primarily to 1415 effect point-to-point transfers between peer MTAs. Other transfer 1416 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1417 most network layer mechanisms, the Internet Mail SMTP supports a 1418 basic level of reliability, by virtue of providing for retransmission 1419 after a temporary transfer failure. Unlike typical packet switches 1420 (and Instant Messaging services), Internet Mail MTAs are expected to 1421 store messages in a manner that allows recovery across service 1422 interruptions, such as host system shutdown. The degree of such 1423 robustness and persistence by an MTA can vary. The base SMTP 1424 specification provides a framework for protocol response codes. An 1425 extensible enhancement to this framework is defined in [RFC5248] 1427 Although quite basic, the dominant routing mechanism for Internet 1428 Mail is the DNS MX record [RFC1035], which specifies an MTA through 1429 which the queried domain can be reached. This mechanism presumes a 1430 public, or at least a common, backbone that permits any attached MTA 1431 to connect to any other. 1433 MTAs can perform any of these well-established roles: 1435 Boundary MTA: An MTA that is part of an ADMD and interacts with 1436 MTAs in other ADMDs. This is also called a Border MTA. There 1437 can be different Boundary MTAs, according to the direction of 1438 mail-flow. 1440 Outbound MTA: An MTA that relays messages to other ADMDs. 1442 Inbound MTA: An MTA that receives inbound SMTP messages from 1443 MTA Relays in other ADMDs, for example, an MTA running on 1444 the host listed as the target of an MX record. 1446 Final MTA: The MTA that transfers a message to the MDA. 1448 These identities are relevant to the MTA: 1450 RFC5321.HELO/.EHLO 1452 RFC3461.ENVID 1454 RFC5321.MailFrom 1455 RFC5321.RcptTo 1457 RFC5322.Received: Set by - Relay Server 1459 RFC0791.SourceAddr 1461 4.3.3. Mail Delivery Agent (MDA) 1463 A transfer of responsibility from the MHS to a Recipient's 1464 environment (mailbox) is called "delivery." In the architecture, as 1465 depicted in Figure 5, delivery takes place within a Mail Delivery 1466 Agent (MDA) and is shown as the (D) transition from the MHS-oriented 1467 MDA component (hMDA) to the Recipient-oriented MDA component (rMDA). 1469 An MDA can provide distinctive, address-based functionality, made 1470 possible by its detailed information about the properties of the 1471 destination address. This information might also be present 1472 elsewhere in the Recipient's ADMD, such as at an organizational 1473 border (Boundary) Relay. However, it is required for the MDA, if 1474 only because the MDA is required to know where to deliver the 1475 message. 1477 Like an MSA, an MDA serves two roles, as depicted in Figure 5. 1478 Formal transfer of responsibility, called "delivery", is effected 1479 between the two components that embody these roles as shows as "(D)" 1480 in Figure 5. The MHS portion (hMDA) primarily functions as a server 1481 SMTP engine. A common additional role is to re-direct the message to 1482 an alternative address, as specified by the recipient addressee's 1483 preferences. The job of the recipient portion of the MDA (rMDA) is 1484 to perform any delivery actions that the Recipient specifies. 1486 Transfer into the MDA is accomplished by a normal MTA transfer 1487 mechanism. Transfer from an MDA to an MS uses an access protocol, 1488 such as POP or IMAP. 1490 NOTE: The term "delivery" can refer to the formal, MHS function 1491 specified here or to the first time a message is displayed to a 1492 Recipient. A simple, practical test for whether the MHS-based 1493 definition applies is whether a DSN can be generated. 1495 These identities are relevant to the MDA: 1497 RFC5321.Return-Path: Set by - Author Originator or Mediator 1498 Originator 1500 The MDA records the RFC5321.MailFrom address into the 1501 RFC5321.Return-Path field. 1503 RFC5322.Received: Set by - MDA server 1505 An MDA can record a Received: header field to indicate trace 1506 information, including source host and receiving host domain 1507 names and/or IP Addresses. 1509 4.4. Transition Modes 1511 From the origination site to the point of delivery, Internet Mail 1512 usually follows a "push" model. That is, the actor that holds the 1513 message initiates transfer to the next venue, typically with SMTP 1514 [RFC5321] or LMTP [RFC2033]. With a "pull" model, the actor that 1515 holds the message waits for the actor in the next venue to initiate a 1516 request for transfer. Standardized mechanisms for pull-based MHS 1517 transfer are ETRN [RFC1985] and ODMR [RFC2645]. 1519 After delivery, the Recipient's MUA (or MS) can gain access by having 1520 the message pushed to it or by having the receiver of access pull the 1521 message, such as by using POP [RFC1939] and IMAP [RFC3501]. 1523 4.5. Implementation and Operation 1525 A discussion of any interesting system architecture often bogs down 1526 when architecture and implementation are confused. An architecture 1527 defines the conceptual functions of a service, divided into discrete 1528 conceptual modules. An implementation of that architecture can 1529 combine or separate architectural components, as needed for a 1530 particular operational environment. For example, a software system 1531 that primarily performs message relaying is an MTA, yet it might also 1532 include MDA functionality. That same MTA system might be able to 1533 interface with non-Internet email services and thus perform both as 1534 an MTA and as a Gateway. 1536 Similarly, implemented modules might be configured to form 1537 elaborations of the architecture. An interesting example is a 1538 distributed MS. One portion might be a remote server and another 1539 might be local to the MUA. As discussed in [RFC1733], there are 1540 three operational relationships among such MSs: 1542 Online: The MS is remote, and messages are accessible only when 1543 the MUA is attached to the MS so that the MUA will re-fetch all 1544 or part of a message, from one session to the next. 1546 Offline: The MS is local to the user, and messages are 1547 completely moved from any remote store, rather than (also) 1548 being retained there. 1550 Disconnected: An rMS and a uMS are kept synchronized, for all or 1551 part of their contents, while they are connected. When they 1552 are disconnected, mail can arrive at the rMS and the user can 1553 make changes to the uMS. The two stores are re-synchronized 1554 when they are reconnected. 1556 5. Mediators 1558 Basic message transfer from Author to Recipients is accomplished by 1559 using an asynchronous store-and-forward communication infrastructure 1560 in a sequence of independent transmissions through some number of 1561 MTAs. A very different task is a sequence of postings and deliveries 1562 through Mediators. A Mediator forwards a message, through a re- 1563 posting process. The Mediator shares some functionality with basic 1564 MTA relaying, but has greater flexibility in both addressing and 1565 content than is available to MTAs. 1567 This is the core set of message information that is commonly set by 1568 all types of Mediators: 1570 RFC5321.HELO/.EHLO: Set by - Mediator Originator 1572 RFC3461.ENVID: Set by - Mediator Originator 1574 RFC5321.RcptTo: Set by - Mediator Author 1576 RFC5321.Received: Set by - Mediator Dest 1578 The Mediator can record received information, to indicate the 1579 delivery to the original address and submission to the alias 1580 address. The trace of Received: header fields can include 1581 everything from original posting, through relaying, to final 1582 delivery. 1584 The aspect of a Mediator that distinguishes it from any other MUA 1585 creating a message is that a Mediator preserves the integrity and 1586 tone of the original message, including the essential aspects of its 1587 origination information. The Mediator might also add commentary. 1589 Examples of MUA messages that a Mediator does not create include: 1591 New message that forwards an existing message: 1593 Although this action provides a basic template for a class of 1594 Mediators, its typical occurrence is not, itself, an example of 1595 a Mediator. The new message is viewed as being from the actor 1596 that is doing the forwarding, rather than from the original 1597 Author. 1599 A new message encapsulates the original message and is seen as 1600 from the new Originator. This Mediator Originator might add 1601 commentary and can modify the original message content. 1602 Because the forwarded message is a component of the message 1603 sent by the new Originator, the new message creates a new 1604 dialogue. However the final Recipient still sees the contained 1605 message as from the original Author. 1607 Reply: 1609 When a Recipient responds to the Author of a message, the new 1610 message is not typically viewed as a forwarding of the 1611 original. Its focus is the new content, although it might 1612 contain all or part of the material from the original message. 1613 The earlier material is merely contextual and secondary. This 1614 includes automated replies, such as vacation out-of-office 1615 notices, as discussed in Section 4.2.1. 1617 Annotation: 1619 The integrity of the original message is usually preserved, but 1620 one or more comments about the message are added in a manner 1621 that distinguishes commentary from original text. The primary 1622 purpose of the new message is to provide commentary from a new 1623 Author, similar to a Reply. 1625 The remainder of this section describes common examples of 1626 Mediators. 1628 5.1. Alias 1630 One function of an MDA is to determine the internal location of a 1631 mailbox in order to perform delivery. An Alias is a simple re- 1632 addressing facility that provides one or more new Internet Mail 1633 addresses, rather than a single, internal one; the message continues 1634 through the transfer service, for delivery to one or more alternate 1635 addresses. Although typically implemented as part of an MDA, this 1636 facility is a Recipient function. It resubmits the message, although 1637 all handling information except the envelope recipient 1638 (rfc5321.RcptTo) address is retained. In particular, the Return 1639 address (rfc5321.MailFrom) is unchanged. 1641 What is distinctive about this forwarding mechanism is how closely it 1642 resembles normal MTA store-and-forward relaying. Its only 1643 significant difference is that it changes the RFC5321.RcptTo value. 1644 Because this change is so small, aliasing can be viewed as a part of 1645 the lower-level mail relaying activity. However, this small change 1646 has a large semantic impact: The designated recipient has chosen a 1647 new recipient. 1649 NOTE: When the replacement list includes more than one address, 1650 the alias is increasingly likely to have delivery problems. 1651 Any problem reports go to the original Author, not the 1652 administrator of the alias entry. This makes it more difficult 1653 to resolve the problem, because the original Author has no 1654 knowledge of the Alias mechanism. 1656 Including the core set of message information listed at the beginning 1657 of this section, Alias typically changes: 1659 RFC5322.To/.CC/.BCC: Set by - Author 1661 These fields retain their original addresses. 1663 RFC5321.MailFrom: Set by - Author 1665 The benefit of retaining the original MailFrom value is to 1666 ensure that an actor related to the originating ADMD knows 1667 there has been a delivery problem. On the other hand, the 1668 responsibility for handling problems, when transiting from the 1669 original recipient mailbox to the alias mailbox usually lies 1670 with that original Recipient, because the Alias mechanism is 1671 strictly under that Recipient's control. Retaining the 1672 original MailFrom address prevents this. 1674 5.2. ReSender 1676 Also called the ReDirector, the ReSender's actions differ from 1677 forwarding because the Mediator "splices" a message's addressing 1678 information to connect the Author of the original message with the 1679 Recipient of the new message. This connection permits them to have 1680 direct exchange, using their normal MUA Reply functions, while also 1681 recording full reference information about the Recipient who served 1682 as a Mediator. Hence, the new Recipient sees the message as being 1683 from the original Author, even if the Mediator adds commentary. 1685 Including the core set of message information listed at the beginning 1686 of this section, these identities are relevant to a resent message: 1688 RFC5322.From: Set by - original Author 1690 Names and addresses for the original Author of the message 1691 content are retained. The free-form (display-name) portion of 1692 the address might be modified to provide informal reference to 1693 the ReSender. 1695 RFC5322.Reply-To: Set by - original Author 1697 If this field is present in the original message, it is 1698 retained in the resent message. 1700 RFC5322.Sender: Set by - Author's Originator or Mediator 1701 Originator. 1703 RFC5322.To/.CC/.BCC: Set by - original Author 1705 These fields specify the original message Recipients. 1707 RFC5322.Resent-From: Set by - Mediator Author 1709 This address is of the original Recipient who is redirecting 1710 the message. Otherwise, the same rules apply to the Resent- 1711 From: field as to an original RFC5322.From field. 1713 RFC5322.Resent-Sender: Set by - Mediator Originator 1715 The address of the actor responsible for resubmitting the 1716 message. As with RFC5322.Sender, this field can be omitted 1717 when it contains the same address as RFC5322.Resent-From. 1719 RFC5322.Resent-To/-CC/-BCC: Set by: Mediator Author 1721 The addresses of the new Recipients who are now able to reply 1722 to the original author. 1724 RFC5321.MailFrom: Set by - Mediator Originator 1726 The actor responsible for resubmission (RFC5322.Resent-Sender) 1727 is also responsible for specifying the new MailFrom address. 1729 5.3. Mailing Lists 1731 A Mailing List receives messages as an explicit addressee and then 1732 re-posts them to a list of subscribed members. The Mailing List 1733 performs a task that can be viewed as an elaboration of the ReSender. 1734 In addition to sending the new message to a potentially large number 1735 of new Recipients, the Mailing List can modify content, for example, 1736 by deleting attachments, converting the format, and adding list- 1737 specific comments. Mailing Lists also archive messages posted by 1738 Authors. Still the message retains characteristics of being from the 1739 original Author. 1741 Including the core set of message information listed at the beginning 1742 of this section, these identities are relevant to a mailing list 1743 processor, when submitting a message: 1745 RFC2919.List-Id: Set by - Mediator Author 1747 RFC2369.List-*: Set by - Mediator Author 1749 RFC5322.From: Set by - original Author 1751 Names and email addresses for the original Author of the 1752 message content are retained. 1754 RFC5322.Reply-To: Set by - Mediator or original Author 1756 Although problematic, it is common for a Mailing List to assign 1757 its own addresses to the Reply-To: header field of messages 1758 that it posts. This assignment is intended to ensure that 1759 replies go to all list members, rather than to only the 1760 original Author. As a User actor, a Mailing List is the Author 1761 of the new message and can legitimately set the Reply-To: 1762 value. As a Mediator attempting to represent the message on 1763 behalf of its original Author, creating or modifying a 1764 Reply-To: field can be viewed as violating that Author's 1765 intent. When the Reply-To is modified in this way, a reply 1766 that is meant only for the original Author will instead go to 1767 the entire list. When the Mailing List does not set the field, 1768 a reply meant for the entire list can instead go only to the 1769 original Author. At best, either choice is a matter of group 1770 culture for the particular list. 1772 RFC5322.Sender: Set by - Author Originator or Mediator 1773 Originator 1775 This field usually specifies the address of the actor 1776 responsible for Mailing List operations. Mailing Lists that 1777 operate in a manner similar to a simple MTA Relay preserve as 1778 much of the original handling information as possible, 1779 including the original RFC5322.Sender field. (Note that this 1780 mode of operation causes the Mailing List to behave much like 1781 an Alias, with a possible difference in number of new 1782 addressees.) 1784 RFC5322.To/.CC: Set by - original Author 1786 These fields usually contain the original list of Recipient 1787 addresses. 1789 RFC5321.MailFrom: Set by - Mediator Originator 1791 Because a Mailing List can modify the content of a message in 1792 any way, it is responsible for that content; that is, it is an 1793 Author. As such, the Return Address is specified by the 1794 Mailing List. Although it is plausible for the Mailing List to 1795 re-use the Return Address employed by the original Originator, 1796 notifications sent to that address after a message has been 1797 processed by a Mailing List could be problematic. 1799 5.4. Gateways 1801 A Gateway performs the basic routing and transfer work of message 1802 relaying, but it also is permitted to modify content, structure, 1803 address, or attributes as needed to send the message into a messaging 1804 environment that operates under different standards or potentially 1805 incompatible policies. When a Gateway connects two differing 1806 messaging services, its role is easy to identify and understand. 1807 When it connects environments that follow similar technical 1808 standards, but significantly different administrative policies, it is 1809 easy to view a Gateway as merely an MTA. 1811 The critical distinction between an MTA and a Gateway is that a 1812 Gateway can make substantive changes to a message to map between the 1813 standards. In virtually all cases, this mapping results in some 1814 degree of semantic loss. The challenge of Gateway design is to 1815 minimize this loss. Standardized gateways to Internet Mail are 1816 facsimile [RFC4143], voicemail [RFC3801], and MMS [RFC4356] 1817 A Gateway can set any identity field available to an MUA. Including 1818 the core set of message information listed at the beginning of this 1819 section, these identities are typically relevant to Gateways: 1821 RFC5322.From: Set by - original Author 1823 Names and addresses for the original Author of the message 1824 content are retained. As for all original addressing 1825 information in the message, the Gateway can translate addresses 1826 as required to continue to be useful in the target environment. 1828 RFC5322.Reply-To: Set by - original Author 1830 It is best for a Gateway to retain this information, if it is 1831 present. The ability to perform a successful reply by a 1832 Recipient is a typical test of Gateway functionality. 1834 RFC5322.Sender: Set by - Author Originator or Mediator 1835 Originator 1837 This field can retain the original value or can be set to a new 1838 address. 1840 RFC5322.To/.CC/.BCC: Set by - original Recipient 1842 These fields usually retain their original addresses. 1844 RFC5321.MailFrom: Set by - Author Originator or Mediator 1845 Originator 1847 The actor responsible for handling the message can specify a 1848 new address to receive handling notices. 1850 5.5. Boundary Filter 1852 To enforce security boundaries, organizations can subject messages to 1853 analysis, for conformance with its safety policies. An example is 1854 detection of content classed as spam or a virus. A filter might 1855 alter the content, to render it safe, such as by removing content 1856 deemed unacceptable. Typically, these actions add content to the 1857 message that records the actions. 1859 6. Considerations 1860 6.1. Security Considerations 1862 This document describes the existing Internet Mail architecture. It 1863 introduces no new capabilities. The security considerations of this 1864 deployed architecture are documented extensively in the technical 1865 specifications referenced by this document. These specifications 1866 cover classic security topics, such as authentication and privacy. 1867 For example, email transfer protocols can use standardized mechanisms 1868 for operation over authenticated and/or encrypted links, and message 1869 content has similar protection standards available. Examples of such 1870 mechanisms include SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP 1871 [RFC4880], and S/MIME [RFC3851]. 1873 The core of the Internet Mail architecture does not impose any 1874 security requirements or functions on the end-to-end or hop-by-hop 1875 components. For example, it does not require participant 1876 authentication and does not attempt to prevent data disclosure. 1878 Particular message attributes might expose specific security 1879 considerations. For example, the blind carbon copy feature of the 1880 architecture invites disclosure concerns, as discussed in section 7.2 1881 of [RFC5321] and section 5 of [RFC5322]. Transport of text or non- 1882 text content in this architecture has security considerations that 1883 are discussed in [RFC5322], [RFC2045], [RFC2046], and [RFC4288] as 1884 well as the security considerations present in the IANA media types 1885 registry for the respective types. 1887 Agents that automatically respond to email raise significant security 1888 considerations, as discussed in [RFC3834]. Gateway behaviors affect 1889 end-to-end security services, as discussed in [RFC2480]. Security 1890 considerations for boundary filters are discussed in [RFC5228]. 1892 See section 7.1 of [RFC5321] for a discussion of the topic of 1893 origination validation. As mentioned in Section 4.1.4, it is common 1894 practice for components of this architecture to use the 1895 [RFC0791].SourceAddr to make policy decisions [RFC2505], although the 1896 address can be "spoofed". It is possible to use it without 1897 authorization. SMTP and Submission authentication [RFC4954], 1898 [RFC4409] provide more secure alternatives. 1900 The discussion of trust boundaries, ADMDs, actors, roles, and 1901 responsibilities in this document highlights the relevance and 1902 potential complexity of security factors for operation of an Internet 1903 mail service. The core design of Internet Mail to encourage open and 1904 casual exchange of messages has met with scaling challenges, as the 1905 population of email participants has grown to include those with 1906 problematic practices. For example, spam, as defined in [RFC2505], 1907 is a by-product of this architecture. A number of standards track or 1908 BCP documents on the subject have been issued. [RFC2505], [RFC5068], 1909 [RFC3685] 1911 6.2. IANA Considerations 1913 This document has no actions for IANA. 1915 6.3. Internationalization 1917 The core Internet email standards are based on the use of US-ASCII. 1918 That is SMTP [RFC5321] and IMF [RFC5322], as well as their 1919 predecessors. They describe the transport and composition of 1920 messages as composed strictly of US-ASCII 7-bit encoded characters. 1921 The standards have been incrementally enhanced to allow for 1922 characters outside of this limited set, while retaining mechanisms 1923 for backwards-compatibility. Specifically: 1925 o The MIME specifications [RFC2045], [RFC2046], [RFC2047] and 1926 [RFC2049] allow for the use of coded character sets and character 1927 encoding schemes ("charsets" in MIME terminology) other than US- 1928 ASCII. MIME's [RFC2046] allows the textual content of a message 1929 to have a label affixed that specifies the charset used in that 1930 content. Equally MIME's [RFC2047] allows the textual content of 1931 certain header fields in a message to be similarly labeled. 1932 However, since messages might be transported over SMTP 1933 implementations only capable of transporting 7-bit encoded 1934 characters, MIME's [RFC2045] also provides for "content transfer 1935 encoding" so that characters of other charsets can be re-encoded 1936 as an overlay to US-ASCII. 1938 o MIME's [RFC2045] allows for the textual content of a message to be 1939 in an 8-bit character encoding scheme. In order to transport 1940 these without re-encoding them, the SMTP specification supports an 1941 option [RFC1652] that permits the transport of such textual 1942 content. However, the [RFC1652] option does not address the use 1943 of 8-bit content in message header fields, and therefore [RFC2047] 1944 encoding is still required for those. 1946 o A series of experimental protocols on Email Address 1947 Internationalization (EAI) have been released that extend SMTP and 1948 IMF to allow for 8-bit encoded characters to appear in addresses 1949 and other information throughout the header fields of messages. 1950 [RFC5335] specifies the format of such message header fields 1951 (which encode the characters in UTF-8), and [RFC5336] specifies an 1952 SMTP option for the transport of these messages. 1954 o MIME's [RFC2045] and [RFC2046] allows for the transport of true 1955 multimedia material; such material enables internationalization 1956 because it is not restricted to any particular language or locale. 1958 o The formats for delivery status notifications (DSNs -- [RFC3462], 1959 [RFC3463], [RFC3464]) and message disposition notifications (MDNs 1960 -- [RFC3798]) include both a structured and unstructured 1961 representation of the notification. In the event that the 1962 unstructured representation is in the wrong language or is 1963 otherwise unsuitable for use, this allows an MUA to construct its 1964 own appropriately localized representation of notification for 1965 display to the user. 1967 o POP and IMAP have no difficulties with handling MIME messages, 1968 including ones containing 8bit, and therefore are not a source of 1969 of internationalization issues. 1971 Hence, the use of UTF-8 is fully established in existing Internet 1972 mail. However support for long-standing encoding forms is retained 1973 and is still used. 1975 7. References 1977 7.1. Normative 1979 [RFC0791] Postel, J., "Internet Protocol", RFC 791, 1981 September. 1981 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1982 STD 13, RFC 1034, November 1987. 1984 [RFC1035] Mockapetris, P., "Domain names - implementation and 1985 specification", STD 13, RFC 1035, November 1987. 1987 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1988 STD 53, RFC 1939, May 1996. 1990 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1991 Extensions (MIME) Part One: Format of Internet Message 1992 Bodies", RFC 2045, November 1996. 1994 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1995 Extensions (MIME) Part Two: Media Types", RFC 2046, 1996 November 1996. 1998 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1999 Part Three: Message Header Extensions for Non-ASCII Text", 2000 RFC 2047, November 1996. 2002 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2003 Extensions (MIME) Part Five: Conformance Criteria and 2004 Examples", RFC 2049, November 1996. 2006 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 2007 Specification", RFC 2181, July 1997. 2009 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 2010 for Core Mail List Commands and their Transport through 2011 Message Header Fields", RFC 2369, July 1998. 2013 [RFC2645] Gellens, R., "On-Demand Mail Relay (ODMR) SMTP with 2014 Dynamic IP Addresses", RFC 2645, August 1999. 2016 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 2017 and Namespace for the Identification of Mailing Lists", 2018 RFC 2919, March 2001. 2020 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet 2021 Mail", RFC 3192, October 2001. 2023 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 2024 Negotiation for Messaging Services based on Email", 2025 RFC 3297, July 2002. 2027 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 2028 Context for Internet Mail", RFC 3458, January 2003. 2030 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 2031 Extension for Delivery Status Notifications (DSNs)", 2032 RFC 3461, January 2003. 2034 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the 2035 Reporting of Mail System Administrative Messages", 2036 RFC 3462, January 2003. 2038 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 2039 RFC 3463, January 2003. 2041 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 2042 4rev1", RFC 3501, March 2003. 2044 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 2045 Notification", RFC 3798, May 2004. 2047 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 2048 Electronic Mail", RFC 3834, August 2004. 2050 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2051 Procedures for Message Header Fields", RFC 3864, 2052 September 2004. 2054 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 2055 Header Fields", RFC 4021, March 2005. 2057 [RFC4288] Freed, N., Klensin, J., and J. Postel, "Media Type 2058 Specifications and Registration Procedures", BCP 13, 2059 RFC 4288, December 2005. 2061 [RFC4289] Freed, N., Klensin, J., and J. Postel, "Multipurpose 2062 Internet Mail Extensions (MIME) Part Four: Registration 2063 Procedures", BCP 13, RFC 4289, December 2005. 2065 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 2066 RFC 4409, April 2006. 2068 [RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support 2069 Diverse Service Environments (Lemonade) Profile", 2070 June 2006. 2072 [RFC5228] Showalter, T., "Sieve: A Mail Filtering Language", 2073 RFC 5228. 2075 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 2076 Mail System Status Codes", RFC 5248, June 2008. 2078 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2079 October 2008. 2081 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2082 October 2008. 2084 7.2. Informative 2086 [RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, 2087 "Standard for the Format of ARPA Network Text Messages", 2088 RFC 733, November 1977. 2090 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 2091 RFC 821, August 1982. 2093 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 2094 text messages", STD 11, RFC 822, August 1982. 2096 [RFC1506] Houttuin, J., "A Tutorial on Gatewaying between X.400 and 2097 Internet Mail", RFC 1506, August 1993. 2099 [RFC1652] Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and 2100 D. Crocker, "SMTP Service Extension for 8bit- 2101 MIMEtransport", RFC 1652, July 1994. 2103 [RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4", 2104 December 1994. 2106 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 2107 RFC 1767, March 1995. 2109 [RFC1985] De Winter, J., "SMTP Service Extension for Remote 2110 Message Queue Starting", August 1996. 2112 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 2113 October 1996. 2115 [RFC2142] Crocker, D., "Mailbox Names for Common services, Roles and 2116 Functions", RFC 2142, May 1997. 2118 [RFC2442] Freed, N., Newman, D., Belissen, J., and M. Hoy, "The 2119 Batch SMTP Media Type", RFC 2442, November 1998. 2121 [RFC2480] Freed, N., "Gateways and MIME Security Multiparts", 2122 RFC 2480, January 1999. 2124 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 2125 RFC 2505, February 1999. 2127 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 2128 April 2001. 2130 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 2131 April 2001. 2133 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 2134 Transport Layer Security", RFC 3207, February 2002. 2136 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 2137 for Delivery Status Notifications", RFC 3464, 2138 January 2003. 2140 [RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest 2141 Extensions", RFC 3685, February 2004. 2143 [RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 2144 Mail - version 2 (VPIMv2)", RFC 3801, June 2004. 2146 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 2147 Extensions (S/MIME) Version 3.1 Message Specification", 2148 RFC 3851, July 2004. 2150 [RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for 2151 Message Tracking", RFC 3885, September 2004. 2153 [RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for 2154 Internet Mail: FFPIM", December 2005. 2156 [RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail 2157 (IFAX) Service of ENUM", RFC 4143, November 2005. 2159 [RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging 2160 Service (MMS) and Internet Mail", RFC 4356, January 2006. 2162 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2163 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 2165 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 2166 Extension for Authentication", RFC 4954, July 2007. 2168 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 2169 E. Allman, "Email Submission Operations: Access and 2170 Accountability Requirements", RFC 5068, BCP 134, Nov 2007. 2172 [RFC5335] Abel, Y., Ed., "Internationalized Email Headers", 2173 RFC 5335, September 2008. 2175 [RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for 2176 Internationalized Email Addresses", RFC 5336, 2177 September 2008. 2179 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 2180 "Tussle in Cyberspace: Defining Tomorrow's Internet", 2181 ACM SIGCOMM, 2002. 2183 Appendix A. Acknowledgements 2185 This work began in 2004 and has evolved through numerous rounds of 2186 community review; it derives from a section in an early version of 2187 [RFC5068]. Over its 5 years of development, the draft has gone 2188 through 14 incremental versions, with vigorous community review that 2189 produced many substantive changes. Review was performed in the IETF 2190 and other email technical venues. Although not a formal activity of 2191 the IETF, issues with the document's contents were resolved using the 2192 classic style of IETF community open, group decision-making. The 2193 document is already cited in other work, such as for IMAP and Sieve 2194 specifications and for academic classwork. The step of standardizing 2195 is useful to provide a solid and stable reference to the Internet's 2196 now-complex email service. 2198 Details of the Originator actor role was greatly clarified during 2199 discussions in the IETF's Marid working group. 2201 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 2202 insight on the framework and details of the original drafts, as did 2203 Chris Newman for the final versions, while also serving as cognizant 2204 Area Director for the document. Tony Hansen served as document 2205 shepherd, through the IETF process. 2207 Later reviews and suggestions were provided by Eric Allman, Nathaniel 2208 Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, 2209 Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John 2210 Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, 2211 Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. 2212 Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg 2213 Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani, and Hans 2214 Lachman. 2216 Diligent early proof-reading was performed by Bruce Lilly. Diligent 2217 professional technical editing was provided by Susan Hunziker. 2219 The final stages of development for this document were guided by a 2220 design team comprising: Alexey Melnikov, Pete Resnick, Carl S. 2221 Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen and Tony 2222 Finch. Pete Resnick developed the final version of the section on 2223 internationalization. 2225 Index 2226 12 2228 7 2229 7-bit 46 2231 A 2232 accountability 13 2233 accountable 14-15 2234 Actor 2235 Administrative 15 2236 Author 11 2237 Consumer 16 2238 Edge 16 2239 Gateway 15 2240 Originator 13 2241 Recipient 11 2242 Return Handler 11 2243 Transit 16 2244 Actors 2245 MHS 12 2246 ADMD 13, 15-16, 20, 26, 32, 39 2247 Administrative Actors 15 2248 Administrative Management Domain 13 2249 aMSA 32 2250 Author 11-12 2251 author 36 2253 B 2254 body-parts 25 2255 bounce handler 11 2256 boundary 16 2258 C 2259 charset 46 2260 Consumer Actor 16 2261 content 12, 14-15, 21, 25, 33 2263 D 2264 delivery 5, 11-12, 14-15, 19, 25-26, 36, 39 2265 Discussion of document 8 2266 DSN 46 2268 E 2269 EAI 46 2270 Edge Actor 16 2271 encoding 46 2272 end-to-end 5 2273 envelope 12, 14, 22, 25-26, 33, 39 2274 ETRN 36 2276 G 2277 Gateway 12, 15 2279 H 2280 header 25 2281 hMSA 32 2283 I 2284 IMAP 25, 32, 35-36, 46 2285 IMF 20, 25, 46 2286 Internet Mail 5 2288 L 2289 LMTP 25, 36 2290 local-part 19 2292 M 2293 Mail 5 2294 Mail From 39 2295 Mail Submission Agent 13 2296 mailbox 39 2297 MDA 25, 39 2298 MDN 11, 25, 46 2299 message 7, 25 2300 Message Disposition Notification 11 2301 Message Handling Service 5 2302 Message Handling System 12 2303 Message Transfer Agent 5 2304 Message User Agent 5 2305 MHS 5, 11-14, 22-23, 25-26 2306 Actors 12 2307 MIME 25, 46 2308 MS 25 2309 MSA 13, 25, 32 2310 MTA 5, 16 2311 boundary 16 2312 MUA 5, 15, 25, 31-32 2314 O 2315 ODMR 36 2316 Originator 11-13 2318 P 2319 POP 25, 32, 35-36, 46 2320 posting 5, 11, 13, 22, 31-32, 36, 39 2321 pull 36 2322 push 36 2324 R 2325 RcptTo 12 2326 Receiver 12 2327 Recipient 11-12, 39 2328 recipient 36 2329 relay 12 2330 responsibility 32 2331 responsible 14-15 2332 Return address 39 2333 Return Handler 11 2334 role 12, 19 2335 Author 11 2336 Originator 13 2337 Recipient 11 2339 S 2340 SIEVE 25-26 2341 SMTP 25, 36, 46 2343 T 2344 transfer 12, 14-15 2345 Transit Actor 16 2346 transition 32 2348 U 2349 UA 5 2350 User Agent 5 2352 Author's Address 2354 Dave Crocker 2355 Brandenburg InternetWorking 2356 675 Spruce Drive 2357 Sunnyvale, CA 94086 2358 USA 2360 Phone: +1.408.246.8253 2361 Email: dcrocker@bbiw.net