idnits 2.17.1 draft-crocker-email-arch-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2019. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2030. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2037. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2043. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2008) is 5904 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.klensin-rfc2821bis' is mentioned on line 307, but not defined ** Obsolete undefined reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3028 (Obsoleted by RFC 5228, RFC 5429) ** Obsolete normative reference: RFC 2304 (ref. 'RFC3192') (Obsoleted by RFC 3192) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 4550 (Obsoleted by RFC 5550) -- Obsolete informational reference (is this intentional?): RFC 821 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 11 errors (**), 0 flaws (~~), 2 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 February 24, 2008 5 Expires: August 27, 2008 7 Internet Mail Architecture 8 draft-crocker-email-arch-10 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 27, 2008. 35 Abstract 37 Over its thirty-five year history Internet Mail has undergone 38 significant changes in scale and complexity, as it has become a 39 global infrastructure service. The first standardized architecture 40 for networked email specified little more than a simple split between 41 the user world and the transmission world. Core aspects of the 42 service, such as the styles of mailbox address and basic message 43 format, have remained remarkably constant. However today's Internet 44 Mail is distinguished by many independent operators, many different 45 components for providing service to users and many others for 46 performing message transfer. Public discussion of the service often 47 lacks common terminology and a common frame of reference for these 48 components and their activities. Having a common reference model and 49 terminology facilitates discussion about problems with the service, 50 changes in policy, or enhancement to the service's functionality. 51 This document offers an enhanced Internet Mail architecture that 52 targets description of the existing service, in order to facilitate 53 clearer and more efficient technical, operations and policy 54 discussions about email. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Service Overview . . . . . . . . . . . . . . . . . . . . . 5 61 1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6 62 1.4. Changes to Previous Version . . . . . . . . . . . . . . . 6 63 2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 8 64 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 9 65 2.2. Mail Handling Service (MHS) Actors . . . . . . . . . . . . 12 66 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 15 67 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 3.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 19 70 3.3. Message Identifier . . . . . . . . . . . . . . . . . . . . 19 71 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 21 72 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 25 73 4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 30 74 4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 32 75 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 35 76 5.1. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 36 77 5.2. Re-Sending . . . . . . . . . . . . . . . . . . . . . . . . 37 78 5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 39 79 5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 40 80 5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 41 81 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 42 82 6.1. Security Considerations . . . . . . . . . . . . . . . . . 42 83 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 42 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 85 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 42 86 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 44 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 45 88 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 90 Intellectual Property and Copyright Statements . . . . . . . . . . 48 92 1. Introduction 94 Over its thirty-five year history Internet Mail has undergone 95 significant changes in scale and complexity, as it has become a 96 global infrastructure service. The changes have been evolutionary, 97 rather than revolutionary, reflecting a strong desire to preserve its 98 installed base of users and utility. Today, Internet Mail is 99 distinguished by many independent operators, many different 100 components for providing service to users and many other components 101 for performing message transfer. 103 Public collaboration on email technical, operations and policy 104 activities, including those responding to the challenges of email 105 abuse, has brought in a much wider range of participants than email's 106 technical community originally had. In order to do work on a large, 107 complex system, they need to share the same view of how it is put 108 together, as well as what terms to use to refer to the pieces and 109 their activities. Otherwise, it is difficult to know exactly what 110 another participant means. It is these differences in each person's 111 perspective that motivates this document, to describe the realities 112 of the current system. Internet mail is the subject of ongoing 113 technical, operations and policy work, and the discussions often are 114 hindered by different models of email service design and different 115 meanings for the same terms. This architecture document seeks to 116 facilitate clearer and more efficient technical, operations and 117 policy exchanges about email. 119 This document offers an enhanced Internet Mail architecture to 120 reflect the current service. In particular it: 122 * Documents refinements to the email model 124 * Clarifies functional roles for the architectural components 126 * Clarifies identity-related issues, across the email service 128 * Defines terminology for architectural components and their 129 interactions 131 1.1. Background 133 The first standardized architecture for networked email specified a 134 simple split between the user world, in the form of Mail User Agents 135 (MUA), and the transmission world, in the form of the Mail Handling 136 Service (MHS) composed of Mail Transfer Agents (MTA). The MHS is 137 responsible for accepting a message from one User and delivering it 138 to one or more others, creating a virtual MUA-to-MUA exchange 139 environment. 141 As shown in Figure 1 this defines two logical "layers" of 142 interoperability. One is directly between Users. The other is 143 between the neighboring components, along the transfer path. In 144 addition, there is interoperability between the layers, first when a 145 message is posted from the User to the MHS and later when it is 146 delivered from the MHS to the User. 148 The operational service has evolved sub-divisions for each of these 149 layers into more specialized modules. Core aspects of the service, 150 such as mailbox addressing and message format style, have remained 151 remarkably constant. So the original distinction between user-level 152 concerns and transfer-level concerns is retained, but with an 153 elaboration to each level of the architecture. The term "Internet 154 Mail" is used to refer to the entire collection of user and transfer 155 components and services. 157 For Internet Mail the term "end-to-end" usually refers to a single 158 posting and the set of deliveries directly resulting from its single 159 transiting of the MHS. A common exception is with group dialogue 160 that is mediated via a mailing list, so that two postings occur 161 before intended recipients receive an Author's message, as discussed 162 in Section 2.1.4. In fact some uses of email consider the entire 163 email service -- including Author and Recipient -- as a subordinate 164 component. For these services "end-to-end" refers to points outside 165 of the email service. Examples are voicemail over email [RFC3801], 166 EDI over email [RFC1767] and facsimile over email [RFC4142]. 168 +--------+ 169 +---------------->| User | 170 | +--------+ 171 | ^ 172 +--------+ | +--------+ . 173 | User +--+--------->| User | . 174 +--------+ | +--------+ . 175 . | ^ . 176 . | +--------+ . . 177 . +-->| User | . . 178 . +--------+ . . 179 . ^ . . 180 . . . . 181 V . . . 182 +---+----------------+------+------+---+ 183 | . . . . | 184 | +...............>+ . . | 185 | . . . | 186 | +......................>+ . | 187 | . . | 188 | +.............................>+ | 189 | | 190 | Mail Handling Service (MHS) | 191 +--------------------------------------+ 193 Figure 1: Basic Internet Mail Service Model 195 1.2. Service Overview 197 End-to-end Internet Mail exchange is accomplished by using a 198 standardized infrastructure comprising: 200 * An email object 202 * Global addressing 204 * An asynchronous sequence of point-to-point transfer mechanisms 206 * No prior arrangement between Author and Recipient 208 * No prior arrangement between point-to-point transfer services, 209 over the open Internet 211 * No requirement for Author and Recipient to be online at the 212 same time. 214 The end-to-end portion of the service is the email object, called a 215 message. Broadly the message, itself, distinguishes between control 216 information for handling, versus the author's message content. 218 A precept to the design of mail over the open Internet is permitting 219 user-to-user and MTA-to-MTA interoperability to take place with no 220 prior, direct arrangement between the independent administrative 221 authorities responsible for handling a message. That is, all 222 participants rely on the core services being universally supported 223 and accessible, either directly or through gateways that translate 224 between Internet Mail and email environments that conform to other 225 standards. Given the importance of spontaneity and serendipity in 226 the world of human communications, this lack of prearrangement 227 between participants is a core benefit of Internet Mail and remains a 228 core requirement for it. 230 Within localized networks at the edge of the public Internet, prior 231 administrative arrangement often is required and can include access 232 control, routing constraints and information query service 233 configuration. In recent years one change to local environments is 234 an increased requirement for authentication or, at least, 235 accountability. In these cases a server performs explicit validation 236 of the client's identity. 238 1.3. Document Conventions 240 In this document, references to structured fields of a message use a 241 two-part dotted notation. The first part cites the document that 242 contains the specification for the field and the second is the name 243 of the field. Hence is the From: field in an email 244 content header and is the address in the SMTP 245 "Mail From" command. 247 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 248 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 249 document are to be interpreted as described in RFC 2119 [RFC2119]. 251 Discussion venue: Please direct discussion about this document 252 to the IETF-SMTP mailing list . 254 1.4. Changes to Previous Version 255 INSTRUCTIONS TO THE RFC EDITOR: Remove this sub-section prior to 256 publication. 258 Many small editing changes, for wordsmithing improvements to make 259 details more consistent. This section documents the nature and basis 260 for changes with significant impact. 262 Originator->Author: The term "Originator" is used by RFC 2822 more 263 broadly than just the From: field, which specifically defines who 264 the author of the content is. I believe this distinguishes two 265 constructs, one for the content author and one for the first 266 agency that handles the message, in terms of the transfer service. 267 So the change from "Originator" to "Author" seems pretty 268 straightforward. The challenge is in using the term Originator, 269 as defined in RFC 2822 and applying it to the system's 270 architecture. 272 Source->Originator: This change is more of a challenge. We need 273 the "Originator" term and construct, but the architecture is 274 already complex enough. Hence, adding a new construct seems like 275 a very poor resolution. The document has used "Source" as an MHS 276 term for the MSA set of functions. While one could argue against 277 re-labeling it as Originator, I believe this is a reasonable 278 choice and likely to be comfortable for community use, since 279 "Source" does not have an established history. 281 Bounce->Return: 'bounce address' is not accurate, because the 282 address is used for more than that, but it *is* as established 283 term within portions of the broader email community. I also 284 believe the extensive discussion on this point, last year, 285 justifies the change. 287 The problem with saying "Bounce" is that is not merely 288 linguistically impure, it is plain wrong and has already caused 289 serious problems. Witness SPF. Frankly, we need to fix RFC2821, 290 but that's a separate battle to fight and not one for this forum. 292 Although not a verbatim use of "Reverse Path", the related term 293 that seems to work publicly is "Return Address". It is already 294 established in the bricks-and-mortar postal world and seems to 295 have some acceptance within parts of the email community. (I've 296 done a draft white paper on authentication for the Messaging Anti- 297 Abuse Working Group and the membership had some debate about this 298 vocabulary choice and converged on agreeing to it.) 300 Is the envelope part of the message? I don't remember whether we 301 resolved this. For a variety of reasons, I believe the message 302 includes its envelope, and am encouraged to find RFC2822upd says: 304 In the context of electronic mail, messages are viewed as 305 having an envelope and contents. The envelope contains 306 whatever information is needed to accomplish transmission and 307 delivery. (See [I-D.klensin-rfc2821bis] (Klensin, J., "Simple 308 Mail Transfer Protocol," November 2007.) for a discussion of 309 the envelope.) The contents comprise the object to be 310 delivered to the recipient. This specification applies only to 311 the format and some of the semantics of message contents. 313 rfc2821bis says: 315 SMTP transports a mail object. A mail object contains an 316 envelope and content. 318 I think these justify having the term 'message' as including the 319 object. 321 Examples of 'new' messages: Section Section 3.3.1contains a list of 322 examples, discussing scenarios that might or might not be viewed 323 as creating a "new" message, rather than retaining an existing 324 one. The list has been expanded. 326 2. Responsible Actor Roles 328 Internet Mail is a highly distributed service, with a variety of 329 actors serving different roles. These divide into 3 basic types: 331 * User 333 * Mail Handling Service (MHS) 335 * ADministrative Management Domain (ADMD) 337 Although related to a technical architecture, the focus on Actors 338 concerns participant responsibilities, rather than on functionality 339 of modules. Hence the labels used are different than for classic 340 email architecture diagrams. 342 2.1. User Actors 344 Users are the sources and sinks of messages. They can be humans, 345 organizations or processes. They can have an exchange that iterates 346 and they can expand or contract the set of users participating in a 347 set of exchanges. In Internet Mail there are three types of user- 348 level Actors: 350 * Authors 352 * Recipients 354 * Mediators 356 From the User-level perspective all mail transfer activities are 357 performed by a monolithic Mail Handling Service (MHS), even though 358 the actual service can be provided by many independent organizations. 359 Users are customers of this unified service. 361 The following figure depicts the flow of messages among Actors: 363 +------------+ 364 | |<---------------------------+ 365 | Author |<----------------+ | 366 | |<----+ | | 367 +-+---+----+-+ | | | 368 | | | | | | 369 | | V | | | 370 | | +---------+-+ | | 371 | | | Recipient | | | 372 | | +-----------+ | | 373 | | | | 374 | | +--------+ | | 375 | | | | | | 376 | V V | | | 377 | +-----------+ +-+-------+-+ | 378 | | Mediator +--->| Recipient | | 379 | +-----------+ +-----------+ | 380 | | 381 | +-----------------------------+ | 382 | | +----------+ | | 383 | | | | | | 384 V V V | | | 385 +-----------+ +-----------+ +---+-+-+---+ 386 | Mediator +--->| Mediator +--->| Recipient | 387 +-----------+ +-----------+ +-----------+ 389 Figure 2: Relationships Among User Actors 391 2.1.1. Author 393 This is the user-level participant responsible for creating the 394 message, its contents and its list of recipient addresses. The MHS 395 operates to send and deliver mail among Authors and Recipients. As 396 described below, the MHS has a "Source" role that correlates with the 397 user-level Author role. 399 2.1.2. Recipient 401 The Recipient is a consumer of delivered message content. As 402 described below, the MHS has a "Dest[ination]" role that correlates 403 with the user-level Recipient role. 405 A Recipient can close the user-level communication loop by creating 406 and submitting a new message that replies to an Author. An example 407 of an automated form of reply is the Message Disposition Notification 408 (MDN), which informs the Author about the Recipient's handling of the 409 message. (See Section 4.1.) 411 2.1.3. Return Handler 413 The Return Handler -- also called "Bounce Handler" -- receives and 414 services notifications generated by the MHS, as a result of efforts 415 to transfer or deliver the message. Notices can be about failures or 416 completions and are sent to an address that is specified by the 417 Source. This Return handling address (also known as a Return 418 address) might have no visible characteristics in common with the 419 address of the Author or Source. 421 2.1.4. Mediator 423 A Mediator receives, aggregates, reformulates and redistributes 424 messages as part of a potentially-protracted, higher-level exchange 425 among Users. It is easy to confuse this user-level activity with the 426 underlying MHS transfer exchanges. However they serve very different 427 purposes and operate in very different ways. Mediators are 428 considered extensively in Section 5. 430 When mail is delivered to a receiving mediator specified in the 431 RFC2821.RcptTo command, the MHS handles it the same way as for any 432 other Recipient. That is, the MHS only sees posting and delivery 433 sources and sinks and does not see (later) re-posting as a 434 continuation of a process. Hence when submitting messages, the 435 Mediator is an Author. 437 The distinctive aspects of a Mediator are, therefore, above the MHS. 438 A Mediator preserves the Author information of the message it 439 reformulates, but may make meaningful changes to the content. Hence 440 the MHS sees a new message, but Users receive a message that is 441 interpreted as primarily being from -- or, at least, initiated by -- 442 the author of the original message. The role of a Mediator permits 443 distinct, active creativity, rather than being limited to the more 444 constrained job of merely connecting together other participants. 445 Hence it is really the Mediator that is responsible for the new 446 message. 448 A Mediator's task can be complex and contingent, such as modifying 449 and adding content or regulating which users are allowed to 450 participate and when. The popular example of this role is a group 451 mailing list. A sequence of Mediators may even perform a series of 452 formal steps, such as reviewing, modifying and approving a purchase 453 request. 455 Because a Mediator originates messages, it can also receive replies. 456 So a Mediator really is a full-fledged User. 458 Gateway: A Gateway is a particularly interesting form of Mediator. 459 It is a hybrid of User and Relay that interconnects heterogeneous 460 mail services. Its goal is to emulate a Relay, and a detailed 461 discussion is in Section 2.2.3. 463 2.2. Mail Handling Service (MHS) Actors 465 The Mail Handling Service (MHS) has the task of performing a single, 466 end-to-end transfer on behalf of the Author and reaching the 467 Recipient address(es) specified in the original RFC2821.RcptTo 468 commands. Mediated or protracted, iterative exchanges, such as those 469 used for collaboration over time, are part of the User-level service, 470 and are not part of this transfer-level Handling Service. 472 The following figure depicts the relationships among transfer 473 participants in Internet Mail. It shows the Source as distinct from 474 the Author, and Dest[ination] as distinct from Recipient, although it 475 is common for each pair to be the same actor. Transfers typically 476 entail one or more Relays. However direct delivery from the Source 477 to Destination is possible. For intra-organization mail services, it 478 is common to have only one Relay. 480 +------------+ +-----------+ 481 | Author | +--------+ | Recipient | 482 +-----+------+ +....>| Return | +-----------+ 483 | . +--------+ ^ 484 | . ^ | 485 //===================================================\\ 486 || | . | Mail Handling | || 487 || | . | Service (MHS) | || 488 V . | | 489 +---------+ . ^ +----+---+ 490 | | . | | | 491 | Origin +....+ +-<------------+ Dest | 492 | | | | | 493 +----+----+ | +--------+ 494 | | ^ 495 | +-------------->-+-<-------------+ | 496 V | | | | 497 +-------+-+ +----+----+ +-+---+---+ 498 | Relay +-->...-->| Relay +------->| Relay | 499 +---------+ +----+----+ +---------+ 500 | 501 V 502 +---------+ 503 | Gateway +-->... 504 +---------+ 506 Figure 3: Relationships Among MHS Actors 508 2.2.1. Originator 510 The Originator role is responsible for ensuring that a message is 511 valid for posting and then submitting it to a Relay. Validity 512 includes conformance with Internet Mail standards, as well as with 513 local operational policies. The Originator can simply review the 514 message for conformance and reject it if there are errors, or it can 515 create some or all of the necessary information. 517 The Originator operates with dual "allegiance". It serves the Author 518 and often it is the same entity. However its role in assuring 519 validity means that it MUST also represent the local operator of the 520 MHS, that is, the local ADministrative Management Domain (ADMD). 522 The Originator also has the responsibility for any post-submission, 523 Author-related administrative tasks associated with message 524 transmission and delivery. Notably this pertains to error and 525 delivery notices. Hence Source is best held accountable for the 526 message content, even when they did not create any or most of it. 528 2.2.2. Relay 530 A mail Relay performs email transfer-service routing and store-and- 531 forward by (re-)transmitting the message on towards its Recipient(s). 532 A Relay can add trace information. However it does not modify 533 existing envelope information or the message content semantics. It 534 can modify message content syntax, such as a change from binary to 535 text transfer-encoding form, only as required to meet the 536 capabilities of the next hop in the MHS. 538 A set of Relays composes a Mail Handling Service (MHS) network. This 539 is above any underlying packet-switching network that they might be 540 using and below any gateways or other user-level Mediators. 542 In other words, interesting email scenarios can involve three 543 distinct architectural layers of store-and-forward service: 545 * User Mediators 547 * MHS Relays 549 * Packet Switches 551 with the bottom-most usually being the Internet's IP service. The 552 most basic email scenarios involve Relays and Switches. 554 Aborting a message transfer results in having the Relay become an 555 Author and sending an error message to the Return address. The 556 potential for looping is avoided by having this message, itself, 557 contain no Return address. 559 2.2.3. Gateway 561 A Gateway is a hybrid form of User and Relay that interconnects 562 heterogeneous mail services. Its purpose is simply to emulate a 563 Relay and the closer it comes to this, the better. However it 564 operates at the User level, because it MUST be able to modify message 565 content. 567 Differences between mail services can be as small as minor syntax 568 variations, but usually encompass significant, semantic distinctions. 569 One difference could have the concept of an email address being a 570 hierarchical, machine-specific address, versus having it be a flat, 571 global name space. Another difference could be between text-only 572 content, versus multi-media. Hence the Relay function in a Gateway 573 offers significant design challenges, to make the result be as 574 seamless as possible. The most significant challenge is in ensuring 575 the user-to-user functionality that matches syntax and semantics of 576 independent email standards suites. 578 The basic test of a Gateway's adequacy is, of course, whether an 579 Author on one side of a Gateway can send a useful message to a 580 Recipient on the other side, without requiring changes to any of the 581 components in the Author's or Recipient's mail services, other than 582 adding the Gateway. To each of these otherwise independent services, 583 the Gateway will appear to be a "native" participant. However the 584 ultimate test of a Gateway's adequacy is whether the Author and 585 Recipient can sustain a dialogue. In particular can a Recipient's 586 MUA automatically formulate a valid Reply that will reach the initial 587 Author? 589 2.3. Administrative Actors 591 Actors often are associated with different organizations, each with 592 its own administrative authority. This operational independence, 593 coupled with the need for interaction between groups, provides the 594 motivation for distinguishing among ADministrative Management Domains 595 (ADMD). Each ADMD can have vastly different operating policies and 596 trust-based decision-making. An obvious example is the distinction 597 between mail that is exchanged within a single organization, versus 598 mail that is exchanged between independent organizations. The rules 599 for handling these two types of traffic tend to be quite different. 600 That difference requires defining the boundaries of each, and this 601 requires the ADMD construct. 603 Operation of Internet Mail services is apportioned to different 604 providers (or operators). Each can be an independent ADMD. This 605 independence of administrative decision-making defines boundaries 606 that distinguish different portions of the Internet Mail service. 607 Examples include an end-user operating their desktop client, a 608 department operating a local Relay, an IT department operating an 609 enterprise Relay and an ISP operating a public shared email service. 610 These can be configured into many combinations of administrative and 611 operational relationships, with each ADMD potentially having a 612 complex arrangement of functional components. Figure 4 depicts 613 relationships among ADMDs. The benefit of having the ADMD construct 614 is to facilitate discussion about designs and operations that need to 615 distinguish between "internal" issues and "external" ones. 617 The architectural impact of needing to have boundaries between ADMD's 618 is discussed in [Tussle]. Most significant is that the entities 619 communicating across ADMD boundaries will typically have an added 620 burden to enforce organizational policies concerning "external" 621 communications. At a more mundane level, routing mail between ADMDs 622 can be an issue, such as needing to route mail for partners over 623 specially-trusted paths. 625 Basic types of ADMDs include -- 627 Edge: Independent transfer services, in networks at the edge of 628 the open Internet Mail service. 630 User: End-user services. This might be subsumed under the Edge 631 service, such as is common for web-based email access. 633 Transit: These are Mail Service Providers (MSP) offering value- 634 added capabilities for Edge ADMDs, such as aggregation and 635 filtering. 637 Note that Transit services are quite different from packet-level 638 switching operation. Whereas end-to-end packet transfers usually go 639 through intermediate routers, email exchange across the open Internet 640 is often directly between the Boundary MTAs of Edge ADMDs, at the 641 email level. This further highlights the differences discussed in 642 Section 2.2.2 644 +-------+ +-------+ +-------+ 645 | ADMD1 | | ADMD3 | | ADMD4 | 646 | ----- | | ----- | | ----- | 647 | | +---------------------->| | | | 648 | User | | |-Edge--+--->|-User | 649 | | | | +---------+ +--->| | | | 650 | V | | | ADMD2 | | +-------+ +-------+ 651 | Edge--+---+ | ----- | | 652 | | | | | | 653 +-------+ +----|-Transit-+---+ 654 | | 655 +---------+ 657 Figure 4: ADMD Example 659 Edge networks can use proprietary email standards internally. 660 However the distinction between Transit network and Edge network 661 transfer services is primarily significant because it highlights the 662 need for concern over interaction and protection between independent 663 administrations. In particular this distinction calls for additional 664 care in assessing transitions of responsibility, as well as the 665 accountability and authorization relationships among participants in 666 email transfer. 668 The interactions between functional components within an ADMD are 669 subject to the policies of that domain. Policies can cover such 670 things as: 672 o Reliability 674 o Access control 676 o Accountability 678 o Content evaluation and modification 680 They can be implemented in different functional components, according 681 to the needs of the ADMD. For example see [RFC5068]. 683 User, Edge and Transit services can be offered by providers that 684 operate component services or sets of services. Further it is 685 possible for one ADMD to host services for other ADMDs. 687 Common ADMD examples are -- 689 Enterprise Service Providers: 691 Operating an organization's internal data and/or mail services. 693 Internet Service Providers: 695 Operating underlying data communication services that, in turn, 696 are used by one or more Relays and Users. It is not 697 necessarily their job to perform email functions, but they can, 698 instead, provide an environment in which those functions can be 699 performed. 701 Mail Service Providers: 703 Operating email services, such as for end-users, or mailing 704 lists. 706 Operational pragmatics often dictate that providers be involved in 707 detailed administration and enforcement issues, to help ensure the 708 health of the overall Internet Mail Service. This can include 709 operators of lower-level packet services. 711 3. Identities 713 Internet Mail uses three forms of identity: mailbox, domain name and 714 message-id. Each is required to be globally unique. 716 3.1. Mailbox 718 "A mailbox sends and receives mail. It is a conceptual entity 719 which does not necessarily pertain to file storage." [RFC2822] 721 A mailbox is specified as an Internet Mail address . It 722 has two distinct parts, divided by an at-sign ("@"). The right-hand 723 side is a globally interpreted domain name that is associated with an 724 ADMD. Domain Names are discussed in Section 3.2. Formal Internet 725 Mail addressing syntax can support source routes, to indicate the 726 path through which a message should be sent. Although legal, the use 727 of source routes is not part of the modern Internet Mail service and 728 it is not discussed further. 730 The portion to the left of the at-sign contains a string that is 731 globally opaque and is called the . It is to be 732 interpreted only by the entity specified by the address's right-hand 733 side domain name. All other entities MUST treat the local-part as a 734 uninterpreted literal string and MUST preserve all of its original 735 details. As such its public distribution is equivalent to sending a 736 Web browser "cookie" that is only interpreted upon being returned to 737 its Author. 739 3.1.1. Global Standards for Local-Part 741 It is common for sites to have local structuring conventions for the 742 left-hand side of an . This permits sub- 743 addressing, such as for distinguishing different discussion groups 744 used by the same participant. However it is worth stressing that 745 these conventions are strictly private to the user's organization and 746 SHOULD NOT be interpreted by any domain except the one listed in the 747 right-hand side of the addr-spec. The exceptions are those 748 specialized services conforming to standardized conventions, as noted 749 below. 751 There are a few types of addresses that have an elaboration on basic 752 email addressing, with a standardized, global schema for the local- 753 part. These are conventions between authoring systems and Recipient 754 Gateways, and they are invisible to the public email transfer 755 infrastructure. When an Author is explicitly sending via a Gateway 756 out of the Internet, there are coding conventions for the local-part, 757 so that the Author can formulate instructions for the Gateway. 758 Standardized examples of this are the telephone numbering formats for 759 VPIM [RFC3801], such as "+16137637582@vpim.example.com", and iFax 760 [RFC3192], such as "FAX=+12027653000/T33S=1387@ifax.example.com". 762 3.1.2. Scope of Email Address Use 764 Email addresses are being used far beyond their original email 765 transfer and delivery role. In practical terms, an email address 766 string has become the common identifier for representing online 767 identity. What is essential, then, is to be clear about the nature 768 and role of an identity string in a particular context and to be 769 clear about the entity responsible for setting that string. For 770 example, see: Section 4.1.4, Section 4.3.3, Section 5. 772 3.2. Domain Names 774 A domain name is a global reference to an Internet resource, such as 775 a host, a service or a network. A domain name usually maps to one or 776 more IP Addresses. Conceptually the name might encompass an entire 777 organization, a collection of machines integrated into a homogeneous 778 service, or only a single machine. A domain name can be administered 779 to refer to individual users, but this is not common practice. The 780 name is structured as a hierarchical sequence of sub-names, separated 781 by dots ("."), with the top of the hierarchy being on the right-end 782 of the sequence. Domain names are defined and operated through the 783 Domain Name System (DNS) [RFC1034], [RFC1035], [RFC2181]. 785 When not part of a mailbox address, a domain name is used in Internet 786 Mail to refer to the ADMD or the host that took action upon the 787 message, such as providing the administrative scope for a message 788 identifier, or performing transfer processing. 790 3.3. Message Identifier 792 There are two standardized tags for identifying messages: Message-ID 793 and ENVID. 795 3.3.1. Message-ID 797 The Message-ID is a user-level tag, primarily used for threading and 798 for eliminating duplicates [RFC2822]. Any actor within the 799 Originating ADMD can assign the Message-ID. The recipient's ADMD is 800 the intended consumer of the Message-ID, although any actor along the 801 transfer path might use it. Internet Mail standards provide for a 802 single Message-ID; however more than one is sometimes assigned. 804 Like a mailbox address, a Message-ID has two distinct parts, divided 805 by an at-sign ("@"). The right-hand side is globally interpreted and 806 specifies the ADMD or host assigning the identifier. The left-hand 807 side contains a string that is globally opaque and serves to uniquely 808 identify the message within the domain referenced on the right-hand 809 side. The duration of uniqueness for the message identifier is 810 undefined. 812 When a message is revised in any way, the question of whether to 813 assign a new Message-ID requires a subjective assessment, deciding 814 whether the editorial content has been changed enough to constitute a 815 new message. [RFC2822] says "a message identifier pertains to 816 exactly one instantiation of a particular message; subsequent 817 revisions to the message each receive new message identifiers." 818 However real-world experience dictates some flexibility. An 819 impossible test is whether the recipient will consider the new 820 message to be equivalent to the old. For most components of Internet 821 Mail, there is no way to predict a specific recipient's preferences 822 on this matter. Both creating and failing to create a new Message-ID 823 have their downsides. 825 The best that can be offered, here, are some guidelines and examples: 827 * If a message is changed only in terms of form, such as 828 character-encoding, it clearly is still the same message. 830 * If a message has minor additions to the content, such as a 831 mailing list tag at the beginning of the RFC2822.Subject header 832 field, or some mailing list administrative information added to 833 the end of the primary body-part's text, then it probably is 834 still the same message. 836 * If a message has viruses deleted from it, it probably is still 837 the same message. 839 * If a message has offensive words deleted from it, then some 840 recipients will consider it the same message, but some will 841 not. 843 * If a message is translated into a different language, then some 844 recipients will consider it the same message, but some will 845 not. 847 * If a message is included in a digest of messages, it the digest 848 constitutes a new message. 850 * If a message is forwarded by a recipient, what is forwarded is 851 considered to be a new message. 853 * If a message is "redirected", such as using RFC2822 854 "Redirect-*" headers, some recipients will consider it the same 855 message, but some will not. 857 The absence of objective, precise criteria for Message-ID re- 858 generation, along with the absence of strong protection associated 859 with the string, means that the presence of an ID can permit an 860 assessment that is marginally better than a heuristic, but the ID 861 certainly has no value on its own for strict formal reference or 862 comparison. Hence Message-ID SHOULD NOT be used for any function 863 that has security implications. 865 3.3.2. ENVID 867 The ENVID (envelope identifier) is a tag that is primarily for use 868 within Delivery Status Notifications (DSN), so that the Return 869 Address (RFC2821.MailFrom) recipient can correlate the DSN with a 870 particular message [RFC3461]. The ENVID is therefore used from one 871 message posting, until the directly-resulting message deliveries. It 872 does not survive re-postings. 874 The ENVID may also be used for message tracking purposes [RFC3885]. 876 The format of an ENVID is free-form. Although its creator might 877 choose to impose structure on the string, none is imposed by Internet 878 standards. By implication, the scope of the string is defined by the 879 domain name of the Return Address. 881 4. Services and Standards 883 Internet Mail's architecture distinguishes among six basic types of 884 functionality, arranged to support a store-and-forward service 885 architecture. As shown in Figure 5 these types can have multiple 886 instances, some of which represent specialized sub-roles. This 887 section considers the activities and relationships among these 888 components, and the Internet Mail standards that apply to them. 890 1. Message 892 2. Mail User Agent (MUA) 894 Originating MUA (oMUA) 896 Receiving MUA (rMUA) 898 3. Message Submission Agent (MSA) 900 Author-focussed MSA functions (oMSA) 902 MHS-focussed MSA functions (hMSA) 904 4. Message Transfer Agent (MTA) 906 5. Message Delivery Agent (MDA) 908 Recipient-focused MDA functions (rMDA) 910 MHS-focussed MDA functions (hMDA) 912 6. Message Store (MS) 914 1. Author MS (oMS) 916 oMS on a remote server (soMS) 918 oMS co-located with the oMUA (uoMS) 920 2. Recipient MS (rms) 922 rMS on a remote server (srMS) 924 rMS co-located with the rMUA (urMS) 926 This section describes each functional component for Internet Mail, 927 and the standards-based protocols associated with their operation. 929 Software implementations of these architectural components often 930 compress them, such as having the same software do MSA, MTA and MDA 931 functions. However the requirements for each of these components of 932 the service are becoming more extensive. So their separation is 933 increasingly common. 935 NOTE: A discussion about any interesting system architecture is 936 often complicated by confusion between architecture versus 937 implementation. An architecture defines the conceptual 938 functions of a service, divided into discrete conceptual 939 modules. An implementation of that architecture can combine or 940 separate architectural components, as needed for a particular 941 operational environment. 943 A software system that primarily performs message relaying -- 944 and therefore is an MTA -- might also include MDA 945 functionality. That same MTA system might be able to interface 946 with non-Internet email services and therefore qualify as a 947 Gateway. 949 It is important not to confuse the engineering decisions made 950 to implement a product, with the architectural abstractions 951 used to define conceptual functions. 953 The following figure shows function modules and the standardized 954 protocols used between them. Additional protocols and configurations 955 are possible. Boxes defined by asterisks (*) represent functions 956 that often are distributed among two or more systems. 958 +------+ +-------+ 959 ............+ oMUA |..............................| Disp | 960 . +--+-+-+ +-------+ 961 . local,imap}| |{smtp,submission ^ 962 . | | +---------+ | 963 . ******* | | .......................| Returns | | 964 . * oMS *<-----+ | . +---------+ | 965 . ******* | . ***************** ^ | 966 . +------V-.---*------------+ * | | 967 . MSA | +-------+ * +------+ | * | | 968 . | | oMSA +--O-->| hMSA | | * | | 969 . | +-------+ * +--+---+ | * | | 970 . +------------*------+-----+ * | | 971 //==========\\ * V {smtp * | | 972 || MESSAGE || * +------+ * //===+===\\ | 973 ||----------|| MHS * | MTA | * || dsn || | 974 || Envelope || * +--+---+ * \\=======// | 975 || SMTP || * V {smtp * ^ ^ | 976 || Content || * +------+ * | | //==+==\\ 977 || RFC2822 || * | MTA +----*-----+ | || mdn || 978 || MIME || * +--+---+ * | \\=====// 979 \\==========// * smtp}| {local * | | 980 . MDA * | {lmtp * | | 981 . +------------+------V-----+ * | | 982 . | +------+ * +------+ | * | | 983 . | | | * | | +--*---------+ | 984 . | | rMDA |<--O---+ hMDA | | * | 985 . | | | * | | |<-*-------+ | 986 . | +-+----+ * +------+ | * | | 987 . +---+--+-----*------------+ * | | 988 . | | ***************** | | 989 . pop} +--+ +---+ | | 990 . imap} | | {local | | 991 . ******************V******** | | 992 . * | +------+ * rMS //===+===\\ | 993 . * | | srMS | * || sieve || | 994 . * V +--+-+-+ * \\=======// | 995 . * +------+ pop} | | * ^ | 996 . * | urMS |<-------+ | * | | 997 . * +--+---+ imap} | * | | 998 . *************************** | | 999 . local}| +------+ |{pop,imap | | 1000 . +->| |<------+ | | 1001 ...........>| rMUA +---------------------------+ | 1002 | +-----------------------------------+ 1003 +------+ 1005 Figure 5: Protocols and Services 1007 4.1. Message Data 1009 The purpose of the Mail Handling Service (MHS) is to exchange a 1010 message object among participants [RFC2822], [RFC0822]. Hence all of 1011 its underlying mechanisms are merely in the service of getting that 1012 message from its Author to its Recipients. A message can be 1013 explicitly labeled as to its nature [RFC3458]. 1015 A message comprises a transit handling envelope and the message 1016 content. The envelope contains information used by the MHS. The 1017 content is divided into a structured header and the body. The header 1018 comprises transit trace information and end-user structured fields. 1019 The body may be unstructured simple lines of text, or it may be a 1020 MIME tree of multi-media subordinate objects, called body-parts, or 1021 attachments [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], 1022 [RFC2049]. 1024 In addition, Internet Mail has a few conventions for special control 1025 data -- 1027 Delivery Status Notification (DSN): 1029 A Delivery Status Notification (DSN) is a message that can be 1030 generated by the MHS (MSA, MTA or MDA) and sent to the 1031 RFC2821.MailFrom address. The mailbox for this is shown as 1032 Returns in Figure 5. DSNs provide information about message 1033 transit, such as transmission errors or successful delivery 1034 [RFC3461]. 1036 Message Disposition Notification (MDN): 1038 A Message Disposition Notification (MDN) is a message that 1039 provides information about user-level, Recipient-side message 1040 processing, such as indicating that the message has been 1041 displayed [RFC3798] or the form of content that can be 1042 supported [RFC3297]. It can be generated by an rMUA and is 1043 sent to the Disposition-Notification-To address(es). The 1044 mailbox for this is shown as Disp in Figure 5. 1046 Message Filtering (SIEVE): 1048 SIEVE is a scripting language that permits specifying 1049 conditions for differential handling of mail, typically at the 1050 time of delivery [RFC3028]. It can be conveyed in a variety of 1051 ways, as a MIME part. Figure 5 shows a Sieve specification 1052 going from the rMUA to the MDA. However filtering can be done 1053 at many different points along the transit path and any one or 1054 more of them might be subject to Sieve directives, especially 1055 within a single ADMD. Hence the Figure shows only one 1056 relationship, for (relative) simplicity. 1058 4.1.1. Envelope 1060 Internet Mail has a fragmented framework for transit-related 1061 "handling" information. Information that is directly used by the MHS 1062 is called the "envelope". It directs handling activities by the 1063 transfer service as is carried in transfer service commands. That 1064 is, the envelope exists in the transfer protocol SMTP [RFC2821]. 1066 Trace information records handling activity and is recorded in the 1067 message Header. [RFC2822] 1069 4.1.2. Header Fields 1071 Header fields are attribute name/value pairs covering an extensible 1072 range of email service, user content and user transaction meta- 1073 information. The core set of header fields is defined in [RFC2822], 1074 [RFC0822]. It is common to extend this set, for different 1075 applications. Procedures for registering header fields are defined 1076 in [RFC4021]. An extensive set of existing header field 1077 registrations is provided in [RFC3864]. 1079 One danger with placing additional information in header fields is 1080 that Gateways often alter or delete them. 1082 4.1.3. Body 1084 The body of a message might simply be lines of ASCII text or it might 1085 be hierarchically structured into a composition of multi-media body- 1086 part attachments, using MIME [RFC2045], [RFC2046], [RFC2047], 1087 [RFC4288], [RFC2049]. MIME structures each body-part into a 1088 recursive set of MIME header field meta-data and MIME Content 1089 sections. 1091 4.1.4. Identity References in a Message 1093 For a message in transit, the core uses of identifiers combine into: 1095 +-----------------------+----------------+---------------------+ 1096 | Layer | Field | Set By | 1097 +-----------------------+----------------+---------------------+ 1098 | Message Body | MIME Header | Author | 1099 | Message header fields | From | Author | 1100 | | Sender | Source | 1101 | | Reply-To | Author | 1102 | | To, CC, BCC | Author | 1103 | | Message-ID | Source | 1104 | | Received | Source, Relay, Dest | 1105 | | Return-Path | MDA, from MailFrom | 1106 | | Resent-* | Mediator | 1107 | | List-Id | Mediator Author | 1108 | | List-* | Mediator Author | 1109 | SMTP | HELO/EHLO | Latest Relay Client | 1110 | | ENVID | Source | 1111 | | MailFrom | Source | 1112 | | RcptTo | Author | 1113 | IP | Source Address | Latest Relay Client | 1114 +-----------------------+----------------+---------------------+ 1116 Layered Identities 1118 The most common address-related fields are: 1120 RFC2822.From: Set by - Author 1122 Names and addresses for author(s) of the message content are 1123 listed in the From: field. 1125 RFC2822.Reply-To: Set by - Author 1127 If a message Recipient sends a reply message that would otherwise 1128 use the RFC2822.From field address(es) that are contained in the 1129 original message, then they are instead to use the address(es) in 1130 the RFC2822.Reply-To field. In other words this field is a direct 1131 override of the From: field, for responses from Recipients. 1133 RFC2822.Sender: Set by - Source 1135 This specifies the address responsible for submitting the message 1136 into the transfer service. For efficiency this field can be 1137 omitted if it contains the same address as RFC2822.From. However 1138 this does not mean there is no Sender specified. Rather it means 1139 that that header field is virtual and that the address in the 1140 From: field MUST be used. 1142 Specification of the notifications Return addresses -- contained 1143 in RFC2821.MailFrom -- is made by the RFC2822.Sender. Typically 1144 the Return address is the same as the Sender address. However 1145 some usage scenarios require it to be different. 1147 RFC2822.To/.CC: Set by - Author 1149 These specify MUA Recipient addresses. However some or all of the 1150 addresses in these fields might not be present in the 1151 RFC2821.RcptTo commands. 1153 The distinction between To and CC is subjective. Generally a To 1154 addressee is considered primary and is expected to take action on 1155 the message. A CC addressee typically receives a copy only for 1156 their information. 1158 RFC2822.BCC: Set by - Author 1160 A message might be copied to an addressee whose participation is 1161 not to be disclosed to the RFC2822.To or RFC2822.CC Recipients 1162 and, usually, not to the other BCC Recipients. The BCC header 1163 field indicates a message copy to such a Recipient. 1165 Typically, the field lists no addresses or only lists the single 1166 address of the Recipient receiving this copy. An MUA will 1167 typically make separate postings for TO and CC Recipients, versus 1168 BCC Recipients. The former will see no indication that any BCCs 1169 were sent, whereas the latter have a BCC field present. It might 1170 be empty, contain a comment, or contain one or more BCC addresses, 1171 depending upon the preferences of the Author. 1173 RFC2821.HELO/.EHLO: Set by - Source 1175 The MSA can specify its hosting domain identity for the SMTP HELO 1176 or EHLO command operation. 1178 RFC3461.ENVID: Set by - Source 1180 The MSA can specify an opaque string, to be included in a DSN, as 1181 a means of assisting the Return address recipient in identifying 1182 the message that produced a DSN, or message tracking. 1184 RFC2821.MailFrom: Set by - Source 1186 This is an end-to-end string that specifies an email address for 1187 receiving return control information, such as "bounces". The name 1188 of this field is misleading, because it is not required to specify 1189 either the author or the Actor responsible for submitting the 1190 message. Rather, the Actor responsible for submission specifies 1191 the RFC2821.MailFrom address. Ultimately the simple basis for 1192 deciding what address needs to be in the RFC2821.MailFrom is to 1193 determine what address needs to be informed about transmission- 1194 level problems (and, possibly, successes.) 1196 RFC2821.RcptTo: Set by - Author 1198 This specifies the MUA mailbox address of a recipient. The string 1199 might not be visible in the message content header. For example, 1200 the message destination address header fields, such as RFC2822.To, 1201 might specify a mailing list mailbox, while the RFC2821.RcptTo 1202 address specifies a member of that list. 1204 RFC2821.Received: Set by - Source, Relay, Mediator, Dest 1206 This indicates trace information, including originating host, 1207 relays, Mediators, and MSA host domain names and/or IP Addresses. 1209 RFC2821.Return-Path: Set by - Source 1211 The MDA records the RFC2821.MailFrom address into the 1212 RFC2822.Return-Path field. 1214 RFC2919.List-Id: Set by - Mediator Author 1216 This provides a globally unique mailing list naming framework that 1217 is independent of particular hosts. [RFC2919] 1219 The identifier is in the form of a domain name; however the string 1220 usually is constructed by combining the two parts of an email 1221 address and the result rarely is a true domain name, listed in the 1222 domain name service -- although it can be. 1224 RFC2369.List-*: Set by - Mediator Author 1226 [RFC2369] defines a collection of message header fields for use by 1227 mailing lists. In effect they supply list-specific parameters for 1228 common mailing list user operations. The identifiers for these 1229 operations are for the list, itself, and the user-as-subscriber 1230 [RFC2369]. 1232 RFC0791.SourceAddr: Set by - The Client SMTP sending host 1233 immediately preceding the current receiving SMTP server. 1235 [RFC0791] defines the basic unit of data transfer for the 1236 Internet, the IP Datagram. It contains a "Source Address" field 1237 that specifies the IP Address for the host (interface) from which 1238 the datagram was sent. This information is set and provided by 1239 the IP layer, and is therefore independent of mail-level 1240 mechanisms. As such, it is often taken to be authoritative, 1241 although it is possible to provide false addresses. 1243 4.2. User-Level Services 1245 Interactions at the user level entail protocol exchanges, distinct 1246 from those that occur at lower layers of the Internet Mail 1247 architecture, which is above the Internet Transport layer. Because 1248 the motivation for email, and much of its use, is for interaction 1249 among humans, the nature and details of these protocol exchanges 1250 often are determined by the needs of human and group communication. 1251 In terms of efforts to specify behaviors, one effect of this is to 1252 require subjective guidelines, rather than strict rules, for some 1253 aspects of system behavior. Mailing Lists provide particularly 1254 salient examples of this. 1256 4.2.1. Mail User Agent (MUA) 1258 A Mail User Agent (MUA) works on behalf of end-users and end-user 1259 applications. It is their "representative" within the email service. 1261 The Origination-side MUA (oMUA) creates a message and performs 1262 initial "submission" into the transfer infrastructure, via a Mail 1263 Submission Agent (MSA). It can also perform any creation- and 1264 posting-time archival in its Message Store (oMS). An MUA's oMS will 1265 typically include a folder for messages under development (Drafts), a 1266 folder for messages waiting to be sent (Queued or Unsent) and a 1267 folder for messages that have been successfully posted for 1268 transmission (Sent). 1270 The Recipient-side MUA (rMUA) works on behalf of the end-user 1271 Recipient to process received mail. This includes generating user- 1272 level return control messages, displaying and disposing of the 1273 received message, and closing or expanding the user communication 1274 loop, by initiating replies and forwarding new messages. 1276 NOTE: Although not shown in Figure 5, an MUA can, itself, have a 1277 distributed implementation, such as a "thin" user interface 1278 module on a limited end-user device, with the bulk of the MUA 1279 functionality operated remotely on a more capable server. An 1280 example of such an architecture might use IMAP [RFC3501] for 1281 most of the interactions between an MUA client and an MUA 1282 server. A standardized approach for such scenarios is defined 1283 by [RFC4550]. 1285 A Mediator is special class of MUA. It performs message re-posting, 1286 as discussed in Section 2.1. 1288 Identity fields relevant to a typical end-user MUA include: 1290 RFC2822.From 1292 RFC2822.Reply-To 1294 RFC2822.Sender 1296 RFC2822.To, RFC2822.CC 1298 RFC2822.BCC 1300 4.2.2. Message Store (MS) 1302 An MUA can employ a long-term Message Store (MS). Figure 5 depicts 1303 an Origination-side MS (oMS) and a Recipient-side MS (rMS). There is 1304 a rich set of choices for configuring a store, because any MS may 1305 comprise a distributed set of component stores. In Figure 5, the rMS 1306 demonstrates this by showing an rMS that is located on a remote 1307 server (srMS) and an rMS that is on the same machine as the MUA 1308 (urMS). The relationship between two message stores, themselves, can 1309 vary. 1311 As discussed in [RFC1733] the operational relationship among MSs can 1312 be -- 1314 Online: Only a remote MS is used, with messages being accessible 1315 only when the MUA is attached to the MS, and the MUA repeatedly 1316 fetches all or part of a message, from one session to the next. 1318 Offline: The MS is local to the user, and messages are 1319 completely moved from any remote store, rather than (also) 1320 being retained there. 1322 Disconnected: An rMS and a uMS are kept synchronized, for all or 1323 part of their contents, while there is a connection between 1324 them. While they are disconnected, mail can continue to arrive 1325 at the rMS and the user may continue to make changes to the 1326 uMS. Upon reconnection, the two stores are re-synchronized. 1328 4.3. MHS-Level Services 1330 4.3.1. Mail Submission Agent (MSA) 1332 A Mail Submission Agent (MSA) accepts the message submission from the 1333 oMUA and enforces the policies of the hosting ADMD and the 1334 requirements of Internet standards. An MSA represents an unusual 1335 functional dichotomy. A portion of its task is to represent MUA 1336 (uMSA) interests during message posting, to facilitate posting 1337 success, and another portion is to represent MHS (hMSA) interests. 1338 This is best modeled, as shown in Figure 5, with two sub-components, 1339 one for the oMUA (oMSA) and one for the MHS (hMSA) 1341 The hMSA's function is to take transit responsibility for a message 1342 that conforms to the relevant Internet standards and to local site 1343 policies. It rejects messages that are not in conformance. The 1344 oMSA's is to perform final message preparation for submission and to 1345 effect the transfer of responsibility to the MHS, via the hMSA. The 1346 amount of preparation will depend upon the local implementations. 1347 Examples of oMSA tasks could be to add header fields, such as Date: 1348 and Message-ID, to modify portions of the message from local 1349 notations to Internet standards, such as expanding an address to its 1350 formal RFC2822 representation. 1352 Historically, standards-based MUA/MSA interactions have used SMTP 1353 [RFC2821]. A recent alternative is SUBMISSION [RFC4409]. Although 1354 SUBMISSION derives from SMTP, it uses a separate TCP port and imposes 1355 distinct requirements, such as access authorization. 1357 Identities relevant to the MSA include: 1359 RFC2821.HELO/.EHLO 1360 RFC3461.ENVID 1362 RFC2821.MailFrom 1364 RFC2821.RcptTo 1366 RFC2821.Received 1368 4.3.2. Mail Transfer Agent (MTA) 1370 A Mail Transfer Agent (MTA) relays mail for one application-level 1371 "hop". It is like a packet-switch or IP router in that its job is to 1372 make routing assessments and to move the message closer to the 1373 Recipient(s). Relaying is performed by a sequence of MTAs, until the 1374 message reaches a destination MDA. Hence an MTA implements both 1375 client and server MTA functionality. It does not make changes to 1376 addresses in the envelope or reformulate the editorial content. 1377 Hence a change in data form, such as to the MIME Content-Transfer- 1378 Encoding, is within the purview of an MTA, whereas removal or 1379 replacement of body content is not. Also it can add trace 1380 information. Of course email objects are typically much larger than 1381 the payload of a packet or datagram, and the end-to-end latencies are 1382 typically much higher. 1384 Internet Mail primarily uses SMTP [RFC2821], [RFC0821] to effect 1385 point-to-point transfers between peer MTAs. Other transfer 1386 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1387 most network layer mechanisms, Internet Mail's SMTP supports a basic 1388 level of reliability, by virtue of providing for retransmission after 1389 a temporary transfer failure. Contrary to typical packet switches 1390 (and Instant Messaging services) Internet Mail MTAs typically store 1391 messages in a manner that allows recovery across service 1392 interruptions, such as host system shutdown. However the degree of 1393 such robustness and persistence by an MTA can be highly variable. 1395 The primary "routing" mechanism for Internet Mail is the DNS MX 1396 record [RFC1035], which specifies a host through which the queried 1397 domain can be reached. This presumes a public -- or at least a 1398 common -- backbone that permits any attached host to connect to any 1399 other. 1401 Identities relevant to the MTA include: 1403 RFC2821.HELO/.EHLO 1405 RFC3461.ENVID 1407 RFC2821.MailFrom 1409 RFC2821.RcptTo 1411 RFC2822.Received Set by - Relay Server 1413 4.3.3. Mail Delivery Agent (MDA) 1415 A Mail Delivery Agent (MDA) delivers email to the Recipient's 1416 mailbox. It can provide distinctive, address-based functionality, 1417 made possible by its detailed knowledge of the properties of the 1418 destination address. This knowledge might also be present elsewhere 1419 in the Recipient's ADMD, such as at an organizational border 1420 (Boundary) Relay. However it is required for the MDA, if only 1421 because the MDA must know where to deliver the message. 1423 As with an MSA, an MDA serves two roles, as depicted in Figure 5. 1424 Formal transfer of responsibility, called "delivery" is effected 1425 between the two components that embody these roles. The MHS portion 1426 (hMDA) primarily functions as a server SMTP engine. A common 1427 additional role is to re-direct the message to an alternative 1428 address, as specified by the recipient addressee's preferences. The 1429 job of the recipient portion of the MDA (rMDA) is to perform any 1430 delivery-actions are desired by the recipient. 1432 Using Internet protocols, delivery can be effected by a variety of 1433 standard protocols. When coupled with an internal local mechanism, 1434 SMTP [RFC2821] and LMTP [RFC2033] permit "push" delivery to the 1435 Recipient system, at the initiative of the upstream email service. 1436 POP [RFC1939] and IMAP [RFC3501] are used for "pull" delivery at the 1437 initiative of the Recipient system. POP and IMAP can also be used 1438 for repeated access to messages on a remote MS. 1440 Identities relevant to the MDA include: 1442 RFC2821.Return-Path: Set by - Author Source or Mediator Source 1444 The MDA records the RFC2821.MailFrom address into the 1445 RFC2822.Return-Path field. 1447 RFC2822.Received: Set by - MDA server 1449 An MDA can record a Received header field to indicate trace 1450 information, including source host and receiving host domain 1451 names and/or IP Addresses. 1453 5. Mediators 1455 Basic email transfer from an Author to the specified Recipients is 1456 accomplished by using an asynchronous, store-and-forward 1457 communication infrastructure, in a sequence of independent 1458 transmissions through some number of MTAs. A very different task is 1459 a User-level sequence of postings and deliveries, through Mediators. 1460 A Mediator forwards a message, through a re-posting process. The 1461 Mediator does share some functionality with basic MTA relaying, but 1462 it enjoys a degree of freedom with both addressing and content that 1463 is not available to MTAs. 1465 RFC2821.HELO/.EHLO: Set by - Mediator Source 1467 RFC3461.ENVID Set by - Author Source or Mediator Source 1469 RFC2821.MailFrom: Set by - Author Source or Mediator Source 1471 RFC2821.RcptTo: Set by - Mediator Author 1473 RFC2821.Received: Set by - Mediator Dest 1475 The salient aspect of a Mediator, that distinguishes it from any 1476 other MUA creating an entirely new message, is that a Mediator 1477 preserves the integrity and tone of the original message, including 1478 the essential aspects of its origination information. The Mediator 1479 might also add commentary. 1481 Examples of MUA message creation NOT performed by Mediators include 1482 -- 1484 New message that forwards an existing message: 1486 This action rather curiously provides a basic template for a 1487 class of Mediators. However for its typical occurrence it is 1488 not itself an example of a Mediator. The new message is viewed 1489 as being from the Actor doing the forwarding, rather than being 1490 from the original Author. 1492 A new message encapsulates the original message and is seen as 1493 strictly "from" the Mediator. The Mediator might add 1494 commentary and certainly has the opportunity to modify the 1495 original message content. The forwarded message is therefore 1496 independent of the original message exchange and creates a new 1497 message dialogue. However the final Recipient sees the 1498 contained message as from the original Author. 1500 Reply: 1502 When a Recipient formulates a response back to the original 1503 message's author, the new message is not typically viewed as 1504 being a "forwarding" of the original. Its focus is the new 1505 content, although it might contain all or part of the material 1506 in the original message. Therefore the earlier material is 1507 merely contextual and secondary. 1509 Annotation: 1511 The integrity of the original message is usually preserved, but 1512 one or more comments about the message are added in a manner 1513 that distinguishes commentary from original text. The tone of 1514 the new message is that it is primarily commentary from a new 1515 Author, similar to a Reply. 1517 The remainder of this section describes common examples of Mediators. 1519 5.1. Aliasing 1521 Aliasing is a simple re-addressing facility that is available in most 1522 MDA implementations. It is performed just before placing a message 1523 into the specified Recipient's mailbox. Instead the message is 1524 submitted back to the transfer service, for delivery to one or more 1525 alternate addresses. Although typically implemented as part of an 1526 MDA, this facility is strictly a Recipient user function. It 1527 resubmits the message, replacing the envelope address, on behalf of 1528 the mailbox address that was listed in the envelope. 1530 What is most distinctive about this forwarding mechanism is how 1531 closely it compares to normal MTA store-and-forward Relaying. Its 1532 only interesting difference is that it changes the RFC2821.RcptTo 1533 value. Having the change be this small makes it easy to view 1534 aliasing as a part of the lower-level mail relaying activity. 1535 However the small change has a large semantic impact: The designated 1536 recipient has chosen a new recipient. Hence that original recipient 1537 SHOULD become responsible for any handling issues. This change would 1538 be reflected by replacing the message's RFC2821.MailFrom address to 1539 be one within the scope of the ADMD doing the aliasing. 1541 An MDA that is re-posting a message to an alias typically changes 1542 only envelope information: 1544 RFC2822.To/.CC/.BCC: Set by - Author 1546 These retain their original addresses. 1548 RFC2821.RcptTo: Set by - Mediator Author 1550 This field contains an alias address. 1552 RFC2821.MailFrom: Set by - Author Source or Mediator Source 1554 The Actor responsible for submission to an alias address will 1555 often retain the original address to receive handling Returns. 1556 The benefit of retaining the original MailFrom value is to 1557 ensure that the origination-side Actor knows that there has 1558 been a delivery problem. On the other hand, the responsibility 1559 for the problem usually lies with the Recipient, since the 1560 Alias mechanism is strictly under the Recipient's control. 1562 RFC2821.Received Set by - Mediator Dest 1564 The Actor can record Received information, to indicate the 1565 delivery to the original address and submission to the alias 1566 address. The trace of Received header fields can therefore 1567 include everything from original posting through final delivery 1568 to a final delivery. 1570 5.2. Re-Sending 1572 Also called Re-Directing, Re-Sending differs from Forwarding by 1573 virtue of having the Mediator "splice" a message's addressing 1574 information, to connect the Author of the original message and the 1575 Recipient of the new message. This permits them to have direct 1576 exchange, using their normal MUA Reply functions. Hence the new 1577 Recipient sees the message as being From: the original Author, even 1578 if the Mediator adds commentary. 1580 Identities specified in a resent message include 1582 RFC2822.From: Set by - original Author 1584 Names and email addresses for the original author(s) of the 1585 message content are retained. The free-form (display-name) 1586 portion of the address might be modified to provide informal 1587 reference to the Actor responsible for the redirection. 1589 RFC2822.Reply-To: Set by - original Author 1591 If this field is present in the original message, it is 1592 retained in the Resent message. 1594 RFC2822.Sender: Set by - Author Source or Mediator Source. 1596 RFC2822.To/.CC/.BCC: Set by - original Author 1598 These specify the original message Recipients. 1600 RFC2822.Resent-From: Set by - Mediator Author 1602 The address of the original Recipient who is redirecting the 1603 message. Otherwise the same rules apply for the Resent-From: 1604 field as for an original RFC2822.From field. 1606 RFC2822.Resent-Sender: Set by - Mediator Source 1608 The address of the Actor responsible for re-submitting the 1609 message. As with RFC2822.Sender, this field is often omitted 1610 when it would merely contain the same address as 1611 RFC2822.Resent-From. 1613 RFC2822.Resent-To/-CC/-BCC: Set by: Mediator Author 1615 The addresses of the new Recipients who will now be able to 1616 reply to the original author. 1618 RFC2821.MailFrom: Set by - Mediator Source 1620 The Actor responsible for re-submission (RFC2822.Resent-Sender) 1621 is also responsible for specifying the new MailFrom address. 1623 RFC2821.RcptTo: Set by - Mediator Author 1625 This will contain the address of a new Recipient. 1627 RFC2822.Received: Set by - Mediator Dest 1629 When resending a message the submission agent can record a 1630 Received header field, to indicate the transition from original 1631 posting to resubmission. 1633 5.3. Mailing Lists 1635 Mailing lists have explicit email addresses and they re-post messages 1636 to a list of subscribed members. The Mailing List Actor performs a 1637 task that can be viewed as an elaboration of the Re-Director role. 1638 In addition to sending the new message to a potentially large number 1639 of new Recipients, the Mediator can modify content, such as deleting 1640 attachments, converting the format, and adding list-specific 1641 comments. In addition, archiving list messages is common. Still the 1642 message retains characteristics of being "from" the original Author. 1644 Identities relevant to a mailing list processor, when submitting a 1645 message, include: 1647 RFC2919.List-Id: Set by - Mediator Author 1649 RFC2369.List-*: Set by - Mediator Author 1651 RFC2822.From: Set by - original Author 1653 Names and email addresses for the original author(s) of the 1654 message content are specified -- or, rather, retained. 1656 RFC2822.Reply-To: Set by - original Author or Mediator Author 1658 RFC2822.Sender: Set by - Author Source or Mediator Source 1660 This will usually specify the address of the Actor responsible 1661 for mailing list operations. However some mailing lists 1662 operate in a manner very similar to a simple MTA Relay, so that 1663 they preserve as much of the original handling information as 1664 possible, including the original RFC2822.Sender field. 1666 RFC2822.To/.CC Set by - original Author 1668 These usually contain the original list of Recipient addresses. 1670 RFC2821.MailFrom Set by - Author Source or Mediator Source 1672 This can contain the original address to be notified of 1673 transmission issues, or the mailing list Actor can set it to 1674 contain a new Notification address. Typically the value is set 1675 to a new address, so that mailing list members and posters are 1676 not burdened with transmission-related Returns. 1678 RFC2821.RcptTo Set by - Mediator Author 1680 This contains the address of a mailing list member. 1682 RFC2821.Received Set by - Mediator Dest 1684 A Mailing List Actor can record a Received header field, to 1685 indicate the transition from original posting to mailing list 1686 forwarding. The Actor can choose to have the message retain 1687 the original set of Received header fields or can choose to 1688 remove them. In the latter case it can ensure that the 1689 original Received header fields are otherwise available, to 1690 ensure later accountability and diagnostic access to them. 1692 5.4. Gateways 1694 A Gateway performs the basic routing and transfer work of message 1695 relaying, but it also may make any content, structure, address, or 1696 attribute modifications needed to send the message into a messaging 1697 environment that operates according to different standards or 1698 potentially incompatible policies. When a Gateway connects two 1699 differing messaging services, its role is easy to identify and 1700 understand. When it connects environments that have technical 1701 similarity, but can have significant administrative differences, it 1702 is easy to think that a Gateway is merely an MTA. 1704 The critical distinction between an MTA and a Gateway is that the 1705 latter can make substantive changes to a message, in order to map 1706 between the standards of two, different messaging services. In 1707 virtually all cases, this mapping process results in some degree of 1708 semantic loss. The challenge of Gateway design is to minimize this 1709 loss. 1711 A Gateway can set any identity field available to a regular MUA. 1712 Identities typically relevant to Gateways include: 1714 RFC2822.From: Set by - original Author 1716 Names and email addresses for the original author(s) of the 1717 message content are retained. As for all original addressing 1718 information in the message, the Gateway can translate addresses 1719 in whatever way will allow them continue to be useful in the 1720 target environment. 1722 RFC2822.Reply-To: Set by - original Author 1724 The Gateway SHOULD retain this information, if it is originally 1725 present. The ability to perform a successful reply by a 1726 Gatewayed Recipient is a typical test of Gateway functionality. 1728 RFC2822.Sender: Set by - Author Source or Mediator Source 1730 This can retain the original value or can be set to a new 1731 address. 1733 RFC2822.To/.CC/.BCC Set by - original Recipient 1735 These usually retain their original addresses. 1737 RFC2821.MailFrom Set by - Author Source or Mediator Source 1739 The Actor responsible for gatewaying the message can choose to 1740 specify a new address to receive handling notices. 1742 RFC2822.Received Set by - Mediator Dest 1744 The Gateway can record a Received header field, to indicate the 1745 transition from the original posting environment to the new 1746 messaging environment. 1748 5.5. Boundary Filter 1750 Organizations often enforce security boundaries by subjecting 1751 messages to analysis, for conformance with the organization's safety 1752 policies. An example is detection of content classed as spam or a 1753 virus. A Filter might alter the content, to render it safe, such as 1754 by removing content deemed unacceptable. Typically these actions 1755 will result in the addition of content that records the actions. 1757 6. Considerations 1759 6.1. Security Considerations 1761 This document does not specify any new Internet Mail functionality. 1762 Consequently it is not intended to introduce any security 1763 considerations. 1765 However its discussion of the roles and responsibilities for 1766 different mail service modules, and the information they create, 1767 highlights the considerable degree to which security issues are 1768 present when implementing any component of the Internet Mail service. 1769 In addition, email transfer protocols can operate over authenticated 1770 and/or encrypted links, and message content or authorship can be 1771 authenticated or encrypted. 1773 6.2. IANA Considerations 1775 This document has no actions for IANA. 1777 7. References 1779 7.1. Normative 1781 [RFC0791] Postel, J., "Internet Protocol", 1981 September. 1783 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1784 STD 13, RFC 1034, November 1987. 1786 [RFC1035] Mockapetris, P., "Domain names - implementation and 1787 specification", STD 13, RFC 1035, November 1987. 1789 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1790 STD 53, RFC 1939, May 1996. 1792 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1793 Extensions (MIME) Part One: Format of Internet Message 1794 Bodies", RFC 2045, November 1996. 1796 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1797 Extensions (MIME) Part Two: Media Types", RFC 2046, 1798 November 1996. 1800 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1801 Part Three: Message Header Extensions for Non-ASCII Text", 1802 RFC 2047, November 1996. 1804 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1805 Extensions (MIME) Part Five: Conformance Criteria and 1806 Examples", RFC 2049, November 1996. 1808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1809 Requirement Levels", BCP 14, RFC 2119, March 1997. 1811 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1812 Specification", RFC 2181, July 1997. 1814 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1815 for Core Mail List Commands and their Transport through 1816 Message Header Fields", RFC 2369, July 1998. 1818 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1819 Addresses", RFC 2645, August 1999. 1821 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1822 April 2001. 1824 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1825 April 2001. 1827 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1828 and Namespace for the Identification of Mailing Lists", 1829 RFC 2919, March 2001. 1831 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 1832 RFC 3028, January 2001. 1834 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet 1835 Mail", RFC 2304, October 2001. 1837 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 1838 Negotiation for Messaging Services based on Email", 1839 RFC 3297, July 2002. 1841 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1842 Context for Internet Mail", RFC 3458, January 2003. 1844 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1845 Extension for Delivery Status Notifications (DSNs)", 1846 RFC 3461, January 2003. 1848 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1849 4rev1", RFC 3501, March 2003. 1851 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1852 Notification", RFC 3798, May 2004. 1854 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1855 Procedures for Message Header Fields", RFC 3864, 1856 September 2004. 1858 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 1859 Header Fields", RFC 4021, March 2005. 1861 [RFC4288] Freed, N., Klensin, J., and J. Postel, "Media Type 1862 Specifications and Registration Procedures", BCP 13, 1863 RFC 4288, December 2005. 1865 [RFC4289] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1866 Internet Mail Extensions (MIME) Part Four: Registration 1867 Procedures", BCP 13, RFC 4289, December 2005. 1869 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1870 RFC 4409, April 2006. 1872 [RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support 1873 Diverse Service Environments (Lemonade) Profile", 1874 June 2006. 1876 7.2. Informative 1878 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 1879 RFC 821, August 1982. 1881 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1882 text messages", STD 11, RFC 822, August 1982. 1884 [RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4", 1885 December 1994. 1887 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 1888 RFC 1767, March 1995. 1890 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1891 October 1996. 1893 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1895 [RFC3801] Vaudreuil, G. and G. Parsons, "", RFC 3801, June 2004. 1897 [RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for 1898 Message Tracking", RFC 3885, September 2004. 1900 [RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for 1901 Internet Mail: FFPIM", December 2005. 1903 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 1904 E. Allman, "Email Submission Operations: Access and 1905 Accountability Requirements", RFC 5068, BCP 134, Nov 2007. 1907 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 1908 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1909 ACM SIGCOMM, 2002. 1911 Appendix A. Acknowledgements 1913 This work derives from a section in draft-hutzler-spamops [RFC5068]. 1914 Discussion of the Source actor role was greatly clarified during 1915 discussions in the IETF's Marid working group. 1917 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1918 insight on the framework and details of the original drafts. 1920 Later reviews and suggestions were provided by Eric Allman, Nathaniel 1921 Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, 1922 Ned Freed, Eric Hall, Tony Hansen, Willemien Hoogendoorn, Brad 1923 Knowles, John Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David 1924 MacQuigg, Alexey Melnikov, der Mouse, S. Moonesamy, Chris Newman, 1925 Daryl Odnert, Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, 1926 Jochen Topf, Greg Vaudreuil. 1928 Diligent proof-reading was performed by Bruce Lilly. 1930 Index 1932 A 1933 Actor 1934 Administrative 15 1935 Author 10 1936 Edge 16 1937 Gateway 14 1938 Mediator 11 1939 Originator 13 1940 Recipient 10 1941 Relay 14 1942 Return Handler 11 1943 Transit 16 1944 User 16 1945 Actors 1946 MHS 12 1947 Administrative Actors 15 1948 Author 10 1950 D 1951 Discussion of document 6 1953 E 1954 Edge Actor 16 1955 end-to-end 4 1957 G 1958 Gateway 12, 14 1960 I 1961 Internet Mail 4 1963 M 1964 Mail 4 1965 Mail exchange 5 1966 Mail Handling Service 3 1967 Mail Handling System 12 1968 Mail Transfer Agent 3 1969 Mail User Agent 3 1970 MDN 10 1971 Mediator 11 1972 Message Disposition Notification 10 1973 MHS 3, 12 1974 Actors 12 1975 MTA 3 1976 MUA 3 1978 O 1979 Originator 13 1981 R 1982 Recipient 10 1983 Relay 14 1984 Return Handler 11 1986 T 1987 Transit Actor 16 1989 U 1990 UA 3 1991 User Actor 16 1992 User Agent 3 1994 Author's Address 1996 Dave Crocker 1997 Brandenburg InternetWorking 1998 675 Spruce Drive 1999 Sunnyvale, CA 94086 2000 USA 2002 Phone: +1.408.246.8253 2003 Email: dcrocker@bbiw.net 2005 Full Copyright Statement 2007 Copyright (C) The IETF Trust (2008). 2009 This document is subject to the rights, licenses and restrictions 2010 contained in BCP 78, and except as set forth therein, the authors 2011 retain all their rights. 2013 This document and the information contained herein are provided on an 2014 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2015 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2016 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2017 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2018 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2019 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2021 Intellectual Property 2023 The IETF takes no position regarding the validity or scope of any 2024 Intellectual Property Rights or other rights that might be claimed to 2025 pertain to the implementation or use of the technology described in 2026 this document or the extent to which any license under such rights 2027 might or might not be available; nor does it represent that it has 2028 made any independent effort to identify any such rights. Information 2029 on the procedures with respect to rights in RFC documents can be 2030 found in BCP 78 and BCP 79. 2032 Copies of IPR disclosures made to the IETF Secretariat and any 2033 assurances of licenses to be made available, or the result of an 2034 attempt made to obtain a general license or permission for the use of 2035 such proprietary rights by implementers or users of this 2036 specification can be obtained from the IETF on-line IPR repository at 2037 http://www.ietf.org/ipr. 2039 The IETF invites any interested party to bring to its attention any 2040 copyrights, patents or patent applications, or other proprietary 2041 rights that may cover technology that may be required to implement 2042 this standard. Please address the information to the IETF at 2043 ietf-ipr@ietf.org.