idnits 2.17.00 (12 Aug 2021) /tmp/idnits58140/draft-crocker-email-arch-13.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 492 has weird spacing: '...lly has the s...' == Line 649 has weird spacing: '...cerning exter...' == Line 669 has weird spacing: '...raction highl...' == Line 1052 has weird spacing: '... script going...' == Line 1085 has weird spacing: '...uctured compo...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to 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 (May 15, 2009) is 4753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3462' is defined on line 2037, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** 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 normative reference: RFC 5335 (Obsoleted by RFC 6532) -- 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 3685 (Obsoleted by RFC 5235) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 5336 (Obsoleted by RFC 6531) Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SMTP D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Standards Track May 15, 2009 5 Expires: November 16, 2009 7 Internet Mail Architecture 8 draft-crocker-email-arch-13 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 November 16, 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 must 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 . . . . . . . . . . . . . . . . . . . 9 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 must work from a common view of it 138 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 196 email [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) transfers or roles 224 ... lines indicate supporting transfers or roles 226 Figure 1: Basic Internet Mail Service Model 228 End-to-end Internet Mail exchange is accomplished by using a 229 standardized infrastructure with these components and 230 characteristics: 232 * An email object 234 * Global addressing 236 * An asynchronous sequence of point-to-point transfer mechanisms 238 * No prior arrangement between MTAs or between Authors and 239 Recipients 241 * No prior arrangement between point-to-point transfer services 242 over the open Internet 244 * No requirement for Author, Originator, or Recipients to be 245 online at the same time 247 The end-to-end portion of the service is the email object, called a 248 "message." Broadly, the message itself distinguishes control 249 information, for handling, from the Author's content. 251 A precept to the design of mail over the open Internet is permitting 252 user-to-user and MTA-to-MTA interoperability without prior, direct 253 arrangement between the independent administrative authorities 254 responsible for handling a message. All participants rely on having 255 the core services universally supported and accessible, either 256 directly or through Gateways that act as translators between Internet 257 Mail and email environments conforming to other standards. Given the 258 importance of spontaneity and serendipity in interpersonal 259 communications, not requiring such prearrangement between 260 participants is a core benefit of Internet Mail and remains a core 261 requirement for it. 263 Within localized networks at the edge of the public Internet, prior 264 administrative arrangement often is required and can include access 265 control, routing constraints, and configuration of the information 266 query service. Although recipient authentication has usually been 267 required for message access since the beginning of Internet Mail, in 268 recent years it also has been required for message submission. In 269 these cases, a server validates the client's identity, whether by 270 explicit security protocols or by implicit infrastructure queries to 271 identify "local" participants. 273 1.2. The Role of This Architecture 275 An Internet service is an integration of related capabilities among 276 two or more participating nodes. The capabilities are accomplished 277 across the Internet by one or more protocols. What connects a 278 protocol to a service is an architecture. An architecture specifies 279 how the protocols implement the service by defining the logical 280 components of a service and the relationships among them. From that 281 logical view, a service defines what is being done, an architecture 282 defines where the pieces are (in relation to each other) and a 283 protocol defines how particular capabilities are performed. 285 As such, an architecture will more formally describe a service at a 286 relatively high level. A protocol which implements some portion of a 287 service will conform to the architecture to a greater or lesser 288 extent, depending on the pragmatic tradeoffs they make when trying to 289 implement the architecture in the context of real-world constraints. 290 Failure to precisely follow an architecture is not a failure of the 291 protocol, nor is failure to precisely cast a protocol a failure of 292 the architecture. Where a protocol varies from the architecture, it 293 should of course explain the reason for the variance. However, such 294 variance is not a mark against a protocol: Happily, the IETF prefers 295 running code to architectural purity. 297 In this particular case, this architecture attempts to define the 298 logical components of Internet email and does so post hoc, trying to 299 capture the architectural principles that the current email protocols 300 embody. To different extents, email protocols will conform to this 301 architecture more or less well. Insofar as this architecture differs 302 from those protocols, the reasons are generally well understood and 303 are required for interoperation. The differences are not a sign that 304 protocols need to be fixed. However, this architecture is a best 305 attempt at a logical model of Internet email, and insofar as new 306 protocol development varies from this architecture, it is necessary 307 for designers to understand those differences and explain them 308 carefully. 310 1.3. Document Conventions 312 References to structured fields of a message use a two-part dotted 313 notation. The first part cites the document that contains the 314 specification for the field and the second is the name of the field. 315 Hence is the IMF From: header field in an email 316 content header and is the address in the SMTP 317 "Mail From" command. 319 When occurring without the IMF (RFC 5322) qualifier, header field 320 names are shown with a colon suffix. For example, From:. 322 References to labels for actors, functions or components have the 323 first letter capitalized. 325 Also, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 326 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 327 this document are to be interpreted as described in RFC 2119 328 [RFC2119] [RFC2119]. 330 RFC EDITOR: Remove the following paragraph before publication. 332 Discussion venue: Please direct discussion about this document 333 to the IETF-SMTP mailing list . 335 2. Responsible Actor Roles 337 Internet Mail is a highly distributed service, with a variety of 338 actors playing different roles. These actors fall into three basic 339 types: 341 * User 343 * Message Handling Service (MHS) 345 * ADministrative Management Domain (ADMD) 347 Although related to a technical architecture, the focus on actors 348 concerns participant responsibilities, rather than functionality of 349 modules. For that reason, the labels used are different from those 350 used in classic email architecture diagrams. 352 2.1. User Actors 354 Users are the sources and sinks of messages. Users can be people, 355 organizations, or processes. They can have an exchange that 356 iterates, and they can expand or contract the set of users that 357 participate in a set of exchanges. In Internet Mail, there are four 358 types of Users: 360 * Authors 362 * Recipients 364 * Return Handlers 366 * Mediators 368 Figure 2 shows the primary and secondary flows of messages among 369 them. 371 ++==========++ 372 || Author ||<..................................<.. 373 ++=++=++=++=++ . 374 || || || ++===========++ . 375 || || ++====>|| Recipient || . 376 || || ++=====+=====++ . 377 || || . . 378 || || ..........................>.+ 379 || || . 380 || || ................... . 381 || || . . . 382 || || V . . 383 || || +-----------+ ++=====+=====++ . 384 || ++========>| Mediator +===>|| Recipient || . 385 || +-----+-----+ ++=====+=====++ . 386 || . . . 387 || ..................+.......>.+ 388 || . 389 || ..............+.................. . 390 || . . . . 391 \/ V V ' . 392 +-----------+ +-----------+ ++=====+=====++ . 393 | Mediator +===>| Mediator +===>|| Recipient || . 394 +-----+-----+ +-----+-----+ ++=====+=====++ . 395 . . . . 396 .................+.................+.......>.. 398 Legend: == lines indicate primary (possibly indirect) transfers or roles 399 ... lines indicate supporting transfers or roles 401 Figure 2: Relationships Among User Actors 403 From the user perspective, all message transfer activities are 404 performed by a monolithic Message Handling Service (MHS), even though 405 the actual service can be provided by many independent organizations. 406 Users are customers of this unified service. 408 Whenever any MHS actor sends information to back to an Author or 409 Originator in the sequence of handling a message, that actor is a 410 User. 412 2.1.1. Author 414 The Author is responsible for creating the message, its contents, and 415 its list of recipient addresses. The MHS transfers the message from 416 the Author and delivers it to the Recipients. The MHS has an 417 Originator role (Section 2.2.1) that correlates with the Author role. 419 2.1.2. Recipient 421 The Recipient is a consumer of the delivered message. The MHS has a 422 Receiver role (Section 2.2.4) that correlates with the Recipient 423 role. This is labeled Recv in Figure 3. 425 Any Recipient can close the user communication loop by creating and 426 submitting a new message that replies to the Author. An example of 427 an automated form of reply is the Message Disposition Notification 428 (MDN), which informs the Author about the Recipient's handling of the 429 message. (See Section 4.1.) 431 2.1.3. Return Handler 433 Also called "Bounce Handler", the Return Handler is a special form of 434 Recipient tasked with servicing notifications that the MHS generates, 435 as it transfers or delivers the message. These notices can be about 436 failures or completions and are sent to an address that is specified 437 by the Originator. This Return Handling address (also known as a 438 Return address) might have no visible characteristics in common with 439 the address of the Author or Originator. 441 2.1.4. Mediator 443 A Mediator receives, aggregates, reformulates, and redistributes 444 messages among Authors and Recipients who are the principals in 445 (potentially) protracted exchanges. This activity is easily confused 446 with the underlying MHS transfer exchanges. However, each serves 447 very different purposes and operates in very different ways. 449 When mail is delivered to the Mediator specified in the 450 RFC5321.RcptTo command for the original message, the MHS handles it 451 the same way as for any other Recipient. In particular, the MHS sees 452 each posting and delivery activity between sources and sinks as 453 independent; it does not see subsequent re-posting as a continuation 454 of a process. Because the Mediator originates messages, it can 455 receive replies. Hence, when submitting a reformulated message, the 456 Mediator is an Author, albeit an author actually serving as an agent 457 of one or more other authors. So a Mediator really is a full-fledged 458 User. Mediators are considered extensively in Section 5. 460 A Mediator attempts to preserve the original Author's information in 461 the message it reformulates but is permitted to make meaningful 462 changes to the message content or envelope. The MHS sees a new 463 message, but users receive a message that they interpret as being 464 from, or at least initiated by, the Author of the original message. 465 The role of a Mediator is not limited to merely connecting other 466 participants; the Mediator is responsible for the new message. 468 A Mediator's role is complex and contingent, for example, modifying 469 and adding content or regulating which users are allowed to 470 participate and when. The common example of this role is a group 471 Mailing List. In a more complex use, a sequence of Mediators could 472 perform a sequence of formal steps, such as reviewing, modifying, and 473 approving a purchase request. 475 A Gateway is a particularly interesting form of Mediator. It is a 476 hybrid of User and Relay that connects heterogeneous mail services. 477 Its purpose is to emulate a Relay. For a detailed discussion, see 478 Section 2.2.3. 480 2.2. Message Handling Service (MHS) Actors 482 The Message Handling Service (MHS) performs a single end-to-end 483 transfer on behalf of the Author to reach the Recipient addresses 484 specified in the original RFC5321.RcptTo commands. Exchanges that 485 are either mediated or iterative and protracted, such as those used 486 for collaboration over time are handled by the User actors, not by 487 the MHS actors. 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. 493 Transfers typically entail one or more Relays. However direct 494 delivery from the Originator to Receiver is possible. Intra- 495 organization mail services usually have only one Relay. 496 ++==========++ ++===========++ 497 || Author || || Recipient || 498 ++====++====++ +--------+ ++===========++ 499 || | Return | /\ 500 || +-+------+ || 501 \/ . ^ || 502 +---------+ . . +---++---+ 503 | | . . | | 504 /--+---------+----------------------------+--------+----\ 505 | | | . . MHS | | | 506 | | Origin +<...... .................+ Recv | | 507 | | | ^ | | | 508 | +---++----+ . +--------+ | 509 | || . /\ | 510 | || ..............+.................. || | 511 | \/ . . . || | 512 | +-------+-+ +--+------+ +-+--++---+ | 513 | | Relay +=======>| Relay +=======>| Relay | | 514 | +---------+ +----++---+ +---------+ | 515 | || | 516 | || | 517 | \/ | 518 | +---------+ | 519 | | Gateway +-->... | 520 | +---------+ | 521 \-------------------------------------------------------/ 523 Legend: == lines indicate primary (possibly indirect) transfers or roles 524 ... lines indicate supporting transfers or roles 526 Figure 3: Relationships Among MHS Actors 528 2.2.1. Originator 530 The Originator ensures that a message is valid for posting and then 531 submits it to a Relay. A message is valid if it conforms to both 532 Internet Mail standards and local operational policies. The 533 Originator can simply review the message for conformance and reject 534 it if it finds errors, or it can create some or all of the necessary 535 information. In effect, the Originator is responsible for the 536 functions of the Mail Submission Agent. 538 The Originator operates with dual allegiance. It serves the Author 539 and can be the same entity. But its role in assuring validity means 540 that it MUST also represent the local operator of the MHS, that is, 541 the local ADministrative Management Domain (ADMD). 543 The Originator also performs any post-submission, Author-related 544 administrative tasks associated with message transfer and delivery. 545 Notably, these tasks pertain to sending error and delivery notices, 546 enforcing local policies, and dealing with messages from the Author 547 that prove to be problematic for the Internet. The Originator is 548 accountable for the message content, even when it is not responsible 549 for it. The Author creates the message, but the Originator handles 550 any transmission issues with it. 552 2.2.2. Relay 554 The Relay performs MHS-level transfer-service routing and store-and- 555 forward, by transmitting or retransmitting the message to its 556 Recipients. The Relay adds trace information [RFC2505] but does not 557 modify the envelope information or the message content semantics. It 558 can modify message content representation, such as changing the form 559 of transfer encoding from binary to text, but only as required to 560 meet the capabilities of the next hop in the MHS. 562 A Message Handling System (MHS) network consists of a set of Relays. 563 This network is above any underlying packet-switching network that 564 might be used and below any Gateways or other Mediators. 566 In other words, email scenarios can involve three distinct 567 architectural layers, each providing its own type of data of store- 568 and-forward service: 570 * User Mediators 572 * MHS Relays 574 * Packet Switches 576 The bottom layer is the Internet's IP service. The most basic email 577 scenarios involve Relays and Switches. 579 When a Relay stops attempting to transfer a message, it becomes an 580 Author because it must send an error message to the Return address. 581 The potential for looping is avoided by omitting a Return address 582 from this message. 584 2.2.3. Gateway 586 A Gateway is a hybrid of User and Relay that connects heterogeneous 587 mail services. Its purpose is to emulate a Relay and the closer it 588 comes to this, the better. A Gateway operates as a User when it 589 needs the ability to modify message content. 591 Differences between mail services can be as small as minor syntax 592 variations, but they usually encompass significant, semantic 593 distinctions. One difference could be email addresses that are 594 hierarchical and machine-specific rather than a flat, global 595 namespace. Another difference could be support for text-only content 596 or multi-media. Hence the Relay function in a Gateway presents a 597 significant design challenge, if the resulting performance is to be 598 seen as nearly seamless. The challenge is to ensure user-to-user 599 functionality between the services, despite differences in their 600 syntax and semantics. 602 The basic test of Gateway design is whether an Author on one side of 603 a Gateway can send a useful message to a Recipient on the other side, 604 without requiring changes to any components in the Author's or 605 Recipient's mail services other than adding the Gateway. To each of 606 these otherwise independent services, the Gateway appears to be a 607 native participant. But the ultimate test of Gateway design is 608 whether the Author and Recipient can sustain a dialogue. In 609 particular, can a Recipient's MUA automatically formulate a valid 610 Reply that will reach the Author? 612 2.2.4. Receiver 614 The Receiver performs final delivery or sends the message to an 615 alternate address. It can also perform filtering and other policy 616 enforcement immediately before or after delivery. 618 2.3. Administrative Actors 620 Administrative actors can be associated with different organizations, 621 each with its own administrative authority. This operational 622 independence, coupled with the need for interaction between groups, 623 provides the motivation to distinguish among ADministrative 624 Management Domains (ADMDs ). Each ADMD can have vastly different 625 operating policies and trust-based decision-making. One obvious 626 example is the distinction between mail that is exchanged within an 627 organization and mail that is exchanged between independent 628 organizations. The rules for handling both types of traffic tend to 629 be quite different. That difference requires defining the boundaries 630 of each, and this requires the ADMD construct. 632 Operation of Internet Mail services is carried out by different 633 providers (or operators). Each can be an independent ADMD. This 634 independence of administrative decision-making defines boundaries 635 that distinguish different portions of the Internet Mail service. A 636 department that operates a local Relay, an IT department that 637 operates an enterprise Relay, and an ISP that operates a public 638 shared email service can be configured into many combinations of 639 administrative and operational relationships. Each is a distinct 640 ADMD, potentially having a complex arrangement of functional 641 components. Figure 4 depicts relationships among ADMDs. The 642 benefit of the ADMD construct is to facilitate discussion about 643 designs, policies and operations that need to distinguish between 644 internal issues and external ones. 646 The architectural impact of the need for boundaries between ADMDs is 647 discussed in [Tussle]. Most significant is that the entities 648 communicating across ADMD boundaries typically have the added burden 649 of enforcing organizational policies concerning external 650 communications. At a more mundane level, routing mail between ADMDs 651 can be an issue, such as needing to route mail between organizational 652 partners over specially trusted paths. 654 These are three basic types of ADMDs: 656 Edge: Independent transfer services in networks at the edge of 657 the open Internet Mail service. 659 Consumer: This might be a type of Edge service, as is common 660 for web-based email access. 662 Transit: Mail Service Providers (MSP) that offer value-added 663 capabilities for Edge ADMDs, such as aggregation and filtering. 665 The mail-level transit service is different from packet-level 666 switching. End-to-end packet transfers usually go through 667 intermediate routers; email exchange across the open Internet can be 668 directly between the Boundary MTAs of Edge ADMDs. This distinction 669 between direct and indirect interaction highlights the differences 670 discussed in Section 2.2.2 671 +--------+ +---------+ +-------+ +-----------+ 672 | ADMD1 |<===>| ADMD2 |<===>| ADMD3 |<===>| ADMD4 | 673 | ----- | | ----- | | ----- | | ----- | 674 | | | | | | | | 675 | Author | | | | | | Recipient | 676 | . | | | | | | ^ | 677 | V | | | | | | . | 678 | Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer | 679 | | | | | | | | 680 +--------+ +---------+ +-------+ +-----------+ 682 Legend: == lines indicate primary (possibly indirect) transfers or roles 683 ... lines indicate supporting transfers or roles 685 Figure 4: Administrative Domain (ADMD) Example 687 Edge networks can use proprietary email standards internally. 688 However the distinction between Transit network and Edge network 689 transfer services is significant because it highlights the need for 690 concern over interaction and protection between independent 691 administrations. In particular, this distinction calls for 692 additional care in assessing the transitions of responsibility and 693 the accountability and authorization relationships among participants 694 in message transfer. 696 The interactions of ADMD components are subject to the policies of 697 that domain, which cover concerns such as these: 699 * Reliability 701 * Access control 703 * Accountability 705 * Content evaluation and modification 707 These policies can be implemented in different functional components, 708 according to the needs of the ADMD. For example, see [RFC5068]. 710 Consumer, Edge, and Transit services can be offered by providers that 711 operate component services or sets of services. Further, it is 712 possible for one ADMD to host services for other ADMDs. 714 These are common examples of ADMDs: 716 Enterprise Service Providers: 718 These ADMDs operate the internal data and/or the mail services 719 within an organization. 721 Internet Service Providers (ISP): 723 These ADMDs operate the underlying data communication services, 724 which are used by one or more Relay and User. ISPs are not 725 responsible for performing email functions, but they can 726 provide an environment in which those functions can be 727 performed. 729 Mail Service Providers: 731 These ADMDs operate email services, such as for consumers or 732 client companies. 734 Practical operational concerns demand that providers be involved in 735 administration and enforcement issues. This involvement can extend 736 to operators of lower-level packet services. 738 3. Identities 740 The forms of identity used by Internet Mail are: mailbox, domain 741 name, message-ID and ENVID. Each must be globally unique. 743 3.1. Mailbox 745 "A mailbox receives mail. It is a conceptual entity that does not 746 necessarily pertain to file storage." [RFC5322] 748 A mailbox is specified as an Internet Mail address . It 749 has two distinct parts, separated by an at-sign (@). The right side 750 is a globally interpreted domain name associated with an ADMD. 751 Domain names are discussed in Section 3.3. Formal Internet Mail 752 addressing syntax can support source routes, to indicate the path 753 through which a message ought to be sent. The use of source routes 754 is not common and has been deprecated in [RFC5321]. 756 The portion to the left of the at-sign contains a string that is 757 globally opaque and is called the . It is to be 758 interpreted only by the entity specified by the address's domain 759 name. Except as noted later in this section all other entities MUST 760 treat the as an uninterpreted literal string and MUST 761 preserve all of its original details. As such its public 762 distribution is equivalent to sending a Web browser "cookie" that is 763 only interpreted upon being returned to its creator. 765 Some local-part values have been standardized, for contacting 766 personnel at an organization. These names cover common operations 767 and business functions. [RFC2142] 769 It is common for sites to have local structuring conventions for the 770 left-hand side of an . This permits sub- 771 addressing, such as for distinguishing different discussion groups 772 used by the same participant. However it is worth stressing that 773 these conventions are strictly private to the user's organization and 774 MUST NOT be interpreted by any domain except the one listed in the 775 right side of the . The exceptions are those specialized 776 services that conform to public, standardized conventions, as noted 777 below. 779 Basic email addressing defines the as being globally 780 opaque. However there are some uses of email that add a 781 standardized, global schema to the value, such as between an author 782 and a Gateway. The details remain invisible to the 783 public email transfer infrastructure, but provide addressing and 784 handling instructions for further processing by the Gateway. 785 Standardized examples of these conventions are the telephone 786 numbering formats for VPIM [RFC3801], such as: 788 +16137637582@vpim.example.com 790 and iFax [RFC3192], such as: 792 FAX=+12027653000/T33S=1387@ifax.example.com 794 3.2. Scope of Email Address Use 796 Email addresses are being used far beyond their original role in 797 email transfer and delivery. In practical terms, an email address 798 string has become the common identifier for representing online 799 identity. Hence, it is essential to be clear about both the nature 800 and role of an identity string in a particular context and the entity 801 responsible for setting that string. For example, see Section 4.1.4, 802 Section 4.3.3 and Section 5. 804 3.3. Domain Names 806 A domain name is a global reference to an Internet resource, such as 807 a host, a service, or a network. A domain name usually maps to one 808 or more IP Addresses. Conceptually, the name can encompass an 809 organization, a collection of machines integrated into a homogeneous 810 service, or a single machine. A domain name can be administered to 811 refer to an individual user, but this is not common practice. The 812 name is structured as a hierarchical sequence of labels, separated by 813 dots (.), with the top of the hierarchy being on the right end of the 814 sequence. There can be many names in the sequence -- that is, the 815 depth of the hierarchy can be substantial. Domain names are defined 816 and operated through the Domain Name System (DNS) [RFC1034], 817 [RFC1035], [RFC2181]. 819 When not part of a mailbox address, a domain name is used in Internet 820 Mail to refer to the ADMD or to the host that took action upon the 821 message, such as providing the administrative scope for a message 822 identifier or performing transfer processing. 824 3.4. Message Identifier 826 There are two standardized tags for identifying messages: Message-ID: 827 and ENVID. A Message-ID: pertains to content, and an ENVID pertains 828 to transfer. 830 3.4.1. Message-ID 832 IMF provides for, at most, a single Message-ID:. The Message-ID: for 833 a single message, which is a user-level IMF tag, has a variety of 834 uses including threading, aiding identification of duplicates, and 835 DSN tracking. The Originator assigns the Message-ID:. The 836 Recipient's ADMD is the intended consumer of the Message-ID:, 837 although any actor along the transfer path can use it. 839 Message-ID: MUST be globally unique. Its format is similar to that 840 of a mailbox, with two distinct parts, separated by an at-sign (@). 841 Typically, the right side specifies the ADMD or host that assigns the 842 identifier, and the left side contains a string that is globally 843 opaque and serves to uniquely identify the message within the domain 844 referenced on the right side. The duration of uniqueness for the 845 message identifier is undefined. 847 When a message is revised in any way, the decision whether to assign 848 a new Message-ID: requires a subjective assessment to determine 849 whether the editorial content has been changed enough to constitute a 850 new message. [RFC5322] states that "a message identifier pertains to 851 exactly one instantiation of a particular message; subsequent 852 revisions to the message each receive new message identifiers." Yet 853 experience suggests that some flexibility is needed. An impossible 854 test is whether the recipient will consider the new message to be 855 equivalent to the old one. For most components of Internet Mail, 856 there is no way to predict a specific recipient's preferences on this 857 matter. Both creating and failing to create a new Message-ID: have 858 their downsides. 860 Here are some guidelines and examples: 862 * If a message is changed only in form, such as character 863 encoding, it is still the same message. 865 * If a message has minor additions to the content, such as a 866 mailing list tag at the beginning of the RFC5322.Subject header 867 field, or some mailing list administrative information added to 868 the end of the primary body-part text, it is probably the same 869 message. 871 * If a message has viruses deleted from it, it is probably the 872 same message. 874 * If a message has offensive words deleted from it, some 875 recipients will consider it the same message, but some will 876 not. 878 * If a message is translated into a different language, some 879 recipients will consider it the same message, but some will 880 not. 882 * If a message is included in a digest of messages, the digest 883 constitutes a new message. 885 * If a message is forwarded by a recipient, what is forwarded is 886 a new message. 888 * If a message is "redirected", such as using IMF "Resent-*" 889 header fields, some recipients will consider it the same 890 message, but some will not. 892 The absence of both objective, precise criteria for regenerating a 893 Message-ID: and strong protection associated with the string means 894 that the presence of an ID can permit an assessment that is 895 marginally better than a heuristic, but the ID certainly has no value 896 on its own for strict formal reference or comparison. For that 897 reason, the Message-ID: SHOULD NOT be used for any function that has 898 security implications. 900 3.4.2. ENVID 902 The ENVID (envelope identifier) can be used for message-tracking 903 purposes ([RFC3885], [RFC3464]) concerning a single posting/delivery 904 transfer. The ENVID labels a single transit of the MHS by a specific 905 message. So, the ENVID is used for one message posting, until that 906 message is delivered. A re-posting of the message, such as by a 907 Mediator, does not reuse that ENVID, but can use a new one, even 908 though the message might legitimately retain its original 909 Message-ID:. 911 The format of an ENVID is free form. Although its creator might 912 choose to impose structure on the string, none is imposed by Internet 913 standards. By implication, the scope of the string is defined by the 914 domain name of the Return Address. 916 4. Services and Standards 918 The Internet Mail architecture comprises six basic types of 919 functionality, which are arranged to support a store-and-forward 920 service. As shown in Figure 5, each type can have multiple 921 instances, some of which represent specialized roles. This section 922 considers the activities and relationships among these components, 923 and the Internet Mail standards that apply to them. 925 Message 927 Message User Agent (MUA) 929 Author MUA (aMUA) 931 Recipient MUA (rMUA) 933 Message Submission Agent (MSA) 935 Author-focused MSA functions (aMSA) 937 MHS-focused MSA functions (hMSA) 939 Message Transfer Agent (MTA) 941 Message Delivery Agent (MDA) 942 Recipient-focused MDA functions (rMDA) 944 MHS-focused MDA functions (hMDA) 946 Message Store (MS) 948 Author MS (aMS) 950 Recipient MS (rMS) 952 This figure shows function modules and the standardized protocols 953 used between them. 955 ++========++ 956 || || +-------+ 957 ...........++ aMUA ||<............................+ Disp | 958 . || || +-------+ 959 . ++=+==+===++ ^ 960 . local,imap}| |{smtp,submission . 961 . +-----+ | | +--------+ . 962 . | aMS |<---+ | ........................>| Return | . 963 . +-----+ | . +--------+ . 964 . | . ***************** ^ . 965 . +-----V-.----*------------+ * . . 966 . MSA | +-------+ * +------+ | * . . 967 . | | aMSA +-(S)->| hMSA | | * . . 968 . | +-------+ * +--+---+ | * . . 969 V +------------*------+-----+ * . . 970 //==========\\ * V {smtp * . . 971 || MESSAGE || * +------+ * //===+===\\ . 972 ||----------|| MHS * | MTA | * || dsn || . 973 || ENVELOPE || * +--+---+ * \\=======// . 974 || smtp || * V {smtp * ^ ^ . 975 || CONTENT || * +------+ * . . //==+==\\ 976 || imf || * | MTA +....*...... . || mdn || 977 || mime || * +--+---+ * . \\=====// 978 \\==========// * smtp}| {local * . ^ 979 . MDA * | {lmtp * . . 980 . +----------------+------V-----+ * . . 981 . | +----------+ * +------+ | * . . 982 . | | | * | | +..*.......... . 983 . | | rMDA |<-(D)--+ hMDA | | * . 984 . | | | * | | |<.*........ . 985 . | +-+------+-+ * +------+ | * . . 986 . +------+---------*------------+ * . . 987 . smtp,local}| ***************** . . 988 . V . . 989 . +-----+ //===+===\\ . 990 . | rMS | || sieve || . 991 . +--+--+ \\=======// . 992 . |{imap,pop,local ^ . 993 . V . . 994 . ++==========++ . . 995 . || || . . 996 .......>|| rMUA ++........................... . 997 || ++................................... 998 ++==========++ 1000 Legend: == lines indicate primary (possibly indirect) transfers or roles 1001 == boxes indicate data objects 1002 ... lines indicate supporting transfers or roles 1003 *** lines indicate aggregated service 1005 Figure 5: Protocols and Services 1007 4.1. Message Data 1009 The purpose of the Message Handling System (MHS) is to exchange an 1010 IMF message object among participants [RFC5322]. All of its 1011 underlying mechanisms serve to deliver that message from its Author 1012 to its Recipients. A message can be explicitly labeled as to its 1013 nature [RFC3458]. 1015 A message comprises a transit-handling envelope and the message 1016 content. The envelope contains information used by the MHS. The 1017 content is divided into a structured header and the body. The header 1018 comprises transit handling trace information and structured fields 1019 that are part of the Author's message content. The body can be 1020 unstructured lines of text or a tree of multi-media subordinate 1021 objects, called "body-parts" or attachments [RFC2045], [RFC2046], 1022 [RFC2047], [RFC4288], [RFC4289], [RFC2049]. 1024 In addition, Internet Mail has a few conventions for special control 1025 data, notably: 1027 Delivery Status Notification (DSN): 1029 A Delivery Status Notification (DSN) is a message that can be 1030 generated by the MHS (MSA, MTA, or MDA) and sent to the 1031 RFC5321.MailFrom address. An MDA and MTA are shown as sources 1032 of DSNs in Figure 5, and the destination is shown as Returns. 1033 DSNs provide information about message transit, such as 1034 transfer errors or successful delivery. [RFC3461] 1036 Message Disposition Notification (MDN): 1038 A Message Disposition Notification (MDN) is a message that 1039 provides information about post-delivery processing, such as 1040 indicating that the message has been displayed [RFC3798] or the 1041 form of content that can be supported [RFC3297]. It can be 1042 generated by an rMUA and is sent to the Disposition- 1043 Notification-To addresses. The mailbox for this is shown as 1044 Disp in Figure 5. 1046 Message Filtering (SIEVE): 1048 Sieve is a scripting language used to specify conditions for 1049 differential handling of mail, typically at the time of 1050 delivery [RFC5228]. Scripts can be conveyed in a variety of 1051 ways, such as a MIME part in a message. Figure 5 shows a Sieve 1052 script going from the rMUA to the MDA. However, filtering can 1053 be done at many different points along the transit path, and 1054 any one or more of them might be subject to Sieve directives, 1055 especially within a single ADMD. the Figure 5 shows only one 1056 relationship, for (relative) simplicity. 1058 4.1.1. Envelope 1060 Internet Mail has a fragmented framework for transit-related handling 1061 information. Information that is used directly by the MHS is called 1062 the "envelope." It directs handling activities by the transfer 1063 service and is carried in transfer service commands. That is, the 1064 envelope exists in the transfer protocol SMTP. [RFC5321] 1066 Trace information, such as RFC5322.Received, is recorded in the 1067 message header and is not subsequently altered. [RFC5322] 1069 4.1.2. Header Fields 1071 Header fields are attribute name/value pairs that cover an extensible 1072 range of email service parameters, structured user content, and user 1073 transaction meta-information. The core set of header fields is 1074 defined in [RFC5322]. It is common practice to extend this set for 1075 different applications. Procedures for registering header fields are 1076 defined in [RFC3864]. An extensive set of existing header field 1077 registrations is provided in [RFC4021]. 1079 One danger of placing additional information in header fields is that 1080 Gateways often alter or delete them. 1082 4.1.3. Body 1084 The body of a message might be lines of ASCII text or a 1085 hierarchically structured composition of multi-media body-part 1086 attachments, using MIME. [RFC2045], [RFC2046], [RFC2047], [RFC4288], 1087 [RFC2049] 1089 4.1.4. Identity References in a Message 1091 Table 1 lists the core identifiers present in a message during 1092 transit. 1094 +----------------------+----------------+---------------------------+ 1095 | Layer | Field | Set By | 1096 +----------------------+----------------+---------------------------+ 1097 | Message Body | MIME Header | Author | 1098 | Message header | From: | Author | 1099 | fields | | | 1100 | | Sender: | Originator | 1101 | | Reply-To: | Author | 1102 | | To:, CC:, BCC: | Author | 1103 | | Message-ID: | Originator | 1104 | | Received: | Originator, Relay, | 1105 | | | Receiver | 1106 | | Return-Path: | MDA, from MailFrom | 1107 | | Resent-*: | Mediator | 1108 | | List-Id: | Mediator | 1109 | | List-*: | Mediator | 1110 | SMTP | HELO/EHLO | Latest Relay Client | 1111 | | ENVID | Originator | 1112 | | MailFrom | Originator | 1113 | | RcptTo | Author | 1114 | | ORCPT | Originator | 1115 | IP | Source Address | Latest Relay Client | 1116 +----------------------+----------------+---------------------------+ 1118 Legend: Layer - The part of the email architecture that uses the 1119 identifier; Field - The protocol construct that contains the 1120 identifier; Set By - The actor role responsible for specifying the 1121 identifier value (and this can be different from the actor that 1122 performs the fill-in function for the protocol construct) 1124 Table 1: Layered Identities 1126 These are the most common address-related fields: 1128 RFC5322.From: Set by - Author 1130 Names and addresses for authors of the message content are 1131 listed in the From: field. 1133 RFC5322.Reply-To: Set by - Author 1135 If a Recipient sends a reply message that would otherwise use 1136 the RFC5322.From field addresses in the original message, the 1137 addresses in the RFC5322.Reply-To field are used instead. In 1138 other words, this field overrides the From: field for responses 1139 from Recipients. 1141 RFC5322.Sender: Set by - Originator 1143 This field specifies the address responsible for submitting the 1144 message to the transfer service. This field can be omitted if 1145 it contains the same address as RFC5322.From. However, 1146 omitting this field does not mean that no Sender is specified; 1147 it means that that header field is virtual and that the address 1148 in the From: field MUST be used. 1150 Specification of the notifications Return addresses, which are 1151 contained in RFC5321.MailFrom, is made by the RFC5322.Sender. 1152 Typically the Return address is the same as the Sender address. 1153 However, some usage scenarios require it to be different. 1155 RFC5322.To/.CC: Set by - Author 1157 These fields specify MUA Recipient addresses. However, some or 1158 all of the addresses in these fields might not be present in 1159 the RFC5321.RcptTo commands. 1161 The distinction between To and CC is subjective. Generally, a 1162 To addressee is considered primary and is expected to take 1163 action on the message. A CC addressee typically receives a 1164 copy as a courtesy. 1166 RFC5322.BCC: Set by - Author 1168 A copy of the message might be sent to an addressee whose 1169 participation is not to be disclosed to the RFC5322.To or 1170 RFC5322.CC Recipients and, usually, not to the other BCC 1171 Recipients. The BCC: header field indicates a message copy to 1172 such a Recipient. Use of this field is discussed in [RFC5322]. 1174 RFC5321.HELO/.EHLO: Set by - Originator, MSA, MTA 1176 Any SMTP client -- including Originator, MSA, or MTA -- can 1177 specify its hosting domain identity for the SMTP HELO or EHLO 1178 command operation. 1180 RFC3461.ENVID: Set by - Originator 1182 The MSA can specify an opaque string, to be included in a DSN, 1183 as a means of assisting the Return address recipient in 1184 identifying the message that produced a DSN or message 1185 tracking. 1187 RFC5321.MailFrom: Set by - Originator 1189 This field is an end-to-end string that specifies an email 1190 address for receiving return control information, such as 1191 returned messages. The name of this field is misleading, 1192 because it is not required to specify either the Author or the 1193 actor responsible for submitting the message. Rather, the 1194 actor responsible for submission specifies the RFC5321.MailFrom 1195 address. Ultimately, the simple basis for deciding which 1196 address needs to be in the RFC5321.MailFrom field is to 1197 determine which address must be informed about transfer-level 1198 problems (and possibly successes.) 1200 RFC5321.RcptTo: Set by - Author, Final MTA, MDA. 1202 This field specifies the MUA mailbox address of a Recipient. 1203 The string might not be visible in the message content header. 1204 For example, the IMF destination address header fields, such as 1205 RFC5322.To, might specify a mailing list mailbox, while the 1206 RFC5321.RcptTo address specifies a member of that list. 1208 RFC5321.ORCPT: Set by - Originator. 1210 This is an optional parameter to the RCPT command, indicating 1211 the original address to which the current RCPT TO address 1212 corresponds, after a mapping was performed during transit. An 1213 ORCPT is the only reliable way to correlate a DSN from a multi- 1214 recipient message transfer with the intended recipient. 1216 RFC5321.Received: Set by - Originator, Relay, Mediator, Dest 1218 This field contains trace information, including originating 1219 host, Relays, Mediators, and MSA host domain names and/or IP 1220 Addresses. 1222 RFC5321.Return-Path: Set by - Originator 1224 The MDA records the RFC5321.MailFrom address into the 1225 RFC5321.Return-Path field. 1227 RFC2919.List-Id: Set by - Mediator Author 1229 This field provides a globally unique mailing list naming 1230 framework that is independent of particular hosts. [RFC2919] 1232 The identifier is in the form of a domain name; however, the 1233 string usually is constructed by combining the two parts of an 1234 email address. The result is rarely a true domain name, listed 1235 in the domain name service, although it can be. 1237 RFC2369.List-*: Set by - Mediator Author 1239 [RFC2369] defines a collection of message header fields for use 1240 by mailing lists. In effect, they supply list-specific 1241 parameters for common mailing list user operations. The 1242 identifiers for these operations are for the list itself and 1243 the user-as-subscriber. [RFC2369] 1245 RFC0791.SourceAddr: Set by - The Client SMTP sending host 1246 immediately preceding the current receiving SMTP server. 1248 [RFC0791] defines the basic unit of data transfer for the 1249 Internet: the IP Datagram. It contains a Source Address field 1250 that specifies the IP Address for the host (interface) from 1251 which the datagram was sent. This information is set and 1252 provided by the IP layer, which makes it independent of mail- 1253 level mechanisms. As such, it is often taken to be 1254 authoritative, although it is possible to provide false 1255 addresses. 1257 4.2. User-Level Services 1259 Interactions at the user level entail protocol exchanges, distinct 1260 from those that occur at lower layers of the Internet Mail MHS 1261 architecture that is, in turn, above the Internet Transport layer. 1262 Because the motivation for email, and much of its use, is for 1263 interaction among people, the nature and details of these protocol 1264 exchanges often are determined by the needs of interpersonal and 1265 group communication. To accommodate the idiosyncratic behavior 1266 inherent in such communication, only subjective guidelines, rather 1267 than strict rules, can be offered for some aspects of system 1268 behavior. Mailing Lists provide particularly salient examples. 1270 4.2.1. Message User Agent (MUA) 1272 A Message User Agent (MUA) works on behalf of User actors and User 1273 applications. It is their representative within the email service. 1275 The Author MUA (aMUA) creates a message and performs initial 1276 submission into the transfer infrastructure via a Mail Submission 1277 Agent (MSA). It can also perform any creation- and posting-time 1278 archival in its Message Store (aMS). An MUA aMS can organize 1279 messages in many different ways. A common model uses aggregations, 1280 called "folders"; in IMAP they are called "mailboxes". This model 1281 allows a folder for messages under development (Drafts), a folder for 1282 messages waiting to be sent (Queued or Unsent), and a folder for 1283 messages that have been successfully posted for transfer (Sent). But 1284 none of these folders is required. For example, IMAP allows drafts 1285 to be stored in any folder; so no Drafts folder needs to be present. 1287 The Recipient MUA (rMUA) works on behalf of the Recipient to process 1288 received mail. This processing includes generating user-level 1289 disposition control messages, displaying and disposing of the 1290 received message, and closing or expanding the user communication 1291 loop by initiating replies and forwarding new messages. 1293 NOTE: Although not shown in Figure 5, an MUA itself can have a 1294 distributed implementation, such as a "thin" user interface 1295 module on a constrained device such as a smartphone, with most 1296 of the MUA functionality running remotely on a more capable 1297 server. An example of such an architecture might use IMAP 1298 [RFC3501] for most of the interactions between an MUA client 1299 and an MUA server. An approach for such scenarios is defined 1300 by [RFC4550]. 1302 A Mediator is special class of MUA. It performs message re-posting, 1303 as discussed in Section 2.1. 1305 An MUA can be automated, on behalf of a user who is not present at 1306 the time the MUA is active. One example is a bulk sending service 1307 that has a timed-initiation feature. These services are not to be 1308 confused with a mailing list Mediator, since there is no incoming 1309 message triggering the activity of the automated service. 1311 A popular and problematic MUA is an automatic responder, such as one 1312 that sends out-of-office notices. This behavior might be confused 1313 with that of a Mediator, but this MUA is generating a new message. 1314 Automatic responders can annoy users of mailing lists unless they 1315 follow [RFC3834]. 1317 The identity fields are relevant to a typical MUA: 1319 RFC5322.From 1321 RFC5322.Reply-To 1323 RFC5322.Sender 1325 RFC5322.To, RFC5322.CC 1327 RFC5322.BCC 1329 4.2.2. Message Store (MS) 1331 An MUA can employ a long-term Message Store (MS). Figure 5 depicts 1332 an Author's MS (aMS) and a Recipient's MS (rMS). An MS can be 1333 located on a remote server or on the same machine as the MUA. 1335 An MS acquires messages from an MDA either proactively by a local 1336 mechanism or even with a standardized mechanism such as SMTP(!) or 1337 reactively by using POP or IMAP. The MUA accesses the MS either by a 1338 local mechanism or by using POP or IMAP. Using POP for individual 1339 message accesses, rather than for bulk transfer, is relatively rare 1340 and inefficient. 1342 4.3. MHS-Level Services 1344 4.3.1. Mail Submission Agent (MSA) 1346 A Mail Submission Agent (MSA) accepts the message submitted by the 1347 aMUA and enforces the policies of the hosting ADMD and the 1348 requirements of Internet standards. An MSA represents an unusual 1349 functional dichotomy. It represents the interests of the Author 1350 (aMUA) during message posting, to facilitate posting success; it also 1351 represents the interests of the MHS. In the architecture, these 1352 responsibilities are modeled, as shown in Figure 5, by dividing the 1353 MSA into two sub-components, aMSA and hMSA, respectively. Transfer 1354 of responsibility for a single message, from an Author's environment 1355 to the MHS, is called "posting". In Figure 5 it is marked as the (S) 1356 transition, within the MSA. 1358 The hMSA takes transit responsibility for a message that conforms to 1359 the relevant Internet standards and to local site policies. It 1360 rejects messages that are not in conformance. The MSA performs final 1361 message preparation for submission and effects the transfer of 1362 responsibility to the MHS, via the hMSA. The amount of preparation 1363 depends upon the local implementations. Examples of oMSA tasks 1364 include adding header fields, such as Date: and Message-ID:, and 1365 modifying portions of the message from local notations to Internet 1366 standards, such as expanding an address to its formal IMF 1367 representation. 1369 Historically, standards-based MUA/MSA message postings have used 1370 SMTP. [RFC5321] The standard currently preferred is SUBMISSION. 1371 [RFC4409] Although SUBMISSION derives from SMTP, it uses a separate 1372 TCP port and imposes distinct requirements, such as access 1373 authorization. 1375 These identities are relevant to the MSA: 1377 RFC5321.HELO/.EHLO 1379 RFC3461.ENVID 1381 RFC5321.MailFrom 1383 RFC5321.RcptTo 1385 RFC5321.Received 1387 RFC0791.SourceAddr 1389 4.3.2. Message Transfer Agent (MTA) 1391 A Message Transfer Agent (MTA) relays mail for one application-level 1392 "hop." It is like a packet-switch or IP router in that its job is to 1393 make routing assessments and to move the message closer to the 1394 Recipients. Of course, email objects are typically much larger than 1395 the payload of a packet or datagram, and the end-to-end latencies are 1396 typically much higher. Relaying is performed by a sequence of MTAs, 1397 until the message reaches a destination MDA. Hence, an MTA 1398 implements both client and server MTA functionality; it does not 1399 change addresses in the envelope or reformulate the editorial 1400 content. A change in data form, such as to MIME Content-Transfer- 1401 Encoding, is within the purview of an MTA, but removal or replacement 1402 of body content is not. An MTA also adds trace information. 1403 [RFC2505] 1405 NOTE: Within a destination ADMD, email relaying modules can 1406 make a variety of changes to the message, prior to delivery. 1407 In such cases, these modules are acting as Gateways, rather 1408 than MTAs. 1410 Internet Mail uses SMTP [RFC5321], [RFC2821], [RFC0821] primarily to 1411 effect point-to-point transfers between peer MTAs. Other transfer 1412 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1413 most network layer mechanisms, the Internet Mail SMTP supports a 1414 basic level of reliability, by virtue of providing for retransmission 1415 after a temporary transfer failure. Unlike typical packet switches 1416 (and Instant Messaging services), Internet Mail MTAs are expected to 1417 store messages in a manner that allows recovery across service 1418 interruptions, such as host system shutdown. The degree of such 1419 robustness and persistence by an MTA can vary. The base SMTP 1420 specification provides a framework for protocol response codes. An 1421 extensible enhancement to this framework is defined in [RFC5248] 1423 Although quite basic, the dominant routing mechanism for Internet 1424 Mail is the DNS MX record [RFC1035], which specifies an MTA through 1425 which the queried domain can be reached. This mechanism presumes a 1426 public, or at least a common, backbone that permits any attached MTA 1427 to connect to any other. 1429 MTAs can perform any of these well-established roles: 1431 Boundary MTA: An MTA that is part of an ADMD and interacts with 1432 MTAs in other ADMDs. This is also called a Border MTA. There 1433 can be different Boundary MTAs, according to the direction of 1434 mail-flow. 1436 Outbound MTA: An MTA that relays messages to other ADMDs. 1438 Inbound MTA: An MTA that receives inbound SMTP messages from 1439 MTA Relays in other ADMDs, for example, an MTA running on 1440 the host listed as the target of an MX record. 1442 Final MTA: The MTA that transfers a message to the MDA. 1444 These identities are relevant to the MTA: 1446 RFC5321.HELO/.EHLO 1448 RFC3461.ENVID 1450 RFC5321.MailFrom 1451 RFC5321.RcptTo 1453 RFC5322.Received: Set by - Relay Server 1455 RFC0791.SourceAddr 1457 4.3.3. Mail Delivery Agent (MDA) 1459 A transfer of responsibility from the MHS to a Recipient's 1460 environment (mailbox) is called "delivery." In the architecture, as 1461 depicted in Figure 5, delivery takes place within a Mail Delivery 1462 Agent (MDA) and is shown as the (D) transition from the MHS-oriented 1463 MDA component (hMDA) to the Recipient-oriented MDA component (rMDA). 1465 An MDA can provide distinctive, address-based functionality, made 1466 possible by its detailed information about the properties of the 1467 destination address. This information might also be present 1468 elsewhere in the Recipient's ADMD, such as at an organizational 1469 border (Boundary) Relay. However, it is required for the MDA, if 1470 only because the MDA is required to know where to deliver the 1471 message. 1473 Like an MSA, an MDA serves two roles, as depicted in Figure 5. 1474 Formal transfer of responsibility, called "delivery", is effected 1475 between the two components that embody these roles as shows as "(D)" 1476 in Figure 5. The MHS portion (hMDA) primarily functions as a server 1477 SMTP engine. A common additional role is to re-direct the message to 1478 an alternative address, as specified by the recipient addressee's 1479 preferences. The job of the recipient portion of the MDA (rMDA) is 1480 to perform any delivery actions that the Recipient specifies. 1482 Transfer into the MDA is accomplished by a normal MTA transfer 1483 mechanism. Transfer from an MDA to an MS uses an access protocol, 1484 such as POP or IMAP. 1486 NOTE: The term "delivery" can refer to the formal, MHS function 1487 specified here or to the first time a message is displayed to a 1488 Recipient. A simple, practical test for whether the MHS-based 1489 definition applies is whether a DSN can be generated. 1491 These identities are relevant to the MDA: 1493 RFC5321.Return-Path: Set by - Author Originator or Mediator 1494 Originator 1496 The MDA records the RFC5321.MailFrom address into the 1497 RFC5321.Return-Path field. 1499 RFC5322.Received: Set by - MDA server 1501 An MDA can record a Received: header field to indicate trace 1502 information, including source host and receiving host domain 1503 names and/or IP Addresses. 1505 4.4. Transition Modes 1507 From the origination site to the point of delivery, Internet Mail 1508 usually follows a "push" model. That is, the actor that holds the 1509 message initiates transfer to the next venue, typically with SMTP 1510 [RFC5321] or LMTP [RFC2033]. With a "pull" model, the actor that 1511 holds the message waits for the actor in the next venue to initiate a 1512 request for transfer. Standardized mechanisms for pull-based MHS 1513 transfer are ETRN [RFC1985] and ODMR [RFC2645]. 1515 After delivery, the Recipient's MUA (or MS) can gain access by having 1516 the message pushed to it or by having the receiver of access pull the 1517 message, such as by using POP [RFC1939] and IMAP [RFC3501]. 1519 4.5. Implementation and Operation 1521 A discussion of any interesting system architecture often bogs down 1522 when architecture and implementation are confused. An architecture 1523 defines the conceptual functions of a service, divided into discrete 1524 conceptual modules. An implementation of that architecture can 1525 combine or separate architectural components, as needed for a 1526 particular operational environment. For example, a software system 1527 that primarily performs message relaying is an MTA, yet it might 1528 also include MDA functionality. That same MTA system might be able 1529 to interface with non-Internet email services and thus perform both 1530 as an MTA and as a Gateway. 1532 Similarly, implemented modules might be configured to form 1533 elaborations of the architecture. An interesting example is a 1534 distributed MS. One portion might be a remote server and another 1535 might be local to the MUA. As discussed in [RFC1733], there are 1536 three operational relationships among such MSs: 1538 Online: The MS is remote, and messages are accessible only when 1539 the MUA is attached to the MS so that the MUA will re-fetch all 1540 or part of a message, from one session to the next. 1542 Offline: The MS is local to the user, and messages are 1543 completely moved from any remote store, rather than (also) 1544 being retained there. 1546 Disconnected: An rMS and a uMS are kept synchronized, for all or 1547 part of their contents, while they are connected. When they 1548 are disconnected, mail can arrive at the rMS and the user can 1549 make changes to the uMS. The two stores are re-synchronized 1550 when they are reconnected. 1552 5. Mediators 1554 Basic message transfer from Author to Recipients is accomplished by 1555 using an asynchronous store-and-forward communication infrastructure 1556 in a sequence of independent transmissions through some number of 1557 MTAs. A very different task is a sequence of postings and deliveries 1558 through Mediators. A Mediator forwards a message, through a re- 1559 posting process. The Mediator shares some functionality with basic 1560 MTA relaying, but has greater flexibility in both addressing and 1561 content than is available to MTAs. 1563 This is the core set of message information that is commonly set by 1564 all types of Mediators: 1566 RFC5321.HELO/.EHLO: Set by - Mediator Originator 1568 RFC3461.ENVID: Set by - Mediator Originator 1570 RFC5321.RcptTo: Set by - Mediator Author 1572 RFC5321.Received: Set by - Mediator Dest 1574 The Mediator can record received information, to indicate the 1575 delivery to the original address and submission to the alias 1576 address. The trace of Received: header fields can include 1577 everything from original posting, through relaying, to final 1578 delivery. 1580 The aspect of a Mediator that distinguishes it from any other MUA 1581 creating a message is that a Mediator preserves the integrity and 1582 tone of the original message, including the essential aspects of its 1583 origination information. The Mediator might also add commentary. 1585 Examples of MUA messages that a Mediator does not create include: 1587 New message that forwards an existing message: 1589 Although this action provides a basic template for a class of 1590 Mediators, its typical occurrence is not, itself, an example of 1591 a Mediator. The new message is viewed as being from the actor 1592 that is doing the forwarding, rather than from the original 1593 Author. 1595 A new message encapsulates the original message and is seen as 1596 from the new Originator. This Mediator Originator might add 1597 commentary and can modify the original message content. 1598 Because the forwarded message is a component of the message 1599 sent by the new Originator, the new message creates a new 1600 dialogue. However the final Recipient still sees the contained 1601 message as from the original Author. 1603 Reply: 1605 When a Recipient responds to the Author of a message, the new 1606 message is not typically viewed as a forwarding of the 1607 original. Its focus is the new content, although it might 1608 contain all or part of the material from the original message. 1609 The earlier material is merely contextual and secondary. This 1610 includes automated replies, such as vacation out-of-office 1611 notices, as discussed in Section 4.2.1. 1613 Annotation: 1615 The integrity of the original message is usually preserved, but 1616 one or more comments about the message are added in a manner 1617 that distinguishes commentary from original text. The primary 1618 purpose of the new message is to provide commentary from a new 1619 Author, similar to a Reply. 1621 The remainder of this section describes common examples of 1622 Mediators. 1624 5.1. Alias 1626 One function of an MDA is to determine the internal location of a 1627 mailbox in order to perform delivery. An Alias is a simple re- 1628 addressing facility that provides one or more new Internet Mail 1629 addresses, rather than a single, internal one; the message continues 1630 through the transfer service, for delivery to one or more alternate 1631 addresses. Although typically implemented as part of an MDA, this 1632 facility is a Recipient function. It resubmits the message, although 1633 all handling information except the envelope recipient 1634 (rfc5321.RcptTo) address is retained. In particular, the Return 1635 address (rfc5321.MailFrom) is unchanged. 1637 What is distinctive about this forwarding mechanism is how closely it 1638 resembles normal MTA store-and-forward relaying. Its only 1639 significant difference is that it changes the RFC5321.RcptTo value. 1640 Because this change is so small, aliasing can be viewed as a part of 1641 the lower-level mail relaying activity. However, this small change 1642 has a large semantic impact: The designated recipient has chosen a 1643 new recipient. 1645 NOTE: When the replacement list includes more than one address, 1646 the alias is increasingly likely to have delivery problems. 1647 Any problem reports go to the original Author, not the 1648 administrator of the alias entry. This makes it more difficult 1649 to resolve the problem, because the original Author has no 1650 knowledge of the Alias mechanism. 1652 Including the core set of message information listed at the beginning 1653 of this section, Alias typically changes: 1655 RFC5322.To/.CC/.BCC: Set by - Author 1657 These fields retain their original addresses. 1659 RFC5321.MailFrom: Set by - Author 1661 The benefit of retaining the original MailFrom value is to 1662 ensure that an actor related to the originating ADMD knows 1663 there has been a delivery problem. On the other hand, the 1664 responsibility for handling problems, when transiting from the 1665 original recipient mailbox to the alias mailbox usually lies 1666 with that original Recipient, because the Alias mechanism is 1667 strictly under that Recipient's control. Retaining the 1668 original MailFrom address prevents this. 1670 5.2. ReSender 1672 Also called the ReDirector, the ReSender's actions differ from 1673 forwarding because the Mediator "splices" a message's addressing 1674 information to connect the Author of the original message with the 1675 Recipient of the new message. This connection permits them to have 1676 direct exchange, using their normal MUA Reply functions, while also 1677 recording full reference information about the Recipient who served 1678 as a Mediator. Hence, the new Recipient sees the message as being 1679 from the original Author, even if the Mediator adds commentary. 1681 Including the core set of message information listed at the beginning 1682 of this section, these identities are relevant to a resent message: 1684 RFC5322.From: Set by - original Author 1686 Names and addresses for the original Author of the message 1687 content are retained. The free-form (display-name) portion of 1688 the address might be modified to provide informal reference to 1689 the ReSender. 1691 RFC5322.Reply-To: Set by - original Author 1693 If this field is present in the original message, it is 1694 retained in the resent message. 1696 RFC5322.Sender: Set by - Author's Originator or Mediator 1697 Originator. 1699 RFC5322.To/.CC/.BCC: Set by - original Author 1701 These fields specify the original message Recipients. 1703 RFC5322.Resent-From: Set by - Mediator Author 1705 This address is of the original Recipient who is redirecting 1706 the message. Otherwise, the same rules apply to the Resent- 1707 From: field as to an original RFC5322.From field. 1709 RFC5322.Resent-Sender: Set by - Mediator Originator 1711 The address of the actor responsible for resubmitting the 1712 message. As with RFC5322.Sender, this field can be omitted 1713 when it contains the same address as RFC5322.Resent-From. 1715 RFC5322.Resent-To/-CC/-BCC: Set by: Mediator Author 1717 The addresses of the new Recipients who are now able to reply 1718 to the original author. 1720 RFC5321.MailFrom: Set by - Mediator Originator 1722 The actor responsible for resubmission (RFC5322.Resent-Sender) 1723 is also responsible for specifying the new MailFrom address. 1725 5.3. Mailing Lists 1727 A Mailing List receives messages as an explicit addressee and then 1728 re-posts them to a list of subscribed members. The Mailing List 1729 performs a task that can be viewed as an elaboration of the ReSender. 1730 In addition to sending the new message to a potentially large number 1731 of new Recipients, the Mailing List can modify content, for example, 1732 by deleting attachments, converting the format, and adding list- 1733 specific comments. Mailing Lists also archive messages posted by 1734 Authors. Still the message retains characteristics of being from the 1735 original Author. 1737 Including the core set of message information listed at the beginning 1738 of this section, these identities are relevant to a mailing list 1739 processor, when submitting a message: 1741 RFC2919.List-Id: Set by - Mediator Author 1743 RFC2369.List-*: Set by - Mediator Author 1745 RFC5322.From: Set by - original Author 1747 Names and email addresses for the original Author of the 1748 message content are retained. 1750 RFC5322.Reply-To: Set by - Mediator or original Author 1752 Although problematic, it is common for a Mailing List to assign 1753 its own addresses to the Reply-To: header field of messages 1754 that it posts. This assignment is intended to ensure that 1755 replies go to all list members, rather than to only the 1756 original Author. As a User actor, a Mailing List is the Author 1757 of the new message and can legitimately set the Reply-To: 1758 value. As a Mediator attempting to represent the message on 1759 behalf of its original Author, creating or modifying a 1760 Reply-To: field can be viewed as violating that Author's 1761 intent. When the Reply-To is modified in this way, a reply 1762 that is meant only for the original Author will instead go to 1763 the entire list. When the Mailing List does not set the field, 1764 a reply meant for the entire list can instead go only to the 1765 original Author. At best, either choice is a matter of group 1766 culture for the particular list. 1768 RFC5322.Sender: Set by - Author Originator or Mediator 1769 Originator 1771 This field usually specifies the address of the actor 1772 responsible for Mailing List operations. Mailing Lists that 1773 operate in a manner similar to a simple MTA Relay preserve as 1774 much of the original handling information as possible, 1775 including the original RFC5322.Sender field. (Note that this 1776 mode of operation causes the Mailing List to behave much like 1777 an Alias, with a possible difference in number of new 1778 addressees.) 1780 RFC5322.To/.CC: Set by - original Author 1782 These fields usually contain the original list of Recipient 1783 addresses. 1785 RFC5321.MailFrom: Set by - Mediator Originator 1787 Because a Mailing List can modify the content of a message in 1788 any way, it is responsible for that content; that is, it is an 1789 Author. As such, the Return Address is specified by the 1790 Mailing List. Although it is plausible for the Mailing List to 1791 re-use the Return Address employed by the original Originator, 1792 notifications sent to that address after a message has been 1793 processed by a Mailing List could be problematic. 1795 5.4. Gateways 1797 A Gateway performs the basic routing and transfer work of message 1798 relaying, but it also is permitted to modify content, structure, 1799 address, or attributes as needed to send the message into a messaging 1800 environment that operates under different standards or potentially 1801 incompatible policies. When a Gateway connects two differing 1802 messaging services, its role is easy to identify and understand. 1803 When it connects environments that follow similar technical 1804 standards, but significantly different administrative policies, it is 1805 easy to view a Gateway as merely an MTA. 1807 The critical distinction between an MTA and a Gateway is that a 1808 Gateway can make substantive changes to a message to map between the 1809 standards. In virtually all cases, this mapping results in some 1810 degree of semantic loss. The challenge of Gateway design is to 1811 minimize this loss. Standardized gateways to Internet Mail are 1812 facsimile [RFC4143], voicemail [RFC3801], and MMS [RFC4356] 1813 A Gateway can set any identity field available to an MUA. Including 1814 the core set of message information listed at the beginning of this 1815 section, these identities are typically relevant to Gateways: 1817 RFC5322.From: Set by - original Author 1819 Names and addresses for the original Author of the message 1820 content are retained. As for all original addressing 1821 information in the message, the Gateway can translate addresses 1822 as required to continue to be useful in the target environment. 1824 RFC5322.Reply-To: Set by - original Author 1826 The Gateway SHOULD retain this information, if it is present. 1827 The ability to perform a successful reply by a Recipient is a 1828 typical test of Gateway functionality. 1830 RFC5322.Sender: Set by - Author Originator or Mediator 1831 Originator 1833 This field can retain the original value or can be set to a new 1834 address. 1836 RFC5322.To/.CC/.BCC: Set by - original Recipient 1838 These fields usually retain their original addresses. 1840 RFC5321.MailFrom: Set by - Author Originator or Mediator 1841 Originator 1843 The actor responsible for handling the message can specify a 1844 new address to receive handling notices. 1846 5.5. Boundary Filter 1848 To enforce security boundaries, organizations can subject messages to 1849 analysis, for conformance with its safety policies. An example is 1850 detection of content classed as spam or a virus. A filter might 1851 alter the content, to render it safe, such as by removing content 1852 deemed unacceptable. Typically, these actions add content to the 1853 message that records the actions. 1855 6. Considerations 1856 6.1. Security Considerations 1858 This document describes the existing Internet Mail architecture. It 1859 introduces no new capabilities. The security considerations of this 1860 deployed architecture are documented extensively in the technical 1861 specifications referenced by this document. These specifications 1862 cover classic security topics, such as authentication and privacy. 1863 For example, email transfer protocols can use standardized mechanisms 1864 for operation over authenticated and/or encrypted links, and message 1865 content has similar protection standards available. Examples of such 1866 mechanisms include SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP 1867 [RFC4880], and S/MIME [RFC3851]. 1869 The core of the Internet Mail architecture does not impose any 1870 security requirements or functions on the end-to-end or hop-by-hop 1871 components. For example, it does not require participant 1872 authentication and does not attempt to prevent data disclosure. 1874 Particular message attributes might expose specific security 1875 considerations. For example, the blind carbon copy feature of the 1876 architecture invites disclosure concerns, as discussed in section 7.2 1877 of [RFC5321] and section 5 of [RFC5322]. Transport of text or non- 1878 text content in this architecture has security considerations that 1879 are discussed in [RFC5322], [RFC2045], [RFC2046], and [RFC4288] as 1880 well as the security considerations present in the IANA media types 1881 registry for the respective types. 1883 Agents that automatically respond to email raise significant security 1884 considerations, as discussed in [RFC3834]. Gateway behaviors affect 1885 end-to-end security services, as discussed in [RFC2480]. Security 1886 considerations for boundary filters are discussed in [RFC5228]. 1888 See section 7.1 of [RFC5321] for a discussion of the topic of 1889 origination validation. As mentioned in Section 4.1.4, it is common 1890 practice for components of this architecture to use the 1891 [RFC0791].SourceAddr to make policy decisions [RFC2505], although the 1892 address can be "spoofed". It is possible to use it without 1893 authorization. SMTP and Submission authentication [RFC4954], 1894 [RFC4409] provide more secure alternatives. 1896 The discussion of trust boundaries, ADMDs, actors, roles, and 1897 responsibilities in this document highlights the relevance and 1898 potential complexity of security factors for operation of an Internet 1899 mail service. The core design of Internet Mail to encourage open and 1900 casual exchange of messages has met with scaling challenges, as the 1901 population of email participants has grown to include those with 1902 problematic practices. For example, spam, as defined in [RFC2505], 1903 is a by-product of this architecture. A number of standards track or 1904 BCP documents on the subject have been issued. [RFC2505], [RFC5068], 1905 [RFC3685] 1907 6.2. IANA Considerations 1909 This document has no actions for IANA. 1911 6.3. Internationalization 1913 The core Internet email standards are based on the use of US-ASCII. 1914 That is SMTP [RFC5321] and IMF [RFC5322], as well as their 1915 predecessors. They describe the transport and composition of 1916 messages as composed strictly of US-ASCII 7-bit encoded characters. 1917 The standards have been incrementally enhanced to allow for 1918 characters outside of this limited set, while retaining mechanisms 1919 for backwards-compatibility. Specifically: 1921 o The MIME specifications [RFC2045], [RFC2046], [RFC2047] and 1922 [RFC2049] allow for the use of coded character sets and character 1923 encoding schemes ("charsets" in MIME terminology) other than US- 1924 ASCII. MIME's [RFC2046] allows the textual content of a message 1925 to have a label affixed that specifies the charset used in that 1926 content. Equally MIME's [RFC2047] allows the textual content of 1927 certain header fields in a message to be similarly labeled. 1928 However, since messages might be transported over SMTP 1929 implementations only capable of transporting 7-bit encoded 1930 characters, MIME's [RFC2045] also provides for "content transfer 1931 encoding" so that characters of other charsets can be re-encoded 1932 as an overlay to US-ASCII. 1934 o MIME's [RFC2045] allows for the textual content of a message to be 1935 in an 8-bit character encoding scheme. In order to transport 1936 these without re-encoding them, the SMTP specification supports an 1937 option [RFC1652] that permits the transport of such textual 1938 content. However, the [RFC1652] option does not address the use 1939 of 8-bit content in message header fields, and therefore [RFC2047] 1940 encoding is still required for those. 1942 o A series of experimental protocols on Email Address 1943 Internationalization (EAI) have been released that extend SMTP and 1944 IMF to allow for 8-bit encoded characters to appear in addresses 1945 and other information throughout the header fields of messages. 1946 [RFC5335] specifies the format of such message header fields 1947 (which encode the characters in UTF-8), and [RFC5336] specifies an 1948 SMTP option for the transport of these messages. 1950 o MIME's [RFC2045] and [RFC2046] allow for the transport of true 1951 multimedia material, which has obvious applicability to 1952 internationalization. 1954 o The formats for delivery status notifications (DSNs--[RFC3462], 1955 [RFC3463], [RFC3464]) and message disposition notifications 1956 (MDNs--[RFC3798]) include both a structured and unstructured 1957 representation of the notification. In the event that the 1958 unstructured representation is in the wrong language or is 1959 otherwise unsuitable for use, this allows an MUA to construct its 1960 own appropriately localized representation of notification for 1961 display to the user. 1963 o POP and IMAP do not introduce internationalization issues. 1965 Hence, the use of UTF-8 is fully established in existing Internet 1966 mail. However support for long-standing encoding forms is retained 1967 and is still used. 1969 7. References 1971 7.1. Normative 1973 [RFC0791] Postel, J., "Internet Protocol", RFC 791, 1981 September. 1975 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1976 STD 13, RFC 1034, November 1987. 1978 [RFC1035] Mockapetris, P., "Domain names - implementation and 1979 specification", STD 13, RFC 1035, November 1987. 1981 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1982 STD 53, RFC 1939, May 1996. 1984 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1985 Extensions (MIME) Part One: Format of Internet Message 1986 Bodies", RFC 2045, November 1996. 1988 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1989 Extensions (MIME) Part Two: Media Types", RFC 2046, 1990 November 1996. 1992 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1993 Part Three: Message Header Extensions for Non-ASCII Text", 1994 RFC 2047, November 1996. 1996 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1997 Extensions (MIME) Part Five: Conformance Criteria and 1998 Examples", RFC 2049, November 1996. 2000 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2001 Requirement Levels", BCP 14, RFC 2119, March 1997. 2003 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 2004 Specification", RFC 2181, July 1997. 2006 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 2007 for Core Mail List Commands and their Transport through 2008 Message Header Fields", RFC 2369, July 1998. 2010 [RFC2645] Gellens, R., "On-Demand Mail Relay (ODMR) SMTP with 2011 Dynamic IP Addresses", RFC 2645, August 1999. 2013 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 2014 April 2001. 2016 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 2017 April 2001. 2019 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 2020 and Namespace for the Identification of Mailing Lists", 2021 RFC 2919, March 2001. 2023 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet 2024 Mail", RFC 3192, October 2001. 2026 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 2027 Negotiation for Messaging Services based on Email", 2028 RFC 3297, July 2002. 2030 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 2031 Context for Internet Mail", RFC 3458, January 2003. 2033 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 2034 Extension for Delivery Status Notifications (DSNs)", 2035 RFC 3461, January 2003. 2037 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the 2038 Reporting of Mail System Administrative Messages", 2039 RFC 3462, January 2003. 2041 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 2042 RFC 3463, January 2003. 2044 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 2045 4rev1", RFC 3501, March 2003. 2047 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 2048 Notification", RFC 3798, May 2004. 2050 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 2051 Electronic Mail", RFC 3834, August 2004. 2053 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2054 Procedures for Message Header Fields", RFC 3864, 2055 September 2004. 2057 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 2058 Header Fields", RFC 4021, March 2005. 2060 [RFC4288] Freed, N., Klensin, J., and J. Postel, "Media Type 2061 Specifications and Registration Procedures", BCP 13, 2062 RFC 4288, December 2005. 2064 [RFC4289] Freed, N., Klensin, J., and J. Postel, "Multipurpose 2065 Internet Mail Extensions (MIME) Part Four: Registration 2066 Procedures", BCP 13, RFC 4289, December 2005. 2068 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 2069 RFC 4409, April 2006. 2071 [RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support 2072 Diverse Service Environments (Lemonade) Profile", 2073 June 2006. 2075 [RFC5228] Showalter, T., "Sieve: A Mail Filtering Language", 2076 RFC 5228. 2078 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 2079 Mail System Status Codes", RFC 5248, June 2008. 2081 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2082 October 2008. 2084 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2085 October 2008. 2087 [RFC5335] Abel, Y., Ed., "Internationalized Email Headers", 2088 RFC 5335, September 2008. 2090 7.2. Informative 2092 [RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, 2093 "Standard for the Format of ARPA Network Text Messages", 2094 RFC 733, November 1977. 2096 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 2097 RFC 821, August 1982. 2099 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 2100 text messages", STD 11, RFC 822, August 1982. 2102 [RFC1506] Houttuin, J., "A Tutorial on Gatewaying between X.400 and 2103 Internet Mail", RFC 1506, August 1993. 2105 [RFC1652] Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and 2106 D. Crocker, "SMTP Service Extension for 8bit- 2107 MIMEtransport", RFC 1652, July 1994. 2109 [RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4", 2110 December 1994. 2112 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 2113 RFC 1767, March 1995. 2115 [RFC1985] De Winter, J., "SMTP Service Extension for Remote 2116 Message Queue Starting", August 1996. 2118 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 2119 October 1996. 2121 [RFC2142] Crocker, D., "Mailbox Names for Common services, Roles and 2122 Functions", RFC 2142, May 1997. 2124 [RFC2442] Freed, N., Newman, D., Belissen, J., and M. Hoy, "The 2125 Batch SMTP Media Type", RFC 2442, November 1998. 2127 [RFC2480] Freed, N., "Gateways and MIME Security Multiparts", 2128 RFC 2480, January 1999. 2130 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 2131 RFC 2505, February 1999. 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 [RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for 2173 Internationalized Email Addresses", RFC 5336, 2174 September 2008. 2176 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 2177 "Tussle in Cyberspace: Defining Tomorrow's Internet", 2178 ACM SIGCOMM, 2002. 2180 Appendix A. Acknowledgements 2182 This work began in 2004 and has evolved through numerous rounds of 2183 community review; it derives from a section in an early version of 2184 [RFC5068]. Over its 5 years of development, the draft has gone 2185 through 13 incremental versions, with vigorous community review that 2186 produced many substantive changes. Review was performed in the IETF 2187 and other email technical venues. Although not a formal activity of 2188 the IETF, issues with the document's contents were resolved using the 2189 classic style of IETF community open, group decision-making. The 2190 document is already cited in other work, such as for IMAP and Sieve 2191 specifications and for academic classwork. The step of standardizing 2192 is useful to provide a solid and stable reference to the Internet's 2193 now-complex email service. 2195 Details of the Originator actor role was greatly clarified during 2196 discussions in the IETF's Marid working group. 2198 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 2199 insight on the framework and details of the original drafts, as did 2200 Chris Newman for the final versions, while also serving as cognizant 2201 Area Director for the document. Tony Hansen served as document 2202 shepherd, through the IETF process. 2204 Later reviews and suggestions were provided by Eric Allman, Nathaniel 2205 Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, 2206 Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John 2207 Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, 2208 Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. 2209 Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg 2210 Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani, and Hans 2211 Lachman. 2213 Diligent early proof-reading was performed by Bruce Lilly. Diligent 2214 technical editing was provided by Susan Hunziker. 2216 The final stages of development for this document were guided by a 2217 design team comprising: Alexey Melnikov, Pete Resnick, Carl S. 2218 Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen and Tony 2219 Finch. Pete Resnick developed the final version of the section on 2220 internationalization. 2222 Index 2223 13 2225 7 2226 7-bit 46 2228 A 2229 accountability 14 2230 accountable 14-15 2231 Actor 2232 Administrative 15 2233 Author 10 2234 Consumer 16 2235 Edge 16 2236 Gateway 15 2237 Originator 13 2238 Recipient 11 2239 Return Handler 11 2240 Transit 16 2241 Actors 2242 MHS 12 2243 ADMD 14-16, 20, 26, 32, 39 2244 Administrative Actors 15 2245 Administrative Management Domain 14 2246 aMSA 32 2247 Author 10, 13 2248 author 36 2250 B 2251 body-parts 25 2252 bounce handler 11 2253 boundary 16 2255 C 2256 charset 46 2257 Consumer Actor 16 2258 content 12, 14-15, 21, 25, 33 2260 D 2261 delivery 5, 11, 13-15, 19, 25-26, 36, 39 2262 Discussion of document 8 2263 DSN 46 2265 E 2266 EAI 46 2267 Edge Actor 16 2268 encoding 46 2269 end-to-end 5 2270 envelope 11, 14, 22, 25-26, 33, 39 2271 ETRN 36 2273 G 2274 Gateway 12, 15 2276 H 2277 header 25 2278 hMSA 32 2280 I 2281 IMAP 25, 32, 35-36, 46 2282 IMF 20, 25, 46 2283 Internet Mail 5 2285 L 2286 LMTP 25, 36 2287 local-part 19 2289 M 2290 Mail 5 2291 Mail From 39 2292 Mail Submission Agent 13 2293 mailbox 39 2294 MDA 25, 39 2295 MDN 11, 25, 46 2296 message 7, 25 2297 Message Disposition Notification 11 2298 Message Handling Service 5 2299 Message Handling System 12 2300 Message Transfer Agent 5 2301 Message User Agent 5 2302 MHS 5, 11-12, 14, 22-23, 25-26 2303 Actors 12 2304 MIME 25, 46 2305 MS 25 2306 MSA 13, 25, 32 2307 MTA 5, 16 2308 boundary 16 2309 MUA 5, 15, 25, 31-32 2311 O 2312 ODMR 36 2313 Originator 11, 13 2315 P 2316 POP 25, 32, 35-36, 46 2317 posting 5, 11, 13, 22, 31-32, 36, 39 2318 pull 36 2319 push 36 2321 R 2322 RcptTo 12 2323 Receiver 13 2324 Recipient 11, 13, 39 2325 recipient 36 2326 relay 13 2327 responsibility 32 2328 responsible 14-15 2329 Return address 39 2330 Return Handler 11 2331 role 11, 19 2332 Author 10 2333 Originator 13 2334 Recipient 11 2336 S 2337 SIEVE 25-26 2338 SMTP 25, 36, 46 2340 T 2341 transfer 13-15 2342 Transit Actor 16 2343 transition 32 2345 U 2346 UA 5 2347 User Agent 5 2349 Author's Address 2351 Dave Crocker 2352 Brandenburg InternetWorking 2353 675 Spruce Drive 2354 Sunnyvale, CA 94086 2355 USA 2357 Phone: +1.408.246.8253 2358 Email: dcrocker@bbiw.net