idnits 2.17.00 (12 Aug 2021) /tmp/idnits48624/draft-crocker-email-arch-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 451 has weird spacing: '...lly has the s...' == Line 608 has weird spacing: '...cerning exter...' == Line 628 has weird spacing: '...raction highl...' == Line 1007 has weird spacing: '... script going...' == Line 1040 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 (April 12, 2009) is 4786 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: 'MAIL-I18N' is defined on line 2025, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2298 (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2304 (ref. 'RFC3192') (Obsoleted by RFC 3192) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 4550 (Obsoleted by RFC 5550) ** Obsolete 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 April 12, 2009 5 Expires: October 14, 2009 7 Internet Mail Architecture 8 draft-crocker-email-arch-12 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 October 14, 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. Document Conventions . . . . . . . . . . . . . . . . . . . 7 74 2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 8 75 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 8 76 2.2. Mail Handling Service (MHS) Actors . . . . . . . . . . . . 11 77 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 14 78 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 3.2. Scope of Email Address Use . . . . . . . . . . . . . . . . 18 81 3.3. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 19 82 3.4. Message Identifier . . . . . . . . . . . . . . . . . . . . 19 83 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 21 84 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 24 85 4.1.4. Identity References in a Message . . . . . . . . . . . 25 86 4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 29 87 4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 31 88 4.4. Transition Modes . . . . . . . . . . . . . . . . . . . . . 35 89 4.5. Implementation and Operation . . . . . . . . . . . . . . . 35 90 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 36 91 5.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 5.2. ReSender . . . . . . . . . . . . . . . . . . . . . . . . . 38 93 5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 40 94 5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 41 95 5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 42 96 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 42 97 6.1. Security Considerations . . . . . . . . . . . . . . . . . 43 98 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 44 99 6.3. Internationalization . . . . . . . . . . . . . . . . . . . 44 100 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 101 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 45 102 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 47 103 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 49 104 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52 107 1. Introduction 109 Over its thirty-five year history, Internet Mail has changed 110 significantly in scale and complexity, as it has become a global 111 infrastructure service. These changes have been evolutionary, rather 112 than revolutionary, reflecting a strong desire to preserve both its 113 installed base and its usefulness. Today, Internet Mail is 114 distinguished by many independent operators, many different 115 components for providing service to users, as well as many different 116 components that transfer messages. 118 The underlying technical standards for Internet Mail comprise a rich 119 array of functional capabilities. The specifications form the core: 121 * Simple Mail Transfer Protocol (SMTP) [RFC0821], [RFC2821], 122 [RFC5321] moves a message through the Internet. 124 * Internet Mail Format (IMF) [RFC0733], [RFC0822], [RFC2822], 125 [RFC5321] defines a message object. 127 * Multipurpose Internet Mail Extensions (MIME) [RFC2045] defines 128 an enhancement to the message object that permits using multi- 129 media attachments. 131 Public collaboration on technical, operations, and policy activities 132 of email, including those that respond to the challenges of email 133 abuse, has brought a much wider range of participants into the 134 technical community. To collaborate productively on this large and 135 complex system, all participants must work from a common view of it 136 and use a common language to describe its components and the 137 interactions among them. But the many differences in perspective 138 currently make it difficult to know exactly what another participant 139 means. 141 It is the need to resolve these differences that motivates this 142 document, which describes the realities of the current system. 143 Internet Mail is the subject of ongoing technical, operations, and 144 policy work, and the discussions often are hindered by different 145 models of email service design and different meanings for the same 146 terms. 148 To serve as the necessary common frame of reference, this document 149 describes the enhanced Internet Mail architecture, reflecting the 150 current service. The document focuses on: 152 * Capturing refinements to the email model 154 * Clarifying functional roles for the architectural components 156 * Clarifying identity-related issues, across the email service 158 * Defining terminology for architectural components and their 159 interactions 161 1.1. History 163 The first standardized architecture for networked email specified a 164 simple split between the user world, in the form of Mail User Agents 165 (MUA), and the transfer world, in the form of the Mail Handling 166 Service (MHS), which is composed of Mail Transfer Agents (MTA) 167 [RFC1506]. The MHS accepts a message from one User and delivers it 168 to one or more other users, creating a virtual MUA-to-MUA exchange 169 environment. 171 As shown in Figure 1, this defines two logical layers of 172 interoperability. One is directly between Users. The other is among 173 the components along the transfer path. In addition, there is 174 interoperability between the layers, first when a message is posted 175 from the User to the MHS and later when it is delivered from the MHS 176 to the User. 178 The operational service has evolved, although core aspects of the 179 service, such as mailbox addressing and message format style, 180 remaining remarkably constant. The original distinction between the 181 user level and transfer level remains, but with elaborations in each. 182 The term "Internet Mail" is used to refer to the entire collection of 183 user and transfer components and services. 185 For Internet Mail, the term "end-to-end" usually refers to a single 186 posting and the set of deliveries that result from a single transit 187 of the MHS. A common exception is group dialogue that is mediated, 188 through a Mailing List; in this case, two postings occur before 189 intended Recipients receive an Author's message, as discussed in 190 Section 2.1.4. In fact, some uses of email consider the entire email 191 service, including Author and Recipient, as a subordinate component. 192 For these services, "end-to-end" refers to points outside the email 193 service. Examples are voicemail over email "[RFC3801], EDI over 194 email [RFC1767] and facsimile over email [RFC4142]. 196 +--------+ 197 ++================>| User | 198 || +--------+ 199 || ^ 200 +--------+ || +--------+ . 201 | User +==++=========>| User | . 202 +---+----+ || +--------+ . 203 . || ^ . 204 . || +--------+ . . 205 . ++==>| User | . . 206 . +--------+ . . 207 . ^ . . 208 . . . . 209 V . . . 210 +---+-----------------+------+------+---+ 211 | . . . . | 212 | .................>. . . | 213 | . . . | 214 | ........................>. . | 215 | . . | 216 | ...............................>. | 217 | | 218 | Mail Handling Service (MHS) | 219 +---------------------------------------+ 220 Legend: == lines indicate primary (possibly indirect) transfers; ... 221 lines indicate supporting transfers 223 Figure 1: Basic Internet Mail Service Model 225 End-to-end Internet Mail exchange is accomplished by using a 226 standardized infrastructure with these components and 227 characteristics: 229 * An email object 231 * Global addressing 233 * An asynchronous sequence of point-to-point transfer mechanisms 235 * No prior arrangement between MTAs or between Authors and 236 Recipients 238 * No prior arrangement between point-to-point transfer services 239 over the open Internet 241 * No requirement for Author, Originator, or Recipients to be 242 online at the same time 244 The end-to-end portion of the service is the email object, called a 245 "message." Broadly, the message itself distinguishes control 246 information, for handling, from the Author's content. 248 A precept to the design of mail over the open Internet is permitting 249 user-to-user and MTA-to-MTA interoperability without prior, direct 250 arrangement between the independent administrative authorities 251 responsible for handling a message. All participants rely on having 252 the core services universally supported and accessible, either 253 directly or through Gateways that act as translators between Internet 254 Mail and email environments conforming to other standards. Given the 255 importance of spontaneity and serendipity in interpersonal 256 communications, not requiring such prearrangement between 257 participants is a core benefit of Internet Mail and remains a core 258 requirement for it. 260 Within localized networks at the edge of the public Internet, prior 261 administrative arrangement often is required and can include access 262 control, routing constraints, and configuration of the information 263 query service. Although recipient authentication has usually been 264 required for message access since the beginning of Internet Mail, in 265 recent years it also has been required for message submission. In 266 these cases, a server validates the client's identity, whether by 267 explicit security protocols or by implicit infrastructure queries to 268 identify "local" participants. 270 1.2. Document Conventions 272 References to structured fields of a message use a two-part dotted 273 notation. The first part cites the document that contains the 274 specification for the field and the second is the name of the field. 275 Hence is the IMF From: header field in an email 276 content header and is the address in the SMTP 277 "Mail From" command. 279 When occurring without the IMF (rfc5322) qualifier, header field 280 names are shown with a colon suffix. For example, From:. 282 References to labels for actors, functions or components have the 283 first letter capitalized. 285 Also, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 286 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 287 this document are to be interpreted as described in RFC 2119 288 [RFC2119] [RFC2119]. 290 RFC EDITOR: Remove the following paragraph before publication. 292 Discussion venue: Please direct discussion about this document 293 to the IETF-SMTP mailing list . 295 2. Responsible Actor Roles 297 Internet Mail is a highly distributed service, with a variety of 298 actors playing different roles. These actors fall into three basic 299 types: 301 * User 303 * Mail Handling Service (MHS) 305 * ADministrative Management Domain (ADMD) 307 Although related to a technical architecture, the focus on actors 308 concerns participant responsibilities, rather than functionality of 309 modules. For that reason, the labels used are different from those 310 used in classic email architecture diagrams. 312 2.1. User Actors 314 Users are the sources and sinks of messages. Users can be people, 315 organizations, or processes. They can have an exchange that 316 iterates, and they can expand or contract the set of users that 317 participate in a set of exchanges. In Internet Mail, there are four 318 types of Users: 320 * Authors 322 * Recipients 324 * Return Handlers 326 * Mediators 328 Figure 2 shows the primary and secondary flows of messages among 329 them. 331 ++==========++ 332 || Author ||<..................................<.. 333 ++=++=++=++=++ . 334 || || || ++===========++ . 335 || || ++====>|| Recipient || . 336 || || ++=====+=====++ . 337 || || . . 338 || || ..........................>.+ 339 || || . 340 || || ................... . 341 || || . . . 342 || || V . . 343 || || +-----------+ ++=====+=====++ . 344 || ++========>| Mediator +===>|| Recipient || . 345 || +-----+-----+ ++=====+=====++ . 346 || . . . 347 || ..................+.......>.+ 348 || . 349 || ..............+.................. . 350 || . . . . 351 \/ V V ' . 352 +-----------+ +-----------+ ++=====+=====++ . 353 | Mediator +===>| Mediator +===>|| Recipient || . 354 +-----+-----+ +-----+-----+ ++=====+=====++ . 355 . . . . 356 .................+.................+.......>.. 357 Legend: == lines indicate primary (possibly indirect) transfers; ... 358 lines indicate supporting transfers 360 Figure 2: Relationships Among User Actors 362 From the user perspective, all mail transfer activities are performed 363 by a monolithic Mail Handling Service (MHS), even though the actual 364 service can be provided by many independent organizations. Users are 365 customers of this unified service. 367 Whenever any MHS actor sends information to back to an Author or 368 Originator in the sequence of handling a message, that actor is a 369 User. 371 2.1.1. Author 373 The Author is responsible for creating the message, its contents, and 374 its list of recipient addresses. The MHS transfers the message from 375 the Author and delivers it to the Recipients. The MHS has an 376 Originator role (Section 2.2.1) that correlates with the Author role. 378 2.1.2. Recipient 380 The Recipient is a consumer of the delivered message. The MHS has a 381 Receiver role (Section 2.2.4) that correlates with the Recipient 382 role. This is labeled Recv in Figure 3. 384 Any Recipient can close the user communication loop by creating and 385 submitting a new message that replies to the Author. An example of 386 an automated form of reply is the Message Disposition Notification 387 (MDN), which informs the Author about the Recipient's handling of the 388 message. (See Section 4.1.) 390 2.1.3. Return Handler 392 Also called "Bounce Handler", the Return Handler is a special form of 393 Recipient tasked with servicing notifications that the MHS generates, 394 as it transfers or delivers the message. These notices can be about 395 failures or completions and are sent to an address that is specified 396 by the Originator. This Return Handling address (also known as a 397 Return address) might have no visible characteristics in common with 398 the address of the Author or Originator. 400 2.1.4. Mediator 402 A Mediator receives, aggregates, reformulates, and redistributes 403 messages among Authors and Recipients who are the principals in 404 (potentially) protracted exchanges. This activity is easily confused 405 with the underlying MHS transfer exchanges. However, each serves 406 very different purposes and operates in very different ways. 408 When mail is delivered to the Mediator specified in the 409 RFC5321.RcptTo command for the original message, the MHS handles it 410 the same way as for any other Recipient. In particular, the MHS sees 411 each posting and delivery activity between sources and sinks as 412 independent; it does not see subsequent re-posting as a continuation 413 of a process. Because the Mediator originates messages, it can 414 receive replies. Hence, when submitting a reformulated message, the 415 Mediator is an Author, albeit an author actually serving as an agent 416 of one or more other authors. So a Mediator really is a full-fledged 417 User. Mediators are considered extensively in Section 5. 419 A Mediator attempts to preserve the original Author's information in 420 the message it reformulates but is permitted to make meaningful 421 changes to the message content or envelope. The MHS sees a new 422 message, but users receive a message that they interpret as being 423 from, or at least initiated by, the Author of the original message. 424 The role of a Mediator is not limited to merely connecting other 425 participants; the Mediator is responsible for the new message. 427 A Mediator's role is complex and contingent, for example, modifying 428 and adding content or regulating which users are allowed to 429 participate and when. The common example of this role is a group 430 Mailing List. In a more complex use, a sequence of Mediators could 431 perform a sequence of formal steps, such as reviewing, modifying, and 432 approving a purchase request. 434 A Gateway is a particularly interesting form of Mediator. It is a 435 hybrid of User and Relay that connects heterogeneous mail services. 436 Its purpose is to emulate a Relay. For a detailed discussion, see 437 Section 2.2.3. 439 2.2. Mail Handling Service (MHS) Actors 441 The Mail Handling Service (MHS) performs a single end-to-end transfer 442 on behalf of the Author to reach the Recipient addresses specified in 443 the original RFC5321.RcptTo commands. Exchanges that are either 444 mediated or iterative and protracted, such as those used for 445 collaboration over time are handled by the User actors, not by the 446 MHS actors. 448 Figure 3 shows the relationships among transfer participants in 449 Internet Mail. Although it shows the Originator (labeled Origin) as 450 distinct from the Author and Receiver (labeled Recv) as distinct from 451 Recipient, each pair of roles usually has the same actor. 452 Transfers typically entail one or more Relays. However direct 453 delivery from the Originator to Receiver is possible. Intra- 454 organization mail services usually have only one Relay. 455 ++==========++ ++===========++ 456 || Author || || Recipient || 457 ++====++====++ +--------+ ++===========++ 458 || | Return | /\ 459 || +-+------+ || 460 \/ . ^ || 461 +---------+ . . +---++---+ 462 | | . . | | 463 /--+---------+----------------------------+--------+----\ 464 | | | . . MHS | | | 465 | | Origin +<...... .................+ Recv | | 466 | | | ^ | | | 467 | +---++----+ . +--------+ | 468 | || . /\ | 469 | || ..............+.................. || | 470 | \/ . . . || | 471 | +-------+-+ +--+------+ +-+--++---+ | 472 | | Relay +=======>| Relay +=======>| Relay | | 473 | +---------+ +----++---+ +---------+ | 474 | || | 475 | || | 476 | \/ | 477 | +---------+ | 478 | | Gateway +-->... | 479 | +---------+ | 480 \-------------------------------------------------------/ 482 Legend: == lines indicate primary (possibly indirect) transfers or 483 roles; ... lines indicate supporting transfers or roles 485 Figure 3: Relationships Among MHS Actors 487 2.2.1. Originator 489 The Originator ensures that a message is valid for posting and then 490 submits it to a Relay. A message is valid if it conforms to both 491 Internet Mail standards and local operational policies. The 492 Originator can simply review the message for conformance and reject 493 it if it finds errors, or it can create some or all of the necessary 494 information. In effect, the Originator is responsible for the 495 functions of the Mail Submission Agent. 497 The Originator operates with dual allegiance. It serves the Author 498 and can be the same entity. But its role in assuring validity means 499 that it MUST also represent the local operator of the MHS, that is, 500 the local ADministrative Management Domain (ADMD). 502 The Originator also performs any post-submission, Author-related 503 administrative tasks associated with message transfer and delivery. 504 Notably, these tasks pertain to sending error and delivery notices, 505 enforcing local policies, and dealing with messages from the Author 506 that prove to be problematic for the Internet. The Originator is 507 accountable for the message content, even when it is not responsible 508 for it. The Author creates the message, but the Originator handles 509 any transmission issues with it. 511 2.2.2. Relay 513 The Relay performs MHS-level transfer-service routing and store-and- 514 forward, by transmitting or retransmitting the message to its 515 Recipients. The Relay adds trace information [RFC2505] but does not 516 modify the envelope information or the message content semantics. It 517 can modify message content representation, such as changing the form 518 of transfer encoding from binary to text, but only as required to 519 meet the capabilities of the next hop in the MHS. 521 A Mail Handling Service (MHS) network consists of a set of Relays. 522 This network is above any underlying packet-switching network that 523 might be used and below any Gateways or other Mediators. 525 In other words, email scenarios can involve three distinct 526 architectural layers, each providing its own type of data of store- 527 and-forward service: 529 * User Mediators 531 * MHS Relays 533 * Packet Switches 535 The bottom layer is the Internet's IP service. The most basic email 536 scenarios involve Relays and Switches. 538 When a Relay stops attempting to transfer a message, it becomes an 539 Author because it must send an error message to the Return address. 540 The potential for looping is avoided by omitting a Return address 541 from this message. 543 2.2.3. Gateway 545 A Gateway is a hybrid of User and Relay that connects heterogeneous 546 mail services. Its purpose is to emulate a Relay and the closer it 547 comes to this, the better. A Gateway operates as a User when it 548 needs the ability to modify message content. 550 Differences between mail services can be as small as minor syntax 551 variations, but they usually encompass significant, semantic 552 distinctions. One difference could be email addresses that are 553 hierarchical and machine-specific rather than a flat, global 554 namespace. Another difference could be support for text-only content 555 or multi-media. Hence the Relay function in a Gateway presents a 556 significant design challenge, if the resulting performance is to be 557 seen as nearly seamless. The challenge is to ensure user-to-user 558 functionality between the services, despite differences in their 559 syntax and semantics. 561 The basic test of Gateway design is whether an Author on one side of 562 a Gateway can send a useful message to a Recipient on the other side, 563 without requiring changes to any components in the Author's or 564 Recipient's mail services other than adding the Gateway. To each of 565 these otherwise independent services, the Gateway appears to be a 566 native participant. But the ultimate test of Gateway design is 567 whether the Author and Recipient can sustain a dialogue. In 568 particular, can a Recipient's MUA automatically formulate a valid 569 Reply that will reach the Author? 571 2.2.4. Receiver 573 The Receiver performs final delivery or sends the message to an 574 alternate address. It can also perform filtering and other policy 575 enforcement immediately before or after delivery. 577 2.3. Administrative Actors 579 Administrative actors can be associated with different organizations, 580 each with its own administrative authority. This operational 581 independence, coupled with the need for interaction between groups, 582 provides the motivation to distinguish among ADministrative 583 Management Domains (ADMDs ). Each ADMD can have vastly different 584 operating policies and trust-based decision-making. One obvious 585 example is the distinction between mail that is exchanged within an 586 organization and mail that is exchanged between independent 587 organizations. The rules for handling both types of traffic tend to 588 be quite different. That difference requires defining the boundaries 589 of each, and this requires the ADMD construct. 591 Operation of Internet Mail services is carried out by different 592 providers (or operators). Each can be an independent ADMD. This 593 independence of administrative decision-making defines boundaries 594 that distinguish different portions of the Internet Mail service. A 595 department that operates a local Relay, an IT department that 596 operates an enterprise Relay, and an ISP that operates a public 597 shared email service can be configured into many combinations of 598 administrative and operational relationships. Each is a distinct 599 ADMD, potentially having a complex arrangement of functional 600 components. Figure 4 depicts relationships among ADMDs. The 601 benefit of the ADMD construct is to facilitate discussion about 602 designs, policies and operations that need to distinguish between 603 internal issues and external ones. 605 The architectural impact of the need for boundaries between ADMDs is 606 discussed in [Tussle]. Most significant is that the entities 607 communicating across ADMD boundaries typically have the added burden 608 of enforcing organizational policies concerning external 609 communications. At a more mundane level, routing mail between ADMDs 610 can be an issue, such as needing to route mail between organizational 611 partners over specially trusted paths. 613 These are three basic types of ADMDs: 615 Edge: Independent transfer services in networks at the edge of 616 the open Internet Mail service. 618 Consumer: This might be a type of Edge service, as is common 619 for web-based email access. 621 Transit: Mail Service Providers (MSP) that offer value-added 622 capabilities for Edge ADMDs, such as aggregation and filtering. 624 The mail-level transit service is different from packet-level 625 switching. End-to-end packet transfers usually go through 626 intermediate routers; email exchange across the open Internet can be 627 directly between the Boundary MTAs of Edge ADMDs. This distinction 628 between direct and indirect interaction highlights the differences 629 discussed in Section 2.2.2 630 +--------+ +---------+ +-------+ +-----------+ 631 | ADMD1 |<===>| ADMD2 |<===>| ADMD3 |<===>| ADMD4 | 632 | ----- | | ----- | | ----- | | ----- | 633 | | | | | | | | 634 | Author | | | | | | Recipient | 635 | . | | | | | | ^ | 636 | V | | | | | | . | 637 | Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer | 638 | | | | | | | | 639 +--------+ +---------+ +-------+ +-----------+ 640 Legend: == lines indicate primary (possibly indirect) transfers or 641 roles; ... lines indicate supporting transfers or roles 643 Figure 4: Administrative Domain (ADMD) Example 645 Edge networks can use proprietary email standards internally. 646 However the distinction between Transit network and Edge network 647 transfer services is significant because it highlights the need for 648 concern over interaction and protection between independent 649 administrations. In particular, this distinction calls for 650 additional care in assessing the transitions of responsibility and 651 the accountability and authorization relationships among participants 652 in message transfer. 654 The interactions of ADMD components are subject to the policies of 655 that domain, which cover concerns such as these: 657 * Reliability 659 * Access control 661 * Accountability 663 * Content evaluation and modification 665 These policies can be implemented in different functional components, 666 according to the needs of the ADMD. For example, see [RFC5068]. 668 Consumer, Edge, and Transit services can be offered by providers that 669 operate component services or sets of services. Further, it is 670 possible for one ADMD to host services for other ADMDs. 672 These are common examples of ADMDs: 674 Enterprise Service Providers: 676 These ADMDs operate the internal data and/or the mail services 677 within an organization. 679 Internet Service Providers (ISP): 681 These ADMDs operate the underlying data communication services, 682 which are used by one or more Relay and User. ISPs are not 683 responsible for performing email functions, but they can 684 provide an environment in which those functions can be 685 performed. 687 Mail Service Providers: 689 These ADMDs operate email services, such as for consumers or 690 client companies. 692 Practical operational concerns demand that providers be involved in 693 administration and enforcement issues. This involvement can extend 694 to operators of lower-level packet services. 696 3. Identities 698 Internet Mail uses three forms of identity: mailbox, domain name, 699 message-ID and ENVID. Each must be globally unique. 701 3.1. Mailbox 703 "A mailbox sends and receives mail. It is a conceptual entity 704 which does not necessarily pertain to file storage." [RFC5322] 706 A mailbox is specified as an Internet Mail address . It 707 has two distinct parts, separated by an at-sign (@). The right side 708 is a globally interpreted domain name associated with an ADMD. 709 Domain names are discussed in Section 3.3. Formal Internet Mail 710 addressing syntax can support source routes, to indicate the path 711 through which a message ought to be sent. The use of source routes 712 is not common and has been deprecated in [RFC5321]. 714 The portion to the left of the at-sign contains a string that is 715 globally opaque and is called the . It is to be 716 interpreted only by the entity specified by the address's domain 717 name. Except as noted later in this section all other entities MUST 718 treat the as an uninterpreted literal string and MUST 719 preserve all of its original details. As such its public 720 distribution is equivalent to sending a Web browser "cookie" that is 721 only interpreted upon being returned to its creator. 723 Some local-part values have been standardized, for contacting 724 personnel at an organization. These names cover common operations 725 and business functions. [RFC2142] 727 It is common for sites to have local structuring conventions for the 728 left-hand side of an . This permits sub- 729 addressing, such as for distinguishing different discussion groups 730 used by the same participant. However it is worth stressing that 731 these conventions are strictly private to the user's organization and 732 MUST NOT be interpreted by any domain except the one listed in the 733 right side of the . The exceptions are those specialized 734 services that conform to public, standardized conventions, as noted 735 below. 737 Basic email addressing defines the as being globally 738 opaque. However there are some uses of email that add a 739 standardized, global schema to the value, such as between an author 740 and a Gateway. The details remain invisible to the 741 public email transfer infrastructure, but provide addressing and 742 handling instructions for further processing by the Gateway. 743 Standardized examples of such conventions are the telephone numbering 744 formats for VPIM [RFC3801] such as: 746 +16137637582@vpim.example.com 748 and iFax [RFC3192], such as: 750 FAX=+12027653000/T33S=1387@ifax.example.com 752 3.2. Scope of Email Address Use 754 Email addresses are being used far beyond their original role in 755 email transfer and delivery. In practical terms, an email address 756 string has become the common identifier for representing online 757 identity. Hence, it is essential to be clear about both the nature 758 and role of an identity string in a particular context and the entity 759 responsible for setting that string. For example, see Section 4.1.4, 760 Section 4.3.3 and Section 5. 762 3.3. Domain Names 764 A domain name is a global reference to an Internet resource, such as 765 a host, a service, or a network. A domain name usually maps to one 766 or more IP Addresses. Conceptually, the name can encompass an 767 organization, a collection of machines integrated into a homogeneous 768 service, or a single machine. A domain name can be administered to 769 refer to an individual user, but this is not common practice. The 770 name is structured as a hierarchical sequence of names, separated by 771 dots (.), with the top of the hierarchy being on the right end of the 772 sequence. There can be many names in the sequence -- that is, the 773 depth of the hierarchy can be substantial. Domain names are defined 774 and operated through the Domain Name System (DNS) [RFC1034], 775 [RFC1035], [RFC2181]. 777 When not part of a mailbox address, a domain name is used in Internet 778 Mail to refer to the ADMD or to the host that took action upon the 779 message, such as providing the administrative scope for a message 780 identifier or performing transfer processing. 782 3.4. Message Identifier 784 There are two standardized tags for identifying messages: Message-ID: 785 and ENVID. A Message-ID: pertains to content, and an ENVID pertains 786 to transfer. 788 3.4.1. Message-ID 790 Internet Mail standards provide for, at most, a single Message-ID:. 791 The Message-ID: for a single message, which is a user-level IMF tag, 792 has a variety of uses including threading, aiding identification of 793 duplicates, and DSN tracking. [RFC5322]. The Originator assigns the 794 Message-ID:. The Recipient's ADMD is the intended consumer of the 795 Message-ID:, although any actor along the transfer path can use it. 797 Message-ID: MUST be globally unique. Its format is similar to that 798 of a mailbox, with two distinct parts, separated by an at-sign (@). 799 Typically, the right side specifies the ADMD or host that assigns the 800 identifier, and the left side contains a string that is globally 801 opaque and serves to uniquely identify the message within the domain 802 referenced on the right side. The duration of uniqueness for the 803 message identifier is undefined. 805 When a message is revised in any way, the decision whether to assign 806 a new Message-ID: requires a subjective assessment to determine 807 whether the editorial content has been changed enough to constitute a 808 new message. [RFC5322] states that "a message identifier pertains to 809 exactly one instantiation of a particular message; subsequent 810 revisions to the message each receive new message identifiers." Yet 811 experience suggests that some flexibility is needed. An impossible 812 test is whether the recipient will consider the new message to be 813 equivalent to the old one. For most components of Internet Mail, 814 there is no way to predict a specific recipient's preferences on this 815 matter. Both creating and failing to create a new Message-ID: have 816 their downsides. 818 Here are some guidelines and examples: 820 * If a message is changed only in form, such as character 821 encoding, it is still the same message. 823 * If a message has minor additions to the content, such as a 824 mailing list tag at the beginning of the RFC5322.Subject header 825 field, or some mailing list administrative information added to 826 the end of the primary body-part text, it is probably the same 827 message. 829 * If a message has viruses deleted from it, it is probably the 830 same message. 832 * If a message has offensive words deleted from it, some 833 recipients will consider it the same message, but some will 834 not. 836 * If a message is translated into a different language, some 837 recipients will consider it the same message, but some will 838 not. 840 * If a message is included in a digest of messages, the digest 841 constitutes a new message. 843 * If a message is forwarded by a recipient, what is forwarded is 844 a new message. 846 * If a message is "redirected", such as using IMF "Resent-*" 847 header fields, some recipients will consider it the same 848 message, but some will not. 850 The absence of both objective, precise criteria for regenerating a 851 Message-ID: and strong protection associated with the string means 852 that the presence of an ID can permit an assessment that is 853 marginally better than a heuristic, but the ID certainly has no value 854 on its own for strict formal reference or comparison. For that 855 reason, the Message-ID: SHOULD NOT be used for any function that has 856 security implications. 858 3.4.2. ENVID 860 The ENVID (envelope identifier) can be used for message-tracking 861 purposes ([RFC3885], [RFC3464]) concerning a single posting/delivery 862 transfer. The ENVID labels a single transit of the MHS by a specific 863 message. So, the ENVID is used for one message posting, until that 864 message is delivered. A re-posting of the message, such as by a 865 Mediator, does not reuse that ENVID, but can use a new one, even 866 though the message might legitimately retain its original 867 Message-ID:. 869 The format of an ENVID is free form. Although its creator might 870 choose to impose structure on the string, none is imposed by Internet 871 standards. By implication, the scope of the string is defined by the 872 domain name of the Return Address. 874 4. Services and Standards 876 The Internet Mail architecture comprises six basic types of 877 functionality, which are arranged to support a store-and-forward 878 service. As shown in Figure 5, each type can have multiple 879 instances, some of which represent specialized roles. This section 880 considers the activities and relationships among these components, 881 and the Internet Mail standards that apply to them. 883 Message 885 Mail User Agent (MUA) 887 Author MUA (aMUA) 889 Recipient MUA (rMUA) 891 Message Submission Agent (MSA) 893 Author-focused MSA functions (aMSA) 895 MHS-focused MSA functions (hMSA) 897 Message Transfer Agent (MTA) 899 Message Delivery Agent (MDA) 900 Recipient-focused MDA functions (rMDA) 902 MHS-focused MDA functions (hMDA) 904 Message Store (MS) 906 Author MS (aMS) 908 Recipient MS (rMS) 910 This figure shows function modules and the standardized protocols 911 used between them. 913 ++========++ 914 || || +-------+ 915 ...........++ aMUA ||<............................+ Disp | 916 . || || +-------+ 917 . ++=+==+===++ ^ 918 . local,imap}| |{smtp,submission . 919 . +-----+ | | +--------+ . 920 . | aMS |<---+ | ........................>| Return | . 921 . +-----+ | . +--------+ . 922 . | . ***************** ^ . 923 . +-----V-.----*------------+ * . . 924 . MSA | +-------+ * +------+ | * . . 925 . | | aMSA +-(S)->| hMSA | | * . . 926 . | +-------+ * +--+---+ | * . . 927 V +------------*------+-----+ * . . 928 //==========\\ * V {smtp * . . 929 || MESSAGE || * +------+ * //===+===\\ . 930 ||----------|| MHS * | MTA | * || dsn || . 931 || ENVELOPE || * +--+---+ * \\=======// . 932 || smtp || * V {smtp * ^ ^ . 933 || CONTENT || * +------+ * . . //==+==\\ 934 || imf || * | MTA +....*...... . || mdn || 935 || mime || * +--+---+ * . \\=====// 936 \\==========// * smtp}| {local * . ^ 937 . MDA * | {lmtp * . . 938 . +----------------+------V-----+ * . . 939 . | +----------+ * +------+ | * . . 940 . | | | * | | +..*.......... . 941 . | | rMDA |<-(D)--+ hMDA | | * . 942 . | | | * | | |<.*........ . 943 . | +-+------+-+ * +------+ | * . . 944 . +------+---------*------------+ * . . 945 . smtp,local}| ***************** . . 946 . V . . 947 . +-----+ //===+===\\ . 948 . | rMS | || sieve || . 949 . +--+--+ \\=======// . 950 . |{imap,pop,local ^ . 951 . V . . 952 . ++==========++ . . 953 . || || . . 954 .......>|| rMUA ++........................... . 955 || ++................................... 956 ++==========++ 957 Legend: == lines indicate primary (possibly indirect) transfers or 958 roles; == bpxes indicate data objects; ... lines indicate supporting 959 transfers or roles; *** lines indicate aggregated service 960 Figure 5: Protocols and Services 962 4.1. Message Data 964 The purpose of the Mail Handling Service (MHS) is to exchange an IMF 965 message object among participants [RFC5322]. All of its underlying 966 mechanisms serve to deliver that message from its Author to its 967 Recipients. A message can be explicitly labeled as to its nature 968 [RFC3458]. 970 A message comprises a transit-handling envelope and the message 971 content. The envelope contains information used by the MHS. The 972 content is divided into a structured header and the body. The header 973 comprises transit handling trace information and structured fields 974 that are part of the Author's message content. The body can be 975 unstructured lines of text or a tree of multi-media subordinate 976 objects, called "body-parts" or attachments [RFC2045], [RFC2046], 977 [RFC2047], [RFC4288], [RFC4289], [RFC2049]. 979 In addition, Internet Mail has a few conventions for special control 980 data, notably: 982 Delivery Status Notification (DSN): 984 A Delivery Status Notification (DSN) is a message that can be 985 generated by the MHS (MSA, MTA, or MDA) and sent to the 986 RFC5321.MailFrom address. An MDA and MTA are shown as sources 987 of DSNs in Figure 5, and the destination is shown as Returns. 988 DSNs provide information about message transit, such as 989 transfer errors or successful delivery. [RFC3461] 991 Message Disposition Notification (MDN): 993 A Message Disposition Notification (MDN) is a message that 994 provides information about post-delivery processing, such as 995 indicating that the message has been displayed [RFC3798] or the 996 form of content that can be supported [RFC3297]. It can be 997 generated by an rMUA and is sent to the Disposition- 998 Notification-To addresses. The mailbox for this is shown as 999 Disp in Figure 5. 1001 Message Filtering (SIEVE): 1003 Sieve is a scripting language used to specify conditions for 1004 differential handling of mail, typically at the time of 1005 delivery [RFC5228]. Scripts can be conveyed in a variety of 1006 ways, such as a MIME part in a message. Figure 5 shows a Sieve 1007 script going from the rMUA to the MDA. However, filtering can 1008 be done at many different points along the transit path, and 1009 any one or more of them might be subject to Sieve directives, 1010 especially within a single ADMD. the Figure 5 shows only one 1011 relationship, for (relative) simplicity. 1013 4.1.1. Envelope 1015 Internet Mail has a fragmented framework for transit-related handling 1016 information. Information that is used directly by the MHS is called 1017 the "envelope." It directs handling activities by the transfer 1018 service and is carried in transfer service commands. That is, the 1019 envelope exists in the transfer protocol SMTP. [RFC5321] 1021 Trace information, such as RFC5322.Received, is recorded in the 1022 message header and is not subsequently altered. [RFC5322] 1024 4.1.2. Header Fields 1026 Header fields are attribute name/value pairs that cover an extensible 1027 range of email service parameters, structured user content, and user 1028 transaction meta-information. The core set of header fields is 1029 defined in [RFC5322]. It is common practice to extend this set for 1030 different applications. Procedures for registering header fields are 1031 defined in [RFC3864]. An extensive set of existing header field 1032 registrations is provided in [RFC4021]. 1034 One danger of placing additional information in header fields is that 1035 Gateways often alter or delete them. 1037 4.1.3. Body 1039 The body of a message might be lines of ASCII text or a 1040 hierarchically structured composition of multi-media body-part 1041 attachments, using MIME. [RFC2045], [RFC2046], [RFC2047], [RFC4288], 1042 [RFC2049] 1044 4.1.4. Identity References in a Message 1046 Table 1 lists the core identifiers present in a message during 1047 transit. 1049 +----------------------+----------------+---------------------------+ 1050 | Layer | Field | Set By | 1051 +----------------------+----------------+---------------------------+ 1052 | Message Body | MIME Header | Author | 1053 | Message header | From: | Author | 1054 | fields | | | 1055 | | Sender: | Originator | 1056 | | Reply-To: | Author | 1057 | | To:, CC:, BCC: | Author | 1058 | | Message-ID: | Originator | 1059 | | Received: | Originator, Relay, | 1060 | | | Receiver | 1061 | | Return-Path: | MDA, from MailFrom | 1062 | | Resent-*: | Mediator | 1063 | | List-Id: | Mediator | 1064 | | List-*: | Mediator | 1065 | SMTP | HELO/EHLO | Latest Relay Client | 1066 | | ENVID | Originator | 1067 | | MailFrom | Originator | 1068 | | RcptTo | Author | 1069 | | ORCPT | Originator | 1070 | IP | Source Address | Latest Relay Client | 1071 +----------------------+----------------+---------------------------+ 1073 Legend: Layer - The part of the email architecture that uses the 1074 identifier; Field - The protocol construct that contains the 1075 identifier; Set By - The actor role responsible for specifying the 1076 identifier value (and this can be different from the actor that 1077 performs the fill-in function for the protocol construct) 1079 Table 1: Layered Identities 1081 These are the most common address-related fields: 1083 RFC5322.From: Set by - Author 1085 Names and addresses for authors of the message content are 1086 listed in the From: field. 1088 RFC5322.Reply-To: Set by - Author 1090 If a Recipient sends a reply message that would otherwise use 1091 the RFC5322.From field addresses in the original message, the 1092 addresses in the RFC5322.Reply-To field are used instead. In 1093 other words, this field overrides the From: field for responses 1094 from Recipients. 1096 RFC5322.Sender: Set by - Originator 1098 This field specifies the address responsible for submitting the 1099 message to the transfer service. This field can be omitted if 1100 it contains the same address as RFC5322.From. However, 1101 omitting this field does not mean that no Sender is specified; 1102 it means that that header field is virtual and that the address 1103 in the From: field MUST be used. 1105 Specification of the notifications Return addresses, which are 1106 contained in RFC5321.MailFrom, is made by the RFC5322.Sender. 1107 Typically the Return address is the same as the Sender address. 1108 However, some usage scenarios require it to be different. 1110 RFC5322.To/.CC: Set by - Author 1112 These fields specify MUA Recipient addresses. However, some or 1113 all of the addresses in these fields might not be present in 1114 the RFC5321.RcptTo commands. 1116 The distinction between To and CC is subjective. Generally, a 1117 To addressee is considered primary and is expected to take 1118 action on the message. A CC addressee typically receives a 1119 copy as a courtesy. 1121 RFC5322.BCC: Set by - Author 1123 A copy of the message might be sent to an addressee whose 1124 participation is not to be disclosed to the RFC5322.To or 1125 RFC5322.CC Recipients and, usually, not to the other BCC 1126 Recipients. The BCC: header field indicates a message copy to 1127 such a Recipient. Use of this field is discussed in [RFC5322]. 1129 RFC5321.HELO/.EHLO: Set by - Originator, MSA, MTA 1131 Any SMTP client -- including Originator, MSA, or MTA -- can 1132 specify its hosting domain identity for the SMTP HELO or EHLO 1133 command operation. 1135 RFC3461.ENVID: Set by - Originator 1137 The MSA can specify an opaque string, to be included in a DSN, 1138 as a means of assisting the Return address recipient in 1139 identifying the message that produced a DSN or message 1140 tracking. 1142 RFC5321.MailFrom: Set by - Originator 1144 This field is an end-to-end string that specifies an email 1145 address for receiving return control information, such as 1146 returned messages. The name of this field is misleading, 1147 because it is not required to specify either the Author or the 1148 actor responsible for submitting the message. Rather, the 1149 actor responsible for submission specifies the RFC5321.MailFrom 1150 address. Ultimately, the simple basis for deciding which 1151 address needs to be in the RFC5321.MailFrom field is to 1152 determine which address must be informed about transfer-level 1153 problems (and possibly successes.) 1155 RFC5321.RcptTo: Set by - Author, Final MTA, MDA. 1157 This field specifies the MUA mailbox address of a Recipient. 1158 The string might not be visible in the message content header. 1159 For example, the IMF destination address header fields, such as 1160 RFC5322.To, might specify a mailing list mailbox, while the 1161 RFC5321.RcptTo address specifies a member of that list. 1163 RFC5321.ORCPT: Set by - Author. 1165 This is an optional parameter to the RCPT command, indicating 1166 the original address to which the current RCPT TO address 1167 corresponds, after a mapping was performed during transit. An 1168 ORCPT is the only reliable way to correlate a DSN from a multi- 1169 recipient message transfer with the intended recipient. 1171 RFC5321.Received: Set by - Originator, Relay, Mediator, Dest 1173 This field contains trace information, including originating 1174 host, Relays, Mediators, and MSA host domain names and/or IP 1175 Addresses. 1177 RFC5321.Return-Path: Set by - Originator 1179 The MDA records the RFC5321.MailFrom address into the 1180 RFC5322.Return-Path field. 1182 RFC2919.List-Id: Set by - Mediator Author 1184 This field provides a globally unique mailing list naming 1185 framework that is independent of particular hosts. [RFC2919] 1186 The identifier is in the form of a domain name; however, the 1187 string usually is constructed by combining the two parts of an 1188 email address. The result is rarely a true domain name, listed 1189 in the domain name service, although it can be. 1191 RFC2369.List-*: Set by - Mediator Author 1193 [RFC2369] defines a collection of message header fields for use 1194 by mailing lists. In effect, they supply list-specific 1195 parameters for common mailing list user operations. The 1196 identifiers for these operations are for the list itself and 1197 the user-as-subscriber. [RFC2369] 1199 RFC0791.SourceAddr: Set by - The Client SMTP sending host 1200 immediately preceding the current receiving SMTP server. 1202 [RFC0791] defines the basic unit of data transfer for the 1203 Internet: the IP Datagram. It contains a Source Address field 1204 that specifies the IP Address for the host (interface) from 1205 which the datagram was sent. This information is set and 1206 provided by the IP layer, which makes it independent of mail- 1207 level mechanisms. As such, it is often taken to be 1208 authoritative, although it is possible to provide false 1209 addresses. 1211 4.2. User-Level Services 1213 Interactions at the user level entail protocol exchanges, distinct 1214 from those that occur at lower layers of the Internet Mail MHS 1215 architecture that is, in turn, above the Internet Transport layer. 1216 Because the motivation for email, and much of its use, is for 1217 interaction among people, the nature and details of these protocol 1218 exchanges often are determined by the needs of interpersonal and 1219 group communication. To accommodate the idiosyncratic behavior 1220 inherent in such communication, only subjective guidelines, rather 1221 than strict rules, can be offered for some aspects of system 1222 behavior. Mailing Lists provide particularly salient examples. 1224 4.2.1. Mail User Agent (MUA) 1226 A Mail User Agent (MUA) works on behalf of User actors and User 1227 applications. It is their representative within the email service. 1229 The Author MUA (aMUA) creates a message and performs initial 1230 submission into the transfer infrastructure via a Mail Submission 1231 Agent (MSA). It can also perform any creation- and posting-time 1232 archival in its Message Store (aMS). An MUA aMS can organize 1233 messages in many different ways. A common model uses aggregations, 1234 called "folders"; in IMAP they are called "mailboxes". This model 1235 allows a folder for messages under development (Drafts), a folder for 1236 messages waiting to be sent (Queued or Unsent), and a folder for 1237 messages that have been successfully posted for transfer (Sent). But 1238 none of these folders is required. For example, IMAP allows drafts 1239 to be stored in any folder; so no Drafts folder needs to be present. 1241 The Recipient MUA (rMUA) works on behalf of the Recipient to process 1242 received mail. This processing includes generating user-level 1243 disposition control messages, displaying and disposing of the 1244 received message, and closing or expanding the user communication 1245 loop by initiating replies and forwarding new messages. 1247 NOTE: Although not shown in Figure 5, an MUA itself can have a 1248 distributed implementation, such as a "thin" user interface 1249 module on a constrained device such as a smartphone, with most 1250 of the MUA functionality running remotely on a more capable 1251 server. An example of such an architecture might use IMAP 1252 [RFC3501] for most of the interactions between an MUA client 1253 and an MUA server. An approach for such scenarios is defined 1254 by [RFC4550]. 1256 A Mediator is special class of MUA. It performs message re-posting, 1257 as discussed in Section 2.1. 1259 An MUA can be automated, on behalf of a user who is not present at 1260 the time the MUA is active. One example is a bulk sending service 1261 that has a timed-initiation feature. These services are not to be 1262 confused with a mailing list Mediator, since there is no incoming 1263 message triggering the activity of the automated service. 1265 A popular and problematic MUA is an automatic responder, such as one 1266 that sends out-of-office notices. This behavior might be confused 1267 with that of a Mediator, but this MUA is generating a new message. 1268 Automatic responders can annoy users of mailing lists unless they 1269 follow [RFC3834]. 1271 The identity fields are relevant to a typical MUA: 1273 RFC5322.From 1274 RFC5322.Reply-To 1276 RFC5322.Sender 1278 RFC5322.To, RFC5322.CC 1280 RFC5322.BCC 1282 4.2.2. Message Store (MS) 1284 An MUA can employ a long-term Message Store (MS). Figure 5 depicts 1285 an Author's MS (aMS) and a Recipient's MS (rMS). An MS can be 1286 located on a remote server or on the same machine as the MUA. 1288 An MS acquires messages from an MDA either proactively by a local 1289 mechanism or even with a standardized mechanism such as SMTP(!) or 1290 reactively by using POP or IMAP. The MUA accesses the MS either by a 1291 local mechanism or by using POP or IMAP. Using POP for individual 1292 message accesses, rather than for bulk transfer, is relatively rare 1293 and inefficient. 1295 4.3. MHS-Level Services 1297 4.3.1. Mail Submission Agent (MSA) 1299 A Mail Submission Agent (MSA) accepts the message submitted by the 1300 aMUA and enforces the policies of the hosting ADMD and the 1301 requirements of Internet standards. An MSA represents an unusual 1302 functional dichotomy. It represents the interests of the Author 1303 (aMUA) during message posting, to facilitate posting success; it also 1304 represents the interests of the MHS. In the architecture, these 1305 responsibilities are modeled, as shown in Figure 5, by dividing the 1306 MSA into two sub-components, aMSA and hMSA, respectively. Transfer 1307 of responsibility for a single message, from an Author's environment 1308 to the MHS, is called "posting". In Figure 5 it is marked as the (S) 1309 transition, within the MSA. 1311 The hMSA takes transit responsibility for a message that conforms to 1312 the relevant Internet standards and to local site policies. It 1313 rejects messages that are not in conformance. The MSA performs final 1314 message preparation for submission and effects the transfer of 1315 responsibility to the MHS, via the hMSA. The amount of preparation 1316 depends upon the local implementations. Examples of oMSA tasks 1317 include adding header fields, such as Date: and Message-ID:, and 1318 modifying portions of the message from local notations to Internet 1319 standards, such as expanding an address to its formal IMF 1320 representation. 1322 Historically, standards-based MUA/MSA message postings have used 1323 SMTP. [RFC5321] The standard currently preferred is SUBMISSION. 1324 [RFC4409] Although SUBMISSION derives from SMTP, it uses a separate 1325 TCP port and imposes distinct requirements, such as access 1326 authorization. 1328 These identities are relevant to the MSA: 1330 RFC5321.HELO/.EHLO 1332 RFC3461.ENVID 1334 RFC5321.MailFrom 1336 RFC5321.RcptTo 1338 RFC5321.Received 1340 RFC0791.SourceAddr 1342 4.3.2. Mail Transfer Agent (MTA) 1344 A Mail Transfer Agent (MTA) relays mail for one application-level 1345 "hop." It is like a packet-switch or IP router in that its job is to 1346 make routing assessments and to move the message closer to the 1347 Recipients. Of course, email objects are typically much larger than 1348 the payload of a packet or datagram, and the end-to-end latencies are 1349 typically much higher. Relaying is performed by a sequence of MTAs, 1350 until the message reaches a destination MDA. Hence, an MTA 1351 implements both client and server MTA functionality; it does not 1352 change addresses in the envelope or reformulate the editorial 1353 content. A change in data form, such as to MIME Content-Transfer- 1354 Encoding, is within the purview of an MTA, but removal or replacement 1355 of body content is not. An MTA also adds trace information. 1356 [RFC2505] 1358 NOTE: Within a destination ADMD, email relaying modules can 1359 make a variety of changes to the message, prior to delivery. 1360 In such cases, these modules are acting as Gateways, rather 1361 than MTAs. 1363 Internet Mail uses SMTP [RFC5321], [RFC0821] primarily to effect 1364 point-to-point transfers between peer MTAs. Other transfer 1365 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1366 most network layer mechanisms, the Internet Mail SMTP supports a 1367 basic level of reliability, by virtue of providing for retransmission 1368 after a temporary transfer failure. Unlike typical packet switches 1369 (and Instant Messaging services), Internet Mail MTAs are expected to 1370 store messages in a manner that allows recovery across service 1371 interruptions, such as host system shutdown. The degree of such 1372 robustness and persistence by an MTA can vary. The base SMTP 1373 specification provides a framework for protocol response codes. An 1374 extensible enhancement to this framework is defined in [RFC5248] 1376 Although quite basic, the primary routing mechanism for Internet Mail 1377 is the DNS MX record [RFC1035], which specifies an MTA through which 1378 the queried domain can be reached. This mechanism presumes a public, 1379 or at least a common, backbone that permits any attached MTA to 1380 connect to any other. 1382 MTAs can perform any of these well-established roles: 1384 Boundary MTA: An MTA that is part of an ADMD and interacts with 1385 MTAs in other ADMDs. This is also called a Border MTA. There 1386 can be different Boundary MTAs, according to the direction of 1387 mail-flow. 1389 Outbound MTA: An MTA that relays messages to other ADMDs. 1391 Inbound MTA: An MTA that receives inbound SMTP messages from 1392 MTA Relays in other ADMDs, for example, an MTA running on 1393 the host listed as the target of an MX record. 1395 Final MTA: The MTA that transfers a message to the MDA. 1397 These identities are relevant to the MTA: 1399 RFC5321.HELO/.EHLO 1401 RFC3461.ENVID 1403 RFC5321.MailFrom 1405 RFC5321.RcptTo 1406 RFC5322.Received: Set by - Relay Server 1408 RFC0791.SourceAddr 1410 4.3.3. Mail Delivery Agent (MDA) 1412 A transfer of responsibility from the MHS to a Recipient's 1413 environment (mailbox) is called "delivery." In the architecture, as 1414 depicted in Figure 5, delivery takes place within a Mail Delivery 1415 Agent (MDA) and is shown as the (D) transition from the MHS-oriented 1416 MDA component (hMDA) to the Recipient-oriented MDA component (rMDA). 1418 An MDA can provide distinctive, address-based functionality, made 1419 possible by its detailed information about the properties of the 1420 destination address. This information might also be present 1421 elsewhere in the Recipient's ADMD, such as at an organizational 1422 border (Boundary) Relay. However, it is required for the MDA, if 1423 only because the MDA is required to know where to deliver the 1424 message. 1426 Like an MSA, an MDA serves two roles, as depicted in Figure 5. 1427 Formal transfer of responsibility, called "delivery", is effected 1428 between the two components that embody these roles as shows as "(D)" 1429 in Figure 5. The MHS portion (hMDA) primarily functions as a server 1430 SMTP engine. A common additional role is to re-direct the message to 1431 an alternative address, as specified by the recipient addressee's 1432 preferences. The job of the recipient portion of the MDA (rMDA) is 1433 to perform any delivery actions that the Recipient specifies. 1435 Transfer into the MDA is accomplished by a normal MTA transfer 1436 mechanism. Transfer from an MDA to an MS uses an access protocol, 1437 such as POP or IMAP. 1439 NOTE: The term "delivery" can refer to the formal, MHS function 1440 specified here or to the first time a message is displayed to a 1441 Recipient. A simple, practical test for whether the MHS-based 1442 definition applies is whether a DSN can be generated. 1444 These identities are relevant to the MDA: 1446 RFC5321.Return-Path: Set by - Author Originator or Mediator 1447 Originator 1448 The MDA records the RFC5321.MailFrom address into the 1449 RFC5322.Return-Path field. 1451 RFC5322.Received: Set by - MDA server 1453 An MDA can record a Received: header field to indicate trace 1454 information, including source host and receiving host domain 1455 names and/or IP Addresses. 1457 4.4. Transition Modes 1459 From the origination site to the point of delivery, Internet Mail 1460 usually follows a "push" model. That is, the actor that holds the 1461 message initiates transfer to the next venue, typically with SMTP 1462 [RFC5321] or LMTP [RFC2033]. With a "pull" model, the actor that 1463 holds the message waits for the actor in the next venue to initiate a 1464 request for transfer. Standardized mechanisms for pull-based MHS 1465 transfer are ETRN [RFC1985] and ODMR [RFC2645]. 1467 After delivery, the Recipient's MUA (or MS) can gain access by having 1468 the message pushed to it or by having the receiver of access pull the 1469 message, such as by using POP [RFC1939] and IMAP [RFC3501]. 1471 4.5. Implementation and Operation 1473 A discussion of any interesting system architecture often bogs down 1474 when architecture and implementation are confused. An architecture 1475 defines the conceptual functions of a service, divided into discrete 1476 conceptual modules. An implementation of that architecture can 1477 combine or separate architectural components, as needed for a 1478 particular operational environment. For example, a software system 1479 that primarily performs message relaying is an MTA, yet it might 1480 also include MDA functionality. That same MTA system might be able 1481 to interface with non-Internet email services and thus perform both 1482 as an MTA and as a Gateway. 1484 Similarly, implemented modules might be configured to form 1485 elaborations of the architecture. An interesting example is a 1486 distributed MS. One portion might be a remote server and another 1487 might be local to the MUA. As discussed in [RFC1733], there are 1488 three operational relationships among such MSs: 1490 Online: The MS is remote, and messages are accessible only when 1491 the MUA is attached to the MS so that the MUA will re-fetch all 1492 or part of a message, from one session to the next. 1494 Offline: The MS is local to the user, and messages are 1495 completely moved from any remote store, rather than (also) 1496 being retained there. 1498 Disconnected: An rMS and a uMS are kept synchronized, for all or 1499 part of their contents, while they are connected. When they 1500 are disconnected, mail can arrive at the rMS and the user can 1501 make changes to the uMS. The two stores are re-synchronized 1502 when they are reconnected. 1504 5. Mediators 1506 Basic message transfer from Author to Recipients is accomplished by 1507 using an asynchronous store-and-forward communication infrastructure 1508 in a sequence of independent transmissions through some number of 1509 MTAs. A very different task is a sequence of postings and deliveries 1510 through Mediators. A Mediator forwards a message, through a re- 1511 posting process. The Mediator shares some functionality with basic 1512 MTA relaying, but has greater flexibility in both addressing and 1513 content than is available to MTAs. 1515 This is the core set of message information that is commonly set by 1516 all types of Mediators: 1518 RFC5321.HELO/.EHLO: Set by - Mediator Originator 1520 RFC3461.ENVID: Set by - Mediator Originator 1522 RFC5321.RcptTo: Set by - Mediator Author 1524 RFC5321.Received: Set by - Mediator Dest 1526 The Mediator can record received information, to indicate the 1527 delivery to the original address and submission to the alias 1528 address. The trace of Received: header fields can include 1529 everything from original posting, through relaying, to final 1530 delivery. 1532 The aspect of a Mediator that distinguishes it from any other MUA 1533 creating a message is that a Mediator preserves the integrity and 1534 tone of the original message, including the essential aspects of its 1535 origination information. The Mediator might also add commentary. 1537 Examples of MUA messages that a Mediator does not create include: 1539 New message that forwards an existing message: 1541 Although this action provides a basic template for a class of 1542 Mediators, its typical occurrence is not, itself, an example of 1543 a Mediator. The new message is viewed as being from the actor 1544 that is doing the forwarding, rather than from the original 1545 Author. 1547 A new message encapsulates the original message and is seen as 1548 from the new Originator. This Mediator Originator might add 1549 commentary and can modify the original message content. 1550 Because the forwarded message is a component of the message 1551 sent by the new Originator, the new message creates a new 1552 dialogue. However the final Recipient still sees the contained 1553 message as from the original Author. 1555 Reply: 1557 When a Recipient responds to the Author of a message, the new 1558 message is not typically viewed as a forwarding of the 1559 original. Its focus is the new content, although it might 1560 contain all or part of the material from the original message. 1561 The earlier material is merely contextual and secondary. This 1562 includes automated replies, such as vacation out-of-office 1563 notices, as discussed in Section 4.2.1. 1565 Annotation: 1567 The integrity of the original message is usually preserved, but 1568 one or more comments about the message are added in a manner 1569 that distinguishes commentary from original text. The primary 1570 purpose of the new message is to provide commentary from a new 1571 Author, similar to a Reply. 1573 The remainder of this section describes common examples of 1574 Mediators. 1576 5.1. Alias 1578 One function of an MDA is to determine the internal location of a 1579 mailbox in order to perform delivery. An Alias is a simple re- 1580 addressing facility that provides one or more new Internet Mail 1581 addresses, rather than a single, internal one; the message continues 1582 through the transfer service, for delivery to one or more alternate 1583 addresses. Although typically implemented as part of an MDA, this 1584 facility is a Recipient function. It resubmits the message, although 1585 all handling information except the envelope recipient 1586 (rfc5321.RcptTo) address is retained. In particular, the Return 1587 address (rfc5321.MailFrom) is unchanged. 1589 What is distinctive about this forwarding mechanism is how closely it 1590 resembles normal MTA store-and-forward relaying. Its only 1591 significant difference is that it changes the RFC5321.RcptTo value. 1592 Because this change is so small, aliasing can be viewed as a part of 1593 the lower-level mail relaying activity. However, this small change 1594 has a large semantic impact: The designated recipient has chosen a 1595 new recipient. 1597 NOTE: When the replacement list includes more than one address, 1598 the alias is increasingly likely to have delivery problems. 1599 Any problem reports go to the original Author, not the 1600 administrator of the alias entry. This makes it more difficult 1601 to resolve the problem, because the original Author has no 1602 knowledge of the Alias mechanism. 1604 Including the core set of message information listed at the beginning 1605 of this section, Alias typically changes: 1607 RFC5322.To/.CC/.BCC: Set by - Author 1609 These fields retain their original addresses. 1611 RFC5321.MailFrom: Set by - Author 1613 The benefit of retaining the original MailFrom value is to 1614 ensure that an actor related to the originating ADMD knows 1615 there has been a delivery problem. On the other hand, the 1616 responsibility for handling problems, when transiting from the 1617 original recipient mailbox to the alias mailbox usually lies 1618 with that original Recipient, because the Alias mechanism is 1619 strictly under that Recipient's control. Retaining the 1620 original MailFrom address prevents this. 1622 5.2. ReSender 1624 Also called the ReDirector, the ReSender's actions differ from 1625 forwarding because the Mediator "splices" a message's addressing 1626 information to connect the Author of the original message with the 1627 Recipient of the new message. This connection permits them to have 1628 direct exchange, using their normal MUA Reply functions, while also 1629 recording full reference information about the Recipient who served 1630 as a Mediator. Hence, the new Recipient sees the message as being 1631 from the original Author, even if the Mediator adds commentary. 1633 Including the core set of message information listed at the beginning 1634 of this section, these identities are relevant to a resent message: 1636 RFC5322.From: Set by - original Author 1638 Names and addresses for the original Author of the message 1639 content are retained. The free-form (display-name) portion of 1640 the address might be modified to provide informal reference to 1641 the ReSender. 1643 RFC5322.Reply-To: Set by - original Author 1645 If this field is present in the original message, it is 1646 retained in the resent message. 1648 RFC5322.Sender: Set by - Author's Originator or Mediator 1649 Originator. 1651 RFC5322.To/.CC/.BCC: Set by - original Author 1653 These fields specify the original message Recipients. 1655 RFC5322.Resent-From: Set by - Mediator Author 1657 This address is of the original Recipient who is redirecting 1658 the message. Otherwise, the same rules apply to the Resent- 1659 From: field as to an original RFC5322.From field. 1661 RFC5322.Resent-Sender: Set by - Mediator Originator 1663 The address of the actor responsible for resubmitting the 1664 message. As with RFC5322.Sender, this field can be omitted 1665 when it contains the same address as RFC5322.Resent-From. 1667 RFC5322.Resent-To/-CC/-BCC: Set by: Mediator Author 1669 The addresses of the new Recipients who are now able to reply 1670 to the original author. 1672 RFC5321.MailFrom: Set by - Mediator Originator 1673 The actor responsible for resubmission (RFC5322.Resent-Sender) 1674 is also responsible for specifying the new MailFrom address. 1676 5.3. Mailing Lists 1678 A Mailing List receives messages as an explicit addressee and then 1679 re-posts them to a list of subscribed members. The Mailing List 1680 performs a task that can be viewed as an elaboration of the ReSender. 1681 In addition to sending the new message to a potentially large number 1682 of new Recipients, the Mailing List can modify content, for example, 1683 by deleting attachments, converting the format, and adding list- 1684 specific comments. Mailing Lists also archive messages posted by 1685 Authors. Still the message retains characteristics of being from the 1686 original Author. 1688 Including the core set of message information listed at the beginning 1689 of this section, these identities are relevant to a mailing list 1690 processor, when submitting a message: 1692 RFC2919.List-Id: Set by - Mediator Author 1694 RFC2369.List-*: Set by - Mediator Author 1696 RFC5322.From: Set by - original Author 1698 Names and email addresses for the original Author of the 1699 message content are retained. 1701 RFC5322.Reply-To: Set by - Mediator or original Author 1703 Although problematic, it is common for a Mailing List to assign 1704 its own addresses to the Reply-To: header field of messages 1705 that it posts. This assignment is intended to ensure that 1706 replies go to all list members, rather than to only the 1707 original Author. As a User actor, a Mailing List is the Author 1708 of the new message and can legitimately set the Reply-To: 1709 value. As a Mediator attempting to represent the message on 1710 behalf of its original Author, creating or modifying a 1711 Reply-To: field can be viewed as violating that Author's 1712 intent. When the Reply-To is modified in this way, a reply 1713 that is meant only for the original Author will instead go to 1714 the entire list. When the Mailing List does not set the field, 1715 a reply meant for the entire list can instead go only to the 1716 original Author. At best, either choice is a matter of group 1717 culture for the particular list. 1719 RFC5322.Sender: Set by - Author Originator or Mediator 1720 Originator 1722 This field usually specifies the address of the actor 1723 responsible for Mailing List operations. Mailing Lists that 1724 operate in a manner similar to a simple MTA Relay preserve as 1725 much of the original handling information as possible, 1726 including the original RFC5322.Sender field. (Note that this 1727 mode of operation causes the Mailing List to behave much like 1728 an Alias, with a possible difference in number of new 1729 addressees.) 1731 RFC5322.To/.CC: Set by - original Author 1733 These fields usually contain the original list of Recipient 1734 addresses. 1736 RFC5321.MailFrom: Set by - Mediator Originator 1738 Because a Mailing List can modify the content of a message in 1739 any way, it is responsible for that content; that is, it is an 1740 Author. As such, the Return Address is specified by the 1741 Mailing List. Although it is plausible for the Mailing List to 1742 re-use the Return Address employed by the original Originator, 1743 notifications sent to that address after a message has been 1744 processed by a Mailing List could be problematic. 1746 5.4. Gateways 1748 A Gateway performs the basic routing and transfer work of message 1749 relaying, but it also is permitted to modify content, structure, 1750 address, or attributes as needed to send the message into a messaging 1751 environment that operates under different standards or potentially 1752 incompatible policies. When a Gateway connects two differing 1753 messaging services, its role is easy to identify and understand. 1754 When it connects environments that follow similar technical 1755 standards, but significantly different administrative policies, it is 1756 easy to view a Gateway as merely an MTA. 1758 The critical distinction between an MTA and a Gateway is that a 1759 Gateway can make substantive changes to a message to map between the 1760 standards. In virtually all cases, this mapping results in some 1761 degree of semantic loss. The challenge of Gateway design is to 1762 minimize this loss. Standardized gateways to Internet Mail are 1763 facsimile [RFC4143], voicemail [RFC3801], and MMS [RFC4356] 1765 A Gateway can set any identity field available to an MUA. Including 1766 the core set of message information listed at the beginning of this 1767 section, these identities are typically relevant to Gateways: 1769 RFC5322.From: Set by - original Author 1771 Names and addresses for the original Author of the message 1772 content are retained. As for all original addressing 1773 information in the message, the Gateway can translate addresses 1774 as required to continue to be useful in the target environment. 1776 RFC5322.Reply-To: Set by - original Author 1778 The Gateway SHOULD retain this information, if it is present. 1779 The ability to perform a successful reply by a Recipient is a 1780 typical test of Gateway functionality. 1782 RFC5322.Sender: Set by - Author Originator or Mediator 1783 Originator 1785 This field can retain the original value or can be set to a new 1786 address. 1788 RFC5322.To/.CC/.BCC: Set by - original Recipient 1790 These fields usually retain their original addresses. 1792 RFC5321.MailFrom: Set by - Author Originator or Mediator 1793 Originator 1795 The actor responsible for handling the message can specify a 1796 new address to receive handling notices. 1798 5.5. Boundary Filter 1800 To enforce security boundaries, organizations can subject messages to 1801 analysis, for conformance with its safety policies. An example is 1802 detection of content classed as spam or a virus. A filter might 1803 alter the content, to render it safe, such as by removing content 1804 deemed unacceptable. Typically, these actions add content to the 1805 message that records the actions. 1807 6. Considerations 1808 6.1. Security Considerations 1810 This document describes the existing Internet Mail architecture. It 1811 introduces no new capabilities. The security considerations of this 1812 deployed architecture are documented extensively in the technical 1813 specifications referenced by this document. These specifications 1814 cover classic security topics, such as authentication and privacy. 1815 For example, email transfer protocols can use standardized mechanisms 1816 for operation over authenticated and/or encrypted links, and message 1817 content has similar protection standards available. Examples of such 1818 mechanisms include SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP 1819 [RFC4880], and S/MIME [RFC3851]. 1821 The core of the Internet Mail architecture does not impose any 1822 security requirements or functions on the end-to-end or hop-by-hop 1823 components. For example, it does not require participant 1824 authentication and does not attempt to prevent data disclosure. 1826 Particular message attributes might expose specific security 1827 considerations. For example, the blind carbon copy feature of the 1828 architecture invites disclosure concerns, as discussed in section 7.2 1829 of [RFC5321] and section 5 of [RFC5322]. Transport of text or non- 1830 text content in this architecture has security considerations that 1831 are discussed in [RFC5322], [RFC2045], [RFC2046], and [RFC4288] as 1832 well as the security considerations present in the IANA media types 1833 registry for the respective types. 1835 Agents that automatically respond to email raise significant security 1836 considerations, as discussed in [RFC3834]. Gateway behaviors affect 1837 end-to-end security services, as discussed in [RFC2480]. Security 1838 considerations for boundary filters are discussed in [RFC5228]. 1840 See section 7.1 of [RFC5321] for a discussion of the topic of 1841 origination validation. As mentioned in Section 4.1.4, it is common 1842 practice for components of this architecture to use the 1843 [RFC0791].SourceAddr to make policy decisions [RFC2505], although the 1844 address can be "spoofed". It is possible to use it without 1845 authorization. SMTP and Submission authentication [RFC4954], 1846 [RFC4409] provide more secure alternatives. 1848 The discussion of trust boundaries, ADMDs, actors, roles, and 1849 responsibilities in this document highlights the relevance and 1850 potential complexity of security factors for operation of an Internet 1851 mail service. The core design of Internet Mail to encourage open and 1852 casual exchange of messages has met with scaling challenges, as the 1853 population of email participants has grown to include those with 1854 problematic practices. For example, spam, as defined in [RFC2505], 1855 is a by-product of this architecture. A number of standards track or 1856 BCP documents on the subject have been issued. [RFC2505], [RFC5068], 1857 [RFC3685] 1859 6.2. IANA Considerations 1861 This document has no actions for IANA. 1863 6.3. Internationalization 1865 The core Internet email standards are based on the use of US-ASCII. 1866 That is SMTP [RFC5321] and IMF [RFC5322], as well as their 1867 predecessors, describe the transport and composition of messages 1868 composed strictly of US-ASCII 7-bit encoded characters. The 1869 standards have been incrementally enhanced to allow for characters 1870 outside of this limited set, while retaining mechanisms for 1871 backwards-compatibility. Specifically: 1873 o The MIME specifications [RFC2045], [RFC2046], [RFC2047] and 1874 [RFC2298] allow for the use of coded character sets and character 1875 encoding schemes ("charsets" in MIME terminology) other than US- 1876 ASCII. MIME's [RFC2046] allows the textual content of a message 1877 to have a label affixed that specifies the charset used in that 1878 content. Equally MIME's [RFC2047] allows the textual content of 1879 certain header fields in a message to be similarly labeled. 1880 However, since messages might be transported over SMTP 1881 implementations only capable of transporting 7-bit encoded 1882 characters, MIME's [RFC2045] also provides for "content transfer 1883 encoding" so that characters of other charsets can be re-encoded 1884 as an overlay to US-ASCII. 1886 o MIME's [RFC2045] allows for the textual content of a message to be 1887 in an 8-bit character encoding scheme. In order to transport 1888 these without re-encoding them, the SMTP specification supports an 1889 option [RFC1652] that permits the transport of such textual 1890 content. However, the [RFC1652] option does not address the use 1891 of 8-bit content in message header fields, and therefore [RFC2047] 1892 encoding is still required for those. 1894 o A series of experimental protocols on Email Address 1895 Internationalization (EAI) have been released that extend SMTP and 1896 IMF to allow for 8-bit encoded characters to appear in addresses 1897 and other information throughout the header fields of messages. 1898 [RFC5335] specifies the format of such message header fields 1899 (which encode the characters in UTF-8), and [RFC5336] specifies an 1900 SMTP option for the transport of these messages. 1902 Hence, the use of UTF-8 is fully established in existing Internet 1903 mail. However support for long-standing encoding forms is retained 1904 and is still used. 1906 7. References 1908 7.1. Normative 1910 [RFC0791] Postel, J., "Internet Protocol", RFC 791, 1981 September. 1912 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1913 STD 13, RFC 1034, November 1987. 1915 [RFC1035] Mockapetris, P., "Domain names - implementation and 1916 specification", STD 13, RFC 1035, November 1987. 1918 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1919 STD 53, RFC 1939, May 1996. 1921 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1922 Extensions (MIME) Part One: Format of Internet Message 1923 Bodies", RFC 2045, November 1996. 1925 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1926 Extensions (MIME) Part Two: Media Types", RFC 2046, 1927 November 1996. 1929 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1930 Part Three: Message Header Extensions for Non-ASCII Text", 1931 RFC 2047, November 1996. 1933 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1934 Extensions (MIME) Part Five: Conformance Criteria and 1935 Examples", RFC 2049, November 1996. 1937 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1938 Requirement Levels", BCP 14, RFC 2119, March 1997. 1940 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1941 Specification", RFC 2181, July 1997. 1943 [RFC2298] Fajman, R., "An Extensible Message Format for Message 1944 Disposition Notifications", RFC 2298, March 1998. 1946 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1947 for Core Mail List Commands and their Transport through 1948 Message Header Fields", RFC 2369, July 1998. 1950 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1951 Addresses", RFC 2645, August 1999. 1953 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1954 April 2001. 1956 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1957 April 2001. 1959 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1960 and Namespace for the Identification of Mailing Lists", 1961 RFC 2919, March 2001. 1963 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet 1964 Mail", RFC 2304, October 2001. 1966 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 1967 Negotiation for Messaging Services based on Email", 1968 RFC 3297, July 2002. 1970 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1971 Context for Internet Mail", RFC 3458, January 2003. 1973 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1974 Extension for Delivery Status Notifications (DSNs)", 1975 RFC 3461, January 2003. 1977 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1978 4rev1", RFC 3501, March 2003. 1980 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1981 Notification", RFC 3798, May 2004. 1983 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 1984 Electronic Mail", RFC 3834, August 2004. 1986 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1987 Procedures for Message Header Fields", RFC 3864, 1988 September 2004. 1990 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 1991 Header Fields", RFC 4021, March 2005. 1993 [RFC4288] Freed, N., Klensin, J., and J. Postel, "Media Type 1994 Specifications and Registration Procedures", BCP 13, 1995 RFC 4288, December 2005. 1997 [RFC4289] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1998 Internet Mail Extensions (MIME) Part Four: Registration 1999 Procedures", BCP 13, RFC 4289, December 2005. 2001 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 2002 RFC 4409, April 2006. 2004 [RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support 2005 Diverse Service Environments (Lemonade) Profile", 2006 June 2006. 2008 [RFC5228] Showalter, T., "Sieve: A Mail Filtering Language", 2009 RFC 5228. 2011 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 2012 Mail System Status Codes", RFC 5248, June 2008. 2014 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2015 October 2008. 2017 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2018 October 2008. 2020 [RFC5335] TWNIC, "Internationalized Email Headers", RFC 5335, 2021 September 2008. 2023 7.2. Informative 2025 [MAIL-I18N] 2026 Internet Mail Consortium, "Using International Characters 2027 in Internet Mail", IMC IMCR-010, August 1998. 2029 [RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, 2030 "Standard for the Format of ARPA Network Text Messages", 2031 RFC 733, November 1977. 2033 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 2034 RFC 821, August 1982. 2036 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 2037 text messages", STD 11, RFC 822, August 1982. 2039 [RFC1506] Houttuin, J., "A Tutorial on Gatewaying between X.400 and 2040 Internet Mail", RFC 1506, August 1993. 2042 [RFC1652] MCI, Innosoft, Dover Beach Consulting, Inc., Network 2043 Management Associates, Inc., and Silicon Graphics, Inc., 2044 "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, 2045 July 1994. 2047 [RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4", 2048 December 1994. 2050 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 2051 RFC 1767, March 1995. 2053 [RFC1985] De Winter, J., "SMTP Service Extension for Remote 2054 Message Queue Starting", August 1996. 2056 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 2057 October 1996. 2059 [RFC2142] Crocker, D., "Mailbox Names for Common services, Roles and 2060 Functions", RFC 2142, May 1997. 2062 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 2064 [RFC2480] Freed, N., "Gateways and MIME Security Multiparts", 2065 RFC 2480, January 1999. 2067 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 2068 RFC 2505, February 1999. 2070 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 2071 Transport Layer Security", RFC 3207, February 2002. 2073 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 2074 for Delivery Status Notifications", RFC 3464, 2075 January 2003. 2077 [RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest 2078 Extensions", RFC 3685, February 2004. 2080 [RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 2081 Mail - version 2 (VPIMv2)", RFC 3801, June 2004. 2083 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 2084 Extensions (S/MIME) Version 3.1 Message Specification", 2085 RFC 3851, July 2004. 2087 [RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for 2088 Message Tracking", RFC 3885, September 2004. 2090 [RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for 2091 Internet Mail: FFPIM", December 2005. 2093 [RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail 2094 (IFAX) Service of ENUM", RFC 4143, November 2005. 2096 [RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging 2097 Service (MMS) and Internet Mail", RFC 4356, January 2006. 2099 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2100 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 2102 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 2103 Extension for Authentication", RFC 4954, July 2007. 2105 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 2106 E. Allman, "Email Submission Operations: Access and 2107 Accountability Requirements", RFC 5068, BCP 134, Nov 2007. 2109 [RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for 2110 Internationalized Email Addresses", RFC 5336, 2111 September 2008. 2113 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 2114 "Tussle in Cyberspace: Defining Tomorrow's Internet", 2115 ACM SIGCOMM, 2002. 2117 Appendix A. Acknowledgements 2119 This work began in 2004 and has evolved through numerous rounds of 2120 community review; it derives from a section in an early version of 2121 [RFC5068]. Over its 4 years of development, the draft has gone 2122 through 12 incremental versions, with vigorous community review that 2123 produced many substantive changes. Review was performed in the IETF 2124 and other email technical venues. Although not a formal activity of 2125 the IETF, issues with the document's contents were resolved using the 2126 classic style of IETF community open, group decision-making. The 2127 document is already cited in other work, such as for IMAP and Sieve 2128 specifications and for academic classwork. The step of standardizing 2129 is useful to provide a solid and stable reference to the Internet's 2130 now-complex email service. 2132 Details of the Originator actor role was greatly clarified during 2133 discussions in the IETF's Marid working group. 2135 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 2136 insight on the framework and details of the original drafts, as did 2137 Chris Newman for the final versions, while also serving as cognizant 2138 Area Director for the document. Tony Hansen served as document 2139 shepherd, through the IETF process. 2141 Later reviews and suggestions were provided by Eric Allman, Nathaniel 2142 Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, 2143 Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John 2144 Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, 2145 Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. 2146 Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, and Greg 2147 Vaudreuil. 2149 Diligent early proof-reading was performed by Bruce Lilly. Diligent 2150 technical editing was provided by Susan Hunziker. 2152 The final stages of development for this document were guided by a 2153 design team comprising: Alexey Melnikov, Pete Resnick, Carl S. 2154 Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen and Tony 2155 Finch. Pete Resnick developed the final version of the section on 2156 internationalization. 2158 Index 2159 12 2161 A 2162 accountability 13 2163 accountable 13-14 2164 Actor 2165 Administrative 14 2166 Author 9 2167 Consumer 15 2168 Edge 15 2169 Gateway 14 2170 Originator 12 2171 Recipient 10 2172 Return Handler 10 2173 Transit 15 2174 Actors 2175 MHS 11 2176 ADMD 13-15, 19, 25, 31, 38 2177 Administrative Actors 14 2178 Administrative Management Domain 13 2179 aMSA 31 2180 Author 9, 12 2181 author 35 2183 B 2184 body-parts 24 2185 bounce handler 10 2186 boundary 15 2188 C 2189 Consumer Actor 15 2190 content 11, 13-14, 20, 24, 32 2192 D 2193 delivery 5, 10, 12-14, 18, 24-25, 35, 38 2194 Discussion of document 8 2196 E 2197 Edge Actor 15 2198 end-to-end 5 2199 envelope 10, 13, 21, 24-25, 32, 38 2200 ETRN 35 2202 G 2203 Gateway 11, 14 2205 H 2206 header 24 2207 hMSA 31 2209 I 2210 Internet Mail 5 2212 L 2213 LMTP 35 2214 local-part 18 2216 M 2217 Mail 5 2218 Mail From 38 2219 Mail Handling Service 5, 11 2220 Mail Submission Agent 12 2221 Mail Transfer Agent 5 2222 Mail User Agent 5 2223 mailbox 38 2224 MDA 38 2225 MDN 10 2226 message 7, 24 2227 Message Disposition Notification 10 2228 MHS 5, 10-11, 13, 21-22, 24-25 2229 Actors 11 2230 MSA 12, 31 2231 MTA 5, 15 2232 boundary 15 2233 MUA 5, 14, 30-31 2235 O 2236 ODMR 35 2237 Originator 10, 12 2239 P 2240 posting 5, 10, 12, 21, 30-31, 35, 38 2241 pull 35 2242 push 35 2244 R 2245 RcptTo 11 2246 Receiver 12 2247 Recipient 10, 12, 38 2248 recipient 35 2249 relay 12 2250 responsibility 31 2251 responsible 13-14 2252 Return address 38 2253 Return Handler 10 2254 role 10, 18 2255 Author 9 2256 Originator 12 2257 Recipient 10 2259 S 2260 SIEVE 24 2261 SMTP 35 2263 T 2264 transfer 12-14 2265 Transit Actor 15 2266 transition 31 2268 U 2269 UA 5 2270 User Agent 5 2272 Author's Address 2274 Dave Crocker 2275 Brandenburg InternetWorking 2276 675 Spruce Drive 2277 Sunnyvale, CA 94086 2278 USA 2280 Phone: +1.408.246.8253 2281 Email: dcrocker@bbiw.net