idnits 2.17.00 (12 Aug 2021) /tmp/idnits51627/draft-crocker-email-arch-09.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 1885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1909. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: It is common for sites to have local structuring conventions for the left-hand side of an . This permits sub-addressing, such as for distinguishing different discussion groups used by the same participant. However it is worth stressing that these conventions are strictly private to the user's organization and MUST not be interpreted by any domain except the one listed in the right-hand side of the addr-spec, and those specialized services conforming to standardized conventions, as noted in the next paragraph. -- 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 (May 26, 2007) is 5473 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 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) == Outdated reference: draft-hutzler-spamops has been published as RFC 5068 -- 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: 10 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SMTP D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Standards Track May 26, 2007 5 Expires: November 27, 2007 7 Internet Mail Architecture 8 draft-crocker-email-arch-09 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 November 27, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Over its thirty-five year history Internet Mail has undergone 42 significant changes in scale and complexity, as it has become a 43 global infrastructure service. The first standardized architecture 44 for networked email specified little more than a simple split between 45 the user world and the transmission world. Core aspects of the 46 service, such as the styles of mailbox address and basic message 47 format, have remained remarkably constant. However today's Internet 48 Mail is marked by many independent operators, many different 49 components for providing service to users and many others for 50 performing message transfer. Public discussion of the service often 51 lacks common terminology and a common frame of reference for these 52 components and their activities. Having a common reference model and 53 terminology makes a basic difference when talking about problems with 54 the service, changes in policy, or enhancement to the service's 55 functionality. This document offers an enhanced Internet Mail 56 architecture that targets description of the existing service, in 57 order to facilitate clearer and more efficient technical, operations 58 and policy discussions about email. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Service Overview . . . . . . . . . . . . . . . . . . . . . 5 65 1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6 66 2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 7 67 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.2. Mail Handling Service (MHS) Actors . . . . . . . . . . . . 10 69 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 13 70 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 3.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 17 73 3.3. Message Identifier . . . . . . . . . . . . . . . . . . . . 17 74 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 19 75 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 23 76 4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 28 77 4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 30 78 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 33 79 5.1. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 34 80 5.2. Re-Sending . . . . . . . . . . . . . . . . . . . . . . . . 35 81 5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 37 82 5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 38 83 5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 39 84 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 40 85 6.1. Security Considerations . . . . . . . . . . . . . . . . . 40 86 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 88 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 40 89 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 42 90 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 43 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 92 Intellectual Property and Copyright Statements . . . . . . . . . . 44 94 1. Introduction 96 Over its thirty-five year history Internet Mail has undergone 97 significant changes in scale and complexity, as it has become a 98 global infrastructure service. The changes have been evolutionary, 99 rather than revolutionary, reflecting a strong desire to preserve its 100 installed base of users and utility. Today, Internet Mail is marked 101 by many independent operators, many different components for 102 providing service to users and many other components for performing 103 message transfer. 105 Public collaboration on email technical, operations and policy 106 activities, including those responding to the challenges of email 107 abuse, has brought in a much wider range of participants than email's 108 technical community originally had. In order to do work on a large, 109 complex system, they need to share the same view of how it is put 110 together, as well as what terms to use to refer to the pieces and 111 their activities. Otherwise, it is difficult to know exactly what 112 another participant means. It is these differences in each person's 113 perspective that motivates this document, to describe the realities 114 of the current system. Internet mail is the subject of ongoing 115 technical, operations and policy work, and the discussions often are 116 hindered by different models of email service design and different 117 meanings for the same terms. This architecture document seeks to 118 facilitate clearer and more efficient technical, operations and 119 policy exchanges about email. 121 This document offers an enhanced Internet Mail architecture to 122 reflect the current service. In particular it: 124 * Documents refinements to the email model 126 * Clarifies functional roles for the architectural components 128 * Clarifies identity-related issues, across the email service 130 * Defines terminology for architectural components and their 131 interactions 133 1.1. Background 135 The first standardized architecture for networked email specified a 136 simple split between the user world, in the form of Mail User Agents 137 (MUA), and the transmission world, in the form of the Mail Handling 138 Service (MHS) composed of Mail Transfer Agents (MTA). The MHS is 139 responsible for accepting a message from one User and delivering it 140 to one or more others, creating a virtual MUA-to-MUA exchange 141 environment. 143 As shown in Figure 1 this defines two logical "layers" of 144 interoperability. One is directly between Users. The other is 145 between the neighboring components, along the transfer path. In 146 addition, there is interoperability between the layers, first when a 147 message is posted from the User to the MHS and later when it is 148 delivered from the MHS to the User. 150 As it has evolved, the operational service has sub-divided each of 151 these layers into more specialized modules. Core aspects of the 152 service, such as mailbox addressing and message format style, have 153 remained remarkably constant. So the original distinction between 154 user-level concerns and transfer-level concerns is retained, but with 155 an elaboration to each level of the architecture. The term "Internet 156 Mail" is used to refer to the entire collection of user and transfer 157 components and services. 159 For Internet Mail the term "end-to-end" usually refers to a single 160 posting and the set of deliveries directly resulting from its single 161 transiting of the MHS. A common exception is with group dialogue 162 that is mediated via a mailing list, so that two postings occur 163 before intended recipients receive an originator's message, as 164 discussed in Section 2.1.4. In fact some uses of email consider the 165 entire email service -- including Originator and Recipient -- as a 166 subordinate component. For these services "end-to-end" refers to 167 points outside of the email service. Examples are voicemail over 168 email [RFC3801], EDI over email [RFC1767] and facsimile over email 169 [RFC4142]. 171 +--------+ 172 +---------------->| User | 173 | +--------+ 174 | ^ 175 +--------+ | +--------+ . 176 | User +--+--------->| User | . 177 +--------+ | +--------+ . 178 . | ^ . 179 . | +--------+ . . 180 . +-->| User | . . 181 . +--------+ . . 182 . ^ . . 183 . . . . 184 V . . . 185 +---+----------------+------+------+---+ 186 | . . . . | 187 | +...............>+ . . | 188 | . . . | 189 | +......................>+ . | 190 | . . | 191 | +.............................>+ | 192 | | 193 | Mail Handling Service (MHS) | 194 +--------------------------------------+ 196 Figure 1: Basic Internet Mail Service Model 198 1.2. Service Overview 200 End-to-end Internet Mail exchange is accomplished by using a 201 standardized infrastructure comprising: 203 * An email object 205 * Global addressing 207 * An asynchronous sequence of point-to-point transfer mechanisms 209 * No prior arrangement between Originator and Recipient 211 * No prior arrangement between point-to-point transfer services, 212 over the open Internet 214 * No requirement for Originator and Recipient to be online at the 215 same time. 217 The end-to-end portion of the service is the email object, called a 218 message. Broadly the message, itself, distinguishes between control 219 information for handling, versus the author's message content. 221 A precept to the design of mail over the open Internet is permitting 222 user-to-user and MTA-to-MTA interoperability to take place with no 223 prior, direct arrangement between the independent administrative 224 authorities that are responsible for handling a message. That is, 225 all participants rely on the core services being universally 226 supported and accessible, either directly or through gateways that 227 translate between Internet Mail standards and other email 228 environments. Given the importance of spontaneity and serendipity in 229 the world of human communications, this lack of prearrangement 230 between participants is a core benefit of Internet Mail and remains a 231 core requirement for it. 233 Within localized networks at the edge of the public Internet, prior 234 administrative arrangement often is required and can include access 235 control, routing constraints and lookup service configuration. In 236 recent years one change to local environments is an increased 237 requirement for authentication or, at least, accountability. In 238 these cases a server performs explicit validation of the client's 239 identity. 241 1.3. Document Conventions 243 In this document, references to structured fields of a message use a 244 two-part dotted notation. The first part cites the document that 245 contains the specification for the field and the second is the name 246 of the field. Hence is the From field in an email 247 content header and is the address in the SMTP 248 "Mail From" command. 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 252 document are to be interpreted as described in RFC 2119 [RFC2119]. 254 Discussion venue: Please direct discussion about this document 255 to the IETF-SMTP mailing list . 257 Changes: Added definition of acronyms to beginning of Services 258 and standards. 260 Restricted 'envelope' to transport level and added 'trace' for 261 other handling information, and added 'handling' to cover both. 263 Removed construct of "associated with" to now use only "set 264 by". 266 Cleanup to pass the 'nits' tool check. 268 2. Responsible Actor Roles 270 Internet Mail is a highly distributed service, with a variety of 271 actors serving different roles. These divide into 3 basic types: 273 * User 275 * Mail Handling Service (MHS) 277 * ADministrative Management Domain (ADMD) 279 Although related to a technical architecture, the focus on Actors 280 concerns participant responsibilities, rather than on functionality 281 of modules. Hence the labels used are different than for classic 282 email architecture diagrams. 284 2.1. User Actors 286 Users are the sources and sinks of messages. They can be humans or 287 processes. They can have an exchange that iterates and they can 288 expand or contract the set of users participating in a set of 289 exchanges. In Internet Mail there are three types of user-level 290 Actors: 292 * Originators 294 * Recipients 296 * Mediators 298 From the User-level perspective all mail transfer activities are 299 performed by a monolithic Mail Handling Service (MHS), even though 300 the actual service can be provided by many independent organizations. 301 Users are customers of this unified service. 303 The following figure depicts the flow of messages among Actors: 304 +------------+ 305 | |<---------------------------+ 306 | Originator |<----------------+ | 307 | |<----+ | | 308 +-+---+----+-+ | | | 309 | | | | | | 310 | | V | | | 311 | | +---------+-+ | | 312 | | | Recipient | | | 313 | | +-----------+ | | 314 | | | | 315 | | +--------+ | | 316 | | | | | | 317 | V V | | | 318 | +-----------+ +-+-------+-+ | 319 | | Mediator +--->| Recipient | | 320 | +-----------+ +-----------+ | 321 | | 322 | +-----------------------------+ | 323 | | +----------+ | | 324 | | | | | | 325 V V V | | | 326 +-----------+ +-----------+ +---+-+-+---+ 327 | Mediator +--->| Mediator +--->| Recipient | 328 +-----------+ +-----------+ +-----------+ 330 Figure 2: Relationships Among User Actors 332 2.1.1. Originator 334 Also called "Author", this is the user-level participant responsible 335 for creating original content and requesting its transmission. The 336 MHS operates to send and deliver mail among Originators and 337 Recipients. As described below, the MHS has a "Source" role that 338 correlates with the user-level Author role. 340 2.1.2. Recipient 342 The Recipient is a consumer of delivered content. As described 343 below, the MHS has a "Dest[ination]" role that correlates with the 344 user-level Recipient role. 346 A Recipient can close the user-level communication loop by creating 347 and submitting a new message that replies to an Originator. An 348 example of an automated form of reply is the Message Disposition 349 Notification, which informs the Originator about the Recipient's 350 handling of the message. (See Section 4.1.) 352 2.1.3. Bounce Handler 354 The Bounce Handler receives and services notifications that are 355 generated by the MHS, as a result of efforts to transfer or deliver 356 the message. Notices can be about failures or completions and are 357 sent to an address that is specified by the Source. This Bounce 358 handling address (also known as a Return address) might have no 359 visible characteristics in common with the address of the Originator 360 or Source. 362 NOTE: The choice of the label "Bounce" is unfortunate, due to 363 its negative implication and narrow focus. However it is the 364 most popular term for the address. 366 2.1.4. Mediator 368 A Mediator receives, aggregates, reformulates and redistributes 369 messages as part of a potentially-protracted, higher-level exchange 370 among Users. Example Mediators include group dialogue, such as 371 collaboration via mailing lists, and organizational message flow, as 372 occurs with a purchase approval process. Note that it is easy to 373 confuse this user-level activity with the underlying MHS transfer 374 exchanges. However they serve very different purposes and operate in 375 very different ways. Mediators are considered extensively in 376 Section 5. 378 When mail is delivered to a receiving mediator specified in the 379 RFC2821.RcptTo command, the MHS handles it the same way as for any 380 other Recipient. That is, the MHS only sees posting and delivery 381 sources and sinks and does not see (later) re-posting as a 382 continuation of a process. Hence when submitting messages, the 383 Mediator is an Originator. 385 The distinctive aspects of a Mediator are, therefore, above the MHS. 386 A Mediator preserves the Originator information of the message it 387 reformulates, but may make meaningful changes to the content. Hence 388 the MHS sees a new message, but Users receive a message that is 389 interpreted as primarily being from -- or, at least, initiated by -- 390 the author of the original message. The role of a Mediator permits 391 distinct, active creativity, rather than being limited to the more 392 constrained job of merely connecting together other participants. 393 Hence it is really the Mediator that is responsible for the new 394 message. 396 A Mediator's task can be complex and contingent, such as modifying 397 and adding content or regulating which users are allowed to 398 participate and when. The popular example of this role is a group 399 mailing list. A sequence of Mediators may even perform a series of 400 formal steps, such as reviewing, modifying and approving a purchase 401 request. 403 Because a Mediator originates messages, it can also receive replies. 404 So a Mediator really is a full-fledged User. 406 Gateway: A Gateway is a particularly interesting form of 407 Mediator. It is a hybrid of User and Relay that interconnects 408 heterogeneous mail services. Its goal is to emulate a Relay, 409 and a detailed discussion is in Section 2.2.3. 411 2.2. Mail Handling Service (MHS) Actors 413 The Mail Handling Service (MHS) has the task of performing a single, 414 end-to-end transfer on behalf of the Originator and reaching the 415 Recipient address(es) specified in the original RFC2821.RcptTo 416 commands. Mediated or protracted, iterative exchanges, such as those 417 used for collaboration over time, are part of the User-level service, 418 and are not part of this transfer-level Handling Service. 420 The following figure depicts the relationships among transfer 421 participants in Internet Mail. It shows the Source as distinct from 422 the Originator, and Dest[ination] as distinct from Recipient, 423 although it is common for each pair to be the same actor. Transfers 424 typically entail one or more Relays. However direct delivery from 425 the Source to Destination is possible. For intra-organization mail 426 services, it is common to have only one Relay. 428 +------------+ +-----------+ 429 | Originator | +--------+ | Recipient | 430 +-----+------+ ..>| Bounce | +-----------+ 431 | . +--------+ ^ 432 | . ^ | 433 /+=================================================+\ 434 || | . | Mail Handling | || 435 || | . | Service (MHS) | || 436 V . | | 437 +---------+ . | +----+----+ 438 | | . | | | 439 | Source +.... +-<-------------+ Dest | 440 | | | | | 441 +----+----+ ^ +---------+ 442 | | ^ 443 | +-------------+-----------------+ | 444 V | | | | 445 +-------+-+ +-+-------+ +-+--+----+ 446 | Relay +-->...-->| Relay +------>| Relay | 447 +---------+ +----+----+ +---------+ 448 | 449 V 450 +---------+ 451 | Gateway +-->... 452 +---------+ 454 Figure 3: Relationships Among MHS Actors 456 2.2.1. Source 458 The Source role is responsible for ensuring that a message is valid 459 for posting and then submitting it to a Relay. Validity includes 460 conformance with Internet Mail standards, as well as with local 461 operational policies. The Source can simply review the message for 462 conformance and reject it if there are errors, or it can create some 463 or all of the necessary information. 465 The Source operates with dual "allegiance". It serves the Originator 466 and often it is the same entity. However its role in assuring 467 validity means that it MUST also represent the local operator of the 468 MHS, that is, the local ADministrative Management Domain (ADMD). 470 The Source also has the responsibility for any post-submission, 471 Originator-related administrative tasks associated with message 472 transmission and delivery. Notably this pertains to error and 473 delivery notices. Hence Source is best held accountable for the 474 message content, even when they did not create any or most of it. 476 2.2.2. Relay 478 A mail Relay performs email transfer-service routing and store-and- 479 forward by (re-)transmitting the message on towards its Recipient(s). 480 A Relay can add trace information. However it does not modify 481 existing envelope information or the message content semantics. It 482 can modify message content syntax, such as a change from binary to 483 text transfer-encoding form, only as required to meet the 484 capabilities of the next hop in the MHS. 486 A set of Relays composes a Mail Handling Service (MHS) network. This 487 is above any underlying packet-switching network that they might be 488 using and below any gateways or other user-level Mediators. 490 In other words, interesting email scenarios can involve three 491 distinct architectural layers of store-and-forward service: 493 * User Mediators 495 * MHS Relays 497 * Packet Switches 499 with the bottom-most usually being the Internet's IP service. The 500 most basic email scenarios involve Relays and Switches. 502 Aborting a message transfer results in having the Relay become an 503 Originator and sending an error message to the Bounce address. The 504 potential for looping is avoided by having this message, itself, 505 contain no Bounce address. 507 2.2.3. Gateway 509 A Gateway is a hybrid form of User and Relay that interconnects 510 heterogeneous mail services. Its purpose is simply to emulate a 511 Relay and the closer it comes to this, the better. However it 512 operates at the User level, because it MUST be able to modify message 513 content. 515 Differences between mail services can be as small as minor syntax 516 variations, but usually encompass significant, semantic distinctions. 517 One difference could have the concept of an email address being a 518 hierarchical, machine-specific address, versus having it be a flat, 519 global name space. Another difference could be between text-only 520 content, versus multi-media. Hence the Relay function in a Gateway 521 offers significant design challenges, to make the result be as 522 seamless as possible. The most significant challenge is in ensuring 523 the user-to-user functionality that matches syntax and semantics of 524 independent email standards suites. 526 The basic test of a Gateway's adequacy is, of course, whether an 527 Originator on one side of a Gateway can send a useful message to a 528 Recipient on the other side, without requiring changes to any of the 529 components in the Originator's or Recipient's mail services, other 530 than adding the Gateway. To each of these otherwise independent 531 services, the Gateway will appear to be a "native" participant. 532 However the ultimate test of a Gateway's adequacy is whether the 533 Originator and Recipient can sustain a dialogue. In particular can a 534 Recipient's MUA automatically formulate a valid Reply that will reach 535 the initial Originator? 537 2.3. Administrative Actors 539 Actors often are associated with different organizations, each with 540 its own administrative authority. This operational independence, 541 coupled with the need for interaction between groups, provides the 542 motivation for distinguishing among ADministrative Management Domains 543 (ADMD). Each ADMD can have vastly different operating policies and 544 trust-based decision-making. An obvious example is the distinction 545 between mail that is exchanged within a single organization, versus 546 mail that is exchanged between independent organizations. The rules 547 for handling these two types of traffic tend to be quite different. 548 That difference requires defining the boundaries of each, and this 549 requires the ADMD construct. 551 Operation of Internet Mail services is apportioned to different 552 providers (or operators). Each can be an independent ADMD. This 553 independence of administrative decision-making defines boundaries 554 that distinguish different portions of the Internet Mail service. 555 Examples include an end-user operating their desktop client, a 556 department operating a local Relay, an IT department operating an 557 enterprise Relay and an ISP operating a public shared email service. 558 These can be configured into many combinations of administrative and 559 operational relationships, with each ADMD potentially having a 560 complex arrangement of functional components. Figure 4 depicts 561 relationships among ADMDs. The benefit of having the ADMD construct 562 is to facilitate discussions and designs that need to distinguish 563 between "internal" issues and "external" ones. 565 The architectural impact of needing to have boundaries between ADMD's 566 is discussed in [Tussle]. Most significant is that the entities 567 communicating across ADMD boundaries will typically have an added 568 burden to enforce organizational policies concerning "external" 569 communications. At a more mundane level, the basis for routing mail 570 between ADMDs is often an issue. 572 Basic types of ADMDs include -- 574 Edge: Independent transfer services, in networks at the edge of 575 the open Internet Mail service. 577 User: End-user services. This might be subsumed under the Edge 578 service, such as is common for web-based email access. 580 Transit: These are Mail Service Providers (MSP) offering value- 581 added capabilities for Edge ADMDs, such as aggregation and 582 filtering. 584 Note that Transit services are quite different from packet-level 585 switching operation. Whereas end-to-end packet transfers usually go 586 through intermediate routers, email exchange across the open Internet 587 is often directly between the Boundary MTAs of Edge ADMDs, at the 588 email level. 590 +-------+ +-------+ +-------+ 591 | ADMD1 | | ADMD3 | | ADMD4 | 592 | ----- | | ----- | | ----- | 593 | | +---------------------->| | | | 594 | User | | |-Edge--+--->|-User | 595 | | | | +---------+ +--->| | | | 596 | V | | | ADMD2 | | +-------+ +-------+ 597 | Edge--+---+ | ----- | | 598 | | | | | | 599 +-------+ +----|-Transit-+---+ 600 | | 601 +---------+ 603 Figure 4: ADMD Example 605 Edge networks can use proprietary email standards internally. 606 However the distinction between Transit network and Edge network 607 transfer services is primarily significant because it highlights the 608 need for concern over interaction and protection between independent 609 administrations. In particular this distinction calls for additional 610 care in assessing transitions of responsibility, as well as the 611 accountability and authorization relationships among participants in 612 email transfer. 614 The interactions between functional components within an ADMD are 615 subject to the policies of that domain. Policies can cover such 616 things as reliability, access control, accountability and even 617 content evaluation and modification. They can be implemented in 618 different functional components, according to the needs of the ADMD. 619 For example see [ID-spamops]. 621 User, Edge and Transit services can be offered by providers that 622 operate component services or sets of services. Further it is 623 possible for one ADMD to host services for other ADMDs. 625 Common ADMD examples are -- 627 Enterprise Service Providers: 629 Operating an organization's internal data and/or mail services. 631 Internet Service Providers: 633 Operating underlying data communication services that, in turn, 634 are used by one or more Relays and Users. It is not 635 necessarily their job to perform email functions, but they can, 636 instead, provide an environment in which those functions can be 637 performed. 639 Mail Service Providers: 641 Operating email services, such as for end-users, or mailing 642 lists. 644 Operational pragmatics often dictate that providers be involved in 645 detailed administration and enforcement issues, to help ensure the 646 health of the overall Internet Mail Service. This can include 647 operators of lower-level packet services. 649 3. Identities 651 Internet Mail uses three forms of identity: mailbox, domain name and 652 message-id. Each is required to be globally unique. 654 3.1. Mailbox 656 "A mailbox sends and receives mail. It is a conceptual entity 657 which does not necessarily pertain to file storage." [RFC2822] 659 A mailbox is specified as an Internet Mail address . It 660 has two distinct parts, divided by an at-sign ("@"). The right-hand 661 side is a globally interpreted domain name that is part of an ADMD. 662 Domain Names are discussed in Section 3.2. Formal Internet Mail 663 addressing syntax can support source routes, to indicate the path 664 through which a message should be sent. Although legal, the use of 665 source routes is not part of the modern Internet Mail service and it 666 is ignored in the rest of this document. 668 The portion to the left of the at-sign contains a string that is 669 globally opaque and is called the . It is to be 670 interpreted only by the entity specified by the address's right-hand 671 side domain name. All other entities MUST treat the local-part as a 672 uninterpreted literal string and MUST preserve all of its original 673 details. As such its public distribution is equivalent to sending a 674 Web browser "cookie" that is only interpreted upon being returned to 675 its originator. 677 3.1.1. Global Standards for Local-Part 679 It is common for sites to have local structuring conventions for the 680 left-hand side of an . This permits sub- 681 addressing, such as for distinguishing different discussion groups 682 used by the same participant. However it is worth stressing that 683 these conventions are strictly private to the user's organization and 684 MUST not be interpreted by any domain except the one listed in the 685 right-hand side of the addr-spec, and those specialized services 686 conforming to standardized conventions, as noted in the next 687 paragraph. 689 There are a few types of addresses that have an elaboration on basic 690 email addressing, with a standardized, global schema for the local- 691 part. These are conventions between originating end-systems and 692 Recipient Gateways, and they are invisible to the public email 693 transfer infrastructure. When an Originator is explicitly sending 694 via a Gateway out of the Internet, there are coding conventions for 695 the local-part, so that the Originator can formulate instructions for 696 the Gateway. Standardized examples of this are the telephone 697 numbering formats for VPIM [RFC3801], such as 698 "+16137637582@vpim.example.com", and iFax [RFC3192], such as 699 "FAX=+12027653000/T33S=1387@ifax.example.com". 701 3.1.2. Scope of Email Address Use 703 Email addresses are being used far beyond their original email 704 transfer and delivery role. In practical terms, email strings have 705 become a common form of user identity on the Internet. What is 706 essential, then, is to be clear about the nature and role of an 707 identity string in a particular context and to be clear about the 708 entity responsible for setting that string. 710 3.2. Domain Names 712 A domain name is a global reference to an Internet resource, such as 713 a host, a service or a network. A domain name usually maps to one or 714 more IP Addresses. Conceptually the name might encompass an entire 715 organization, a collection of machines integrated into a homogeneous 716 service, or only a single machine. A domain name can be administered 717 to refer to individual users, but this is not common practice. The 718 name is structured as a hierarchical sequence of sub-names, separated 719 by dots ("."), with the top of the hierarchy being on the right-end 720 of the sequence. Domain names are defined and operated through the 721 Domain Name Service (DNS) [RFC1034], [RFC1035], [RFC2181]. 723 When not part of a mailbox address, a domain name is used in Internet 724 Mail to refer to the ADMD or the host that took action upon the 725 message, such as providing the administrative scope for a message 726 identifier, or performing transfer processing. 728 3.3. Message Identifier 730 There are two standardized tags for identifying messages: Message-ID 731 and ENVID. 733 3.3.1. Message-ID 735 The Message-ID is a user-level tag, primarily used for threading and 736 for eliminating duplicates [RFC2822]. Any actor within the 737 originating ADMD might assign the Message-ID, although it is 738 typically created by an actor within the Originating ADMD.. The 739 recipient's ADMD is the intended consumer of the Message-ID, although 740 any actor along the transfer path might use it. Internet Mail 741 standards provide for a single Message-ID; however more than one is 742 sometimes assigned. 744 Like a mailbox address, a Message-ID has two distinct parts, divided 745 by an at-sign ("@"). The right-hand side is globally interpreted and 746 specifies the ADMD or host assigning the identifier. The left-hand 747 side contains a string that is globally opaque and serves to uniquely 748 identify the message within the domain referenced on the right-hand 749 side. The duration of uniqueness for the message identifier is 750 undefined. 752 When a message is revised in any way, the question of whether to 753 assign a new Message-ID requires a subjective assessment, deciding 754 whether the editorial content has been changed enough to constitute a 755 new message. [RFC2822] says "a message identifier pertains to 756 exactly one instantiation of a particular message; subsequent 757 revisions to the message each receive new message identifiers." 758 However real-world experience dictates some flexibility. An 759 impossible test is whether the recipient will consider the new 760 message to be equivalent to the old. For most components of Internet 761 Mail, there is no way to predict a specific recipient's preferences 762 on this matter. Both creating and failing to create a new Message-ID 763 have their downsides. 765 The best that can be offered, here, are some guidelines and examples: 767 * If a message is changed only in terms of form, such as 768 character-encoding, it clearly is still the same message. 770 * If a message has minor additions to the content, such as a 771 mailing list tag at the beginning of the RFC2822.Subject header 772 field, or some mailing list administrative information added to 773 the end of the primary body-part's text, then it probably is 774 still the same message. 776 * If a message has viruses deleted from it, it probably is still 777 the same message. 779 * If a message has offensive words deleted from it, then some 780 recipients will consider it the same message, but some will 781 not. 783 * If a message is translated into a different language, then some 784 recipients will consider it the same message, but some will 785 not. 787 The absence of objective, precise criteria for Message-ID re- 788 generation, along with the absence of strong protection associated 789 with the string, means that the presence of an ID can permit an 790 assessment that is marginally better than a heuristic, but the ID 791 certainly has no value on its own for strict formal reference or 792 comparison. Hence it is not appropriate to use the Message-ID for 793 any process that might be called "security". 795 3.3.2. ENVID 797 The ENVID (envelope identifier) is a tag that is primarily for use 798 within Delivery Status Notifications (DSN), so that the Bounce 799 Address (RFC2821.MailFrom) recipient can correlate the DSN with a 800 particular message [RFC3461]. The ENVID is therefore used from one 801 message posting, until the directly-resulting message deliveries. It 802 does not survive re-postings. 804 The ENVID may also be used for message tracking purposes [RFC3885]. 806 The format of an ENVID is free-form. Although its creator might 807 choose to impose structure on the string, none is imposed by Internet 808 standards. By implication, the scope of the string is defined by the 809 domain name of the Bounce Address. 811 4. Services and Standards 813 Internet Mail's architecture distinguishes among six basic types of 814 functional components, arranged to support a store-and-forward 815 service architecture. As shown in Figure 5 these types can have 816 multiple instances, some of which represent specialized sub-roles. 817 This section considers the activities and relationships among these 818 components, and the Internet Mail standards used among them. 820 1. Message 822 2. Mail User Agent (MUA) 824 + Originating MUA (oMUA) 826 + Receiving MUA (rMUA) 828 3. Message Submission Agent (MSA) 830 + Originator-focussed MSA functions (oMSA) 832 + MHS-focussed MSA functions (hMSA) 834 4. Message Transfer Agent (MTA) 836 5. Message Delivery Agent (MDA) 838 + Recipient-focused MDA functions (rMDA) 840 + MHS-focussed MDA functions (hMDA) 842 6. Message Store (MS) 844 + Originator MS (oMS) 846 - oMS on a remote server (soMS) 848 - oMS co-located with the oMUA (uoMS) 850 + Recipient MS (rms) 852 - rMS on a remote server (srM) 854 - rMS co-located with the rMUA (urMS) 856 This section describes each functional component for Internet Mail, 857 and the standards-based protocols that are associated with their 858 operation. 860 Software implementations of these architectural components often 861 compress them, such as having the same software do MSA, MTA and MDA 862 functions. However the requirements for each of these components of 863 the service are becoming more extensive. So their separation is 864 increasingly common. 866 NOTE: A discussion about any interesting system architecture is 867 often complicated by confusion between architecture versus 868 implementation. An architecture defines the conceptual 869 functions of a service, divided into discrete conceptual 870 modules. An implementation of that architecture can combine or 871 separate architectural components, as needed for a particular 872 operational environment. It is important not to confuse the 873 engineering decisions that are made to implement a product, 874 with the architectural abstractions used to define conceptual 875 functions. 877 The following figure shows function modules and the standardized 878 protocols used between them. Additional protocols and configurations 879 are possible. Boxes defined by asterisks (*) represent functions 880 that often are distributed among two or more systems. 882 +------+ +-------+ 883 ............+ oMUA |..............................| Disp | 884 . +--+-+-+ +-------+ 885 . local,imap}| |{smtp,submission ^ 886 . | | +---------+ | 887 . ******* | | .......................| Bounces | | 888 . * oMS *<-----+ | . +---------+ | 889 . ******* | . ***************** ^ | 890 . +------V-.---*------------+ * | | 891 . MSA | +-------+ * +------+ | * | | 892 . | | oMSA +--O-->| hMSA | | * | | 893 . | +-------+ * +--+---+ | * | | 894 . +------------*------+-----+ * | | 895 /+==========+\ * V {smtp * | | 896 || MESSAGE || * +------+ * /+===+===+\ | 897 ||----------|| MHS * | MTA | * || dsn || | 898 || Envelope || * +--+---+ * \+=======+/ | 899 || SMTP || * V {smtp * ^ ^ | 900 || Content || * +------+ * | | /+==+==+\ 901 || RFC2822 || * | MTA +----*-----+ | || mdn || 902 || MIME || * +--+---+ * | \+=====+/ 903 \+==========+/ * smtp}| {local * | | 904 MDA * | {lmtp * | | 905 . +------------+------V-----+ * | | 906 . | +------+ * +------+ | * | | 907 . | | | * | | +--*---------+ | 908 . | | rMDA |<--O---+ hMDA | | * | 909 . | | | * | | |<-*-------+ | 910 . | +-+----+ * +------+ | * | | 911 . +---+--+-----*------------+ * | | 912 . | | ***************** | | 913 . pop} +--+ +---+ | | 914 . imap} | | {local | | 915 . ******************V******** | | 916 . * | +------+ * rMS /+===+===+\ | 917 . * | | srMS | * || sieve || | 918 . * V +--+-+-+ * \+=======+/ | 919 . * +------+ pop} | | * ^ | 920 . * | urMS |<-------+ | * | | 921 . * +--+---+ imap} | * | | 922 . *************************** | | 923 . local}| +------+ |{pop,imap | | 924 . +->| |<------+ | | 925 ...........>| rMUA +---------------------------+ | 926 | +-----------------------------------+ 927 +------+ 929 Figure 5: Protocols and Services 931 4.1. Message Data 933 The purpose of the Mail Handling Service (MHS) is to exchange a 934 message object among participants [RFC2822], [RFC0822]. Hence all of 935 its underlying mechanisms are merely in the service of getting that 936 message from its Originator to its Recipients. A message can be 937 explicitly labeled as to its nature [RFC3458]. 939 A message comprises a transit handling envelope and the message 940 content. The envelope contains information used by the MHS. The 941 content is divided into a structured header and the body. The header 942 comprises transit trace information and end-user structured fields. 943 The body may be unstructured simple lines of text, or it may be a 944 MIME tree of multi-media subordinate objects, called body-parts, or 945 attachments [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], 946 [RFC2049]. 948 In addition, Internet Mail has a few conventions for special control 949 data -- 951 Delivery Status Notification (DSN): 953 A Delivery Status Notification (DSN) is a message that can be 954 generated by the MHS (MSA, MTA or MDA) and sent to the 955 RFC2821.MailFrom address. The mailbox for this is shown as 956 Bounces in Figure 5. DSNs provide information about message 957 transit, such as transmission errors or successful delivery 958 [RFC3461]. 960 Message Disposition Notification (MDN): 962 A Message Disposition Notification (MDN) is a message that 963 provides information about user-level, Recipient-side message 964 processing, such as indicating that the message has been 965 displayed [RFC3798] or the form of content that can be 966 supported [RFC3297]. It can be generated by an rMUA and is 967 sent to the Disposition-Notification-To address(es). The 968 mailbox for this is shown as Disp in Figure 5. 970 Message Filtering (SIEVE): 972 SIEVE is a scripting language that permits specifying 973 conditions for differential handling of mail, typically at the 974 time of delivery [RFC3028]. It can be conveyed in a variety of 975 ways, as a MIME part. Figure 5 shows a Sieve specification 976 going from the rMUA to the MDA. However filtering can be done 977 at many different points along the transit path and any one or 978 more of them might be subject to Sieve directives, especially 979 within a single ADMD. Hence the Figure shows only one 980 relationship, for (relative) simplicity. 982 4.1.1. Envelope 984 Internet Mail has a fragmented framework for transit-related 985 "handling" information. Information that is directly used by the MHS 986 is called the "envelope". It directs handling activities by the 987 transfer service as is carried in transfer service commands. That 988 is, the envelope exists in the transfer protocol SMTP [RFC2821]. 990 Trace information records handling activity and is recorded in the 991 message Header. 993 4.1.2. Header Fields 995 Header fields are attribute name/value pairs covering an extensible 996 range of email service, user content and user transaction meta- 997 information. The core set of header fields is defined in [RFC2822], 998 [RFC0822]. It is common to extend this set, for different 999 applications. Procedures for registering header fields are defined 1000 in [RFC4021]. An extensive set of existing header field 1001 registrations is provided in [RFC3864]. 1003 One danger with placing additional information in header fields is 1004 that Gateways often alter or delete them. 1006 4.1.3. Body 1008 The body of a message might simply be lines of ASCII text or it might 1009 be hierarchically structured into a composition of multi-media body- 1010 part attachments, using MIME [RFC2045], [RFC2046], [RFC2047], 1011 [RFC4288], [RFC2049]. MIME structures each body-part into a 1012 recursive set of MIME header field meta-data and MIME Content 1013 sections. 1015 4.1.4. Identity References in a Message 1017 For a message in transit, the core uses of identifiers combine into: 1019 +-----------------------+----------------+---------------------+ 1020 | Layer | Field | Set By | 1021 +-----------------------+----------------+---------------------+ 1022 | Message Body | MIME Header | Originator | 1023 | Message header fields | From | Originator | 1024 | | Sender | Source | 1025 | | Reply-To | Originator | 1026 | | To, CC, BCC | Originator | 1027 | | Message-ID | Source | 1028 | | Received | Source, Relay, Dest | 1029 | | Return-Path | MDA, from MailFrom | 1030 | | Resent-* | Mediator | 1031 | | List-Id | Mediator Originator | 1032 | | List-* | Mediator Originator | 1033 | SMTP | HELO/EHLO | Latest Relay Client | 1034 | | ENVID | Source | 1035 | | MailFrom | Source | 1036 | | RcptTo | Originator | 1037 | IP | Source Address | Latest Relay Client | 1038 +-----------------------+----------------+---------------------+ 1040 Layered Identities 1042 The most common address-related fields are: 1044 RFC2822.From Set by: Originator 1046 Names and addresses for author(s) of the message content are 1047 listed in the From field. 1049 RFC2822.Reply-To Set by: Originator 1051 If a message Recipient sends a reply message that would otherwise 1052 use the RFC2822.From field address(es) that are contained in the 1053 original message, then they are instead to use the address(es) in 1054 the RFC2822.Reply-To field. In other words this field is a direct 1055 override of the From field, for responses from Recipients. 1057 RFC2822.Sender Set by: Source 1059 This specifies the address responsible for submitting the message 1060 into the transfer service. For efficiency this field can be 1061 omitted if it contains the same address as RFC2822.From. However 1062 this does not mean there is no Sender specified. Rather it means 1063 that that header field is virtual and that the address in the From 1064 field MUST be used. 1066 Specification of the error return addresses -- the "Bounce" 1067 address, contained in RFC2821.MailFrom -- is made by the 1068 RFC2822.Sender. Typically the Bounce address is the same as the 1069 Sender address. However some usage scenarios require it to be 1070 different. 1072 RFC2822.To/.CC Set by: Originator 1074 These specify MUA Recipient addresses. However some or all of the 1075 addresses in these fields might not be present in the 1076 RFC2821.RcptTo commands, due to handling process that might 1077 transfer from the former to the latter. 1079 The distinction between To and CC is subjective. Generally a To 1080 addressee is considered primary and is expected to take action on 1081 the message. A CC addressee typically receives a copy only for 1082 their information. 1084 RFC2822.BCC Set by: Originator 1086 A message might be copied to an addressee whose participation is 1087 not to be disclosed to the RFC2822.To or RFC2822.CC Recipients 1088 and, usually, not to the other BCC Recipients. The BCC header 1089 field indicates a message copy to such a Recipient. 1091 Typically, the field lists no addresses or only lists the address 1092 of the Recipient receiving this copy. An MUA will typically make 1093 separate postings for TO and CC Recipients, versus BCC Recipients. 1094 The former will see no indication that any BCCs were sent, whereas 1095 the latter have a BCC field present. It might be empty, contain a 1096 comment, or contain one or more BCC addresses, depending upon the 1097 preferences of the Originator. 1099 RFC2821.HELO/.EHLO Set by: Source 1101 The MSA can specify its hosting domain identity for the SMTP HELO 1102 or EHLO command operation. 1104 RFC3461.ENVID Set by: Source 1106 The MSA can specify an opaque string, to be included in a DSN, as 1107 a means of assisting the Bounce address recipient in identifying 1108 the message that produced a DSN, or message tracking. 1110 RFC2821.MailFrom Set by: Source 1111 This is an end-to-end string that specifies an email address for 1112 receiving return control information, such as "bounces". The name 1113 of this field is misleading, because it is not required to specify 1114 either the author or the agent responsible for submitting the 1115 message. Rather, the agent responsible for submission specifies 1116 the RFC2821.MailFrom address. Ultimately the simple basis for 1117 deciding what address needs to be in the RFC2821.MailFrom is to 1118 determine what address needs to be informed about transmission- 1119 level problems (and, possibly, successes.) 1121 RFC2821.RcptTo Set by: Originator 1123 This specifies the MUA mailbox address of a recipient. The string 1124 might not be visible in the message content header. For example, 1125 the message destination address header fields, such as RFC2822.To, 1126 might specify a mailing list mailbox, while the RFC2821.RcptTo 1127 address specifies a member of that list. 1129 RFC2821.Received Set by: Source, Relay, Mediator, Dest 1131 This indicates trace information, including originating host, 1132 relays, Mediators, and MSA host domain names and/or IP Addresses. 1134 RFC2821.Return-Path Set by: Source 1136 The MDA records the RFC2821.MailFrom address into the 1137 RFC2822.Return-Path field. 1139 RFC2919.List-Id Set by: Mediator Originator 1141 This provides a globally unique mailing list naming framework that 1142 is independent of particular hosts. [RFC2919] 1144 The identifier is in the form of a domain name; however the string 1145 usually is constructed by combining the two parts of an email 1146 address and the result rarely is a true domain name, listed in the 1147 domain name service -- although it can be. 1149 RFC2369.List-* Set by: Mediator Originator 1151 [RFC2369] defines a collection of message header fields for use by 1152 mailing lists. In effect they supply list-specific parameters for 1153 common mailing list user operations. The identifiers for these 1154 operations are for the list, itself, and the user-as-subscriber 1155 [RFC2369]. 1157 RFC0791.SourceAddr Set by: The Client SMTP sending host immediately 1158 preceding the current receiving SMTP server. 1160 [RFC0791] defines the basic unit of data transfer for the 1161 Internet, the IP Datagram. It contains a "Source Address" field 1162 that specifies the IP Address for the host (interface) from which 1163 the datagram was sent. This information is set and provided by 1164 the IP layer, and is therefore independent of mail-level 1165 mechanisms. As such, it is often taken to be authoritative, 1167 although it is possible to provide false addresses. 1169 4.2. User-Level Services 1171 Interactions at the user level entail protocol exchanges, distinct 1172 from those that occur at lower layers of the Internet Mail 1173 architecture, which is above the Internet Transport layer. Because 1174 the motivation for email, and much of its use, is for interaction 1175 among humans, the nature and details of these protocol exchanges 1176 often are determined by the needs of human and group communication. 1177 In terms of efforts to specify behaviors, one effect of this is to 1178 require subjective guidelines, rather than strict rules, for some 1179 aspects of system behavior. Mailing Lists provide particularly 1180 salient examples of this. 1182 4.2.1. Mail User Agent (MUA) 1184 A Mail User Agent (MUA) works on behalf of end-users and end-user 1185 applications. It is their "representative" within the email service. 1187 The Origination-side MUA (oMUA) creates a message and performs 1188 initial "submission" into the transfer infrastructure, via a Mail 1189 Submission Agent (MSA). It can also perform any creation- and 1190 posting-time archival in its Message Store (oMS). An MUA's oMS will 1191 typically include a folder for messages under development (Drafts), a 1192 folder for messages waiting to be sent (Queued or Unsent) and a 1193 folder for messages that have been successfully posted for 1194 transmission (Sent). 1196 The Recipient-side MUA (rMUA) works on behalf of the end-user 1197 Recipient to process received mail. This includes generating user- 1198 level return control messages, displaying and disposing of the 1199 received message, and closing or expanding the user communication 1200 loop, by initiating replies and forwarding new messages. 1202 NOTE: Although not shown in Figure 5, an MUA can, itself, have a 1203 distributed implementation, such as a "thin" user interface 1204 module on a limited end-user device, with the bulk of the MUA 1205 functionality operated remotely on a more capable server. An 1206 example of such an architecture might use IMAP [RFC3501] for 1207 most of the interactions between an MUA client and an MUA 1208 server. A standardized approach for such scenarios is defined 1209 by [RFC4550]. 1211 A Mediator is special class of MUA. It performs message re-posting, 1212 as discussed in Section 2.1. 1214 Identity fields relevant to a typical end-user MUA include: 1216 RFC2822.From 1218 RFC2822.Reply-To 1220 RFC2822.Sender 1222 RFC2822.To, RFC2822.CC 1224 RFC2822.BCC 1226 4.2.2. Message Store (MS) 1228 An MUA can employ a long-term Message Store (MS). Figure 5 depicts 1229 an Origination-side Ms (oMS) and a Recipient-side MS (rMS). There is 1230 a rich set of choices for configuring a store, because any MS may 1231 comprise a distributed set of component stores. In Figure 5, the rMS 1232 demonstrates this by showing an rMS that is located on a remote 1233 server (srMS) and an rMS that is on the same machine as the MUA 1234 (urMS). The relationship between two message stores, themselves, can 1235 vary. 1237 As discussed in [RFC1733] the operational relationship among MSs can 1238 be -- 1240 Online: Only a remote MS is used, with messages being accessible 1241 only when the MUA is attached to the MS, and the MUA repeatedly 1242 fetches all or part of a message, from one session to the next. 1244 Offline: The MS is local to the user, and messages are 1245 completely moved from any remote store, rather than (also) 1246 being retained there. 1248 Disconnected: An rMS and a uMS are kept synchronized, for all or 1249 part of their contents, while there is a connection between 1250 them. While they are disconnected, mail can continue to arrive 1251 at the rMS and the user may continue to make changes to the 1252 uMS. Upon reconnection, the two stores are re-synchronized. 1254 4.3. MHS-Level Services 1256 4.3.1. Mail Submission Agent (MSA) 1258 A Mail Submission Agent (MSA) accepts the message submission from the 1259 oMUA and enforces the policies of the hosting ADMD and the 1260 requirements of Internet standards. An MSA represents an unusual 1261 functional dichotomy. A portion of its task is to represent MUA 1262 (uMSA) interests during message posting, to facilitate posting 1263 success, and another portion is to represent MHS (hMSA) interests. 1264 This is best modeled, as shown in Figure 5, with two sub-components, 1265 one for the oMUA (oMSA) and one for the MHS (hMSA) 1267 The hMSA's function is to take transit responsibility for a message 1268 that conforms to the relevant Internet standards and to local site 1269 policies. It rejects messages that are not in conformance. The 1270 oMSA's is to perform final message preparation for submission and to 1271 effect the transfer of responsibility to the MHS, via the hMSA. The 1272 amount of preparation will depend upon the local implementations. 1273 Examples of oMSA tasks could be to add header fields, such as Date: 1274 and Message-ID, to modify portions of the message from local 1275 notations to Internet standards, such as expanding an address to its 1276 formal RFC2822 representation. 1278 Historically, standards-based MUA/MSA interactions have used SMTP 1279 [RFC2821]. A recent alternative is SUBMISSION [RFC4409]. Although 1280 SUBMISSION derives from SMTP, it uses a separate TCP port and imposes 1281 distinct requirements, such as access authorization. 1283 Identities relevant to the MSA include: 1285 RFC2821.HELO/.EHLO 1286 RFC3461.ENVID 1288 RFC2821.MailFrom 1290 RFC2821.RcptTo 1292 RFC2821.Received 1294 4.3.2. Mail Transfer Agent (MTA) 1296 A Mail Transfer Agent (MTA) relays mail for one application-level 1297 "hop". It is like a packet-switch or IP router in that its job is to 1298 make routing assessments and to move the message closer to the 1299 Recipient(s). Relaying is performed by a sequence of MTAs, until the 1300 message reaches a destination MDA. Hence an MTA implements both 1301 client and server MTA functionality. It does not make changes to 1302 addresses in the envelope or reformulate the editorial content. 1303 Hence a change in data form, such as to the MIME Content-Transfer- 1304 Encoding, is within the purview of an MTA, whereas removal or 1305 replacement of body content is not. Also it can add trace 1306 information. Of course email objects are typically much larger than 1307 the payload of a packet or datagram, and the end-to-end latencies are 1308 typically much higher. 1310 Internet Mail primarily uses SMTP [RFC2821], [RFC0821] to effect 1311 point-to-point transfers between peer MTAs. Other transfer 1312 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1313 most network layer mechanisms, Internet Mail's SMTP supports a basic 1314 level of reliability, by virtue of providing for retransmission after 1315 a temporary transfer failure. Contrary to typical packet switches 1316 (and Instant Messaging services) Internet Mail MTAs typically store 1317 messages in a manner that allows recovery across service 1318 interruptions, such as host system shutdown. However the degree of 1319 such robustness and persistence by an MTA can be highly variable. 1321 The primary "routing" mechanism for Internet Mail is the DNS MX 1322 record [RFC1035], which specifies a host through which the queried 1323 domain can be reached. This presumes a public -- or at least a 1324 common -- backbone that permits any attached host to connect to any 1325 other. 1327 Identities relevant to the MTA include: 1329 RFC2821.HELO/.EHLO 1331 RFC3461.ENVID 1333 RFC2821.MailFrom 1335 RFC2821.RcptTo 1337 RFC2822.Received Set by: Relay Server 1339 4.3.3. Mail Delivery Agent (MDA) 1341 A Mail Delivery Agent (MDA) delivers email to the Recipient's 1342 mailbox. It can provide distinctive, address-based functionality, 1343 made possible by its detailed knowledge of the properties of the 1344 destination address. This knowledge might also be present elsewhere 1345 in the Recipient's ADMD, such as at an organizational border 1346 (Boundary) Relay. However it is required for the MDA, if only 1347 because the MDA must know where to deliver the message. 1349 As with an MSA, an MDA serves two roles, as depicted in Figure 5. 1350 Formal transfer of responsibility, called "delivery" is effected 1351 between the two components that embody these roles. The MHS portion 1352 (hMDA) primarily functions as a server SMTP engine. A common 1353 additional role is to re-direct the message to an alternative 1354 address, as specified by the recipient addressee's preferences. The 1355 job of the recipient portion of the MDA (rMDA) is to perform any 1356 delivery-actions are desired by the recipient. 1358 Using Internet protocols, delivery can be effected by a variety of 1359 standard protocols. When coupled with an internal local mechanism, 1360 SMTP [RFC2821] and LMTP [RFC2033] permit "push" delivery to the 1361 Recipient system, at the initiative of the upstream email service. 1362 POP [RFC1939] and IMAP [RFC3501] are used for "pull" delivery at the 1363 initiative of the Recipient system. POP and IMAP can also be used 1364 for repeated access to messages on a remote MS. 1366 Identities relevant to the MDA include: 1368 RFC2821.Return-Path Set by: Originator Source or Mediator Source 1370 The MDA records the RFC2821.MailFrom address into the 1371 RFC2822.Return-Path field. 1373 RFC2822.Received Set by: MDA server 1375 An MDA can record a Received header field to indicate trace 1376 information, including source host and receiving host domain 1377 names and/or IP Addresses. 1379 5. Mediators 1381 Basic email transfer from an Originator to the specified Recipients 1382 is accomplished by using an asynchronous, store-and-forward 1383 communication infrastructure, in a sequence of independent 1384 transmissions through some number of MTAs. A very different task is 1385 a User-level sequence of postings and deliveries, through Mediators. 1386 A Mediator forwards a message, through a re-posting process. The 1387 Mediator does share some functionality with basic MTA relaying, but 1388 it enjoys a degree of freedom with both addressing and content that 1389 is not available to MTAs. 1391 RFC2821.HELO/.EHLO Set by: Mediator Source 1393 RFC3461.ENVID Set by: Originator Source or Mediator Source 1395 RFC2821.MailFrom Set by: Originator Source or Mediator Source 1397 RFC2821.RcptTo Set by: Mediator Originator 1399 RFC2821.Received Set by: Mediator Dest 1401 The salient aspect of a Mediator, that distinguishes it from any 1402 other MUA creating an entirely new message, is that a Mediator 1403 preserves the integrity and tone of the original message, including 1404 the essential aspects of its origination information. The Mediator 1405 might also add commentary. 1407 Examples of MUA message creation that are NOT performed by Mediators 1408 include -- 1410 New message that forwards an existing message: 1412 This action rather curiously provides a basic template for a 1413 class of Mediators. However for its typical occurrence it is 1414 not itself an example of a Mediator. The new message is viewed 1415 as being from the Agent doing the forwarding, rather than being 1416 from the original Originator. 1418 A new message encapsulates the original message and is seen as 1419 strictly "from" the Mediator. The Mediator might add 1420 commentary and certainly has the opportunity to modify the 1421 original message content. The forwarded message is therefore 1422 independent of the original message exchange and creates a new 1423 message dialogue. However the final Recipient sees the 1424 contained message as from the original Originator. 1426 Reply: 1428 When a Recipient formulates a response back to the original 1429 message's author, the new message is not typically viewed as 1430 being a "forwarding" of the original. Its focus is the new 1431 content, although it might contain all or part of the material 1432 in the original message. Therefore the earlier material is 1433 merely contextual and secondary. 1435 Annotation: 1437 The integrity of the original message is usually preserved, but 1438 one or more comments about the message are added in a manner 1439 that distinguishes commentary from original text. The tone of 1440 the new message is that it is primarily commentary from a new 1441 Originator, similar to a Reply. 1443 The remainder of this section describes common examples of Mediators. 1445 5.1. Aliasing 1447 Aliasing is a simple re-addressing facility that is available in most 1448 MDA implementations. It is performed just before placing a message 1449 into the specified Recipient's mailbox. Instead the message is 1450 submitted back to the transfer service, for delivery to one or more 1451 alternate addresses. Although typically implemented as part of an 1452 MDA, this facility is strictly a Recipient user function. It 1453 resubmits the message, replacing the envelope address, on behalf of 1454 the mailbox address that was listed in the envelope. 1456 What is most distinctive about this forwarding mechanism is how 1457 closely it compares to normal MTA store-and-forward Relaying. Its 1458 only interesting difference is that it changes the RFC2821.RcptTo 1459 value. Having the change be this small makes it easy to view 1460 aliasing as a part of the lower-level mail relaying activity. 1461 However the small change has a large semantic impact: The designated 1462 recipient has chosen a new recipient. Hence that original recipient 1463 SHOULD become responsible for any handling issues. This change would 1464 be reflected by replacing the message's RFC2821.MailFrom address to 1465 be one within the scope of the ADMD doing the aliasing. 1467 An MDA that is re-posting a message to an alias typically changes 1468 only envelope information: 1470 RFC2822.To/.CC/.BCC Set by: Originator 1472 These retain their original addresses. 1474 RFC2821.RcptTo Set by: Mediator Originator 1476 This field contains an alias address. 1478 RFC2821.MailFrom Set by: Originator Source or Mediator Source 1480 The agent responsible for submission to an alias address will 1481 often retain the original address to receive handling Bounces. 1482 The benefit of retaining the original MailFrom value is to 1483 ensure that the origination-side agent knows that there has 1484 been a delivery problem. On the other hand, the responsibility 1485 for the problem usually lies with the Recipient, since the 1486 Alias mechanism is strictly under the Recipient's control. 1488 RFC2821.Received Set by: Mediator Dest 1490 The agent can record Received information, to indicate the 1491 delivery to the original address and submission to the alias 1492 address. The trace of Received header fields can therefore 1493 include everything from original posting through final delivery 1494 to a final delivery. 1496 5.2. Re-Sending 1498 Also called Re-Directing, Re-Sending differs from Forwarding by 1499 virtue of having the Mediator "splice" a message's addressing 1500 information, to connect the Originator of the original message and 1501 the Recipient of the new message. This permits them to have direct 1502 exchange, using their normal MUA Reply functions. Hence the new 1503 Recipient sees the message as being From the original Originator, 1504 even if the Mediator adds commentary. 1506 Identities specified in a resent message include 1508 RFC2822.From Set by: original Originator 1510 Names and email addresses for the original author(s) of the 1511 message content are retained. The free-form (display-name) 1512 portion of the address might be modified to provide informal 1513 reference to the agent responsible for the redirection. 1515 RFC2822.Reply-To Set by: original Originator 1517 If this field is present in the original message, it is 1518 retained in the Resent message. 1520 RFC2822.Sender Set by: Originator Source or Mediator Source. 1522 RFC2822.To/.CC/.BCC Set by: original Originator 1524 These specify the original message Recipients. 1526 RFC2822.Resent-From Set by: Mediator Originator 1528 The address of the original Recipient who is redirecting the 1529 message. Otherwise the same rules apply for the Resent-From 1530 field as for an original RFC2822.From field. 1532 RFC2822.Resent-Sender Set by: Mediator Source 1534 The address of the agent responsible for re-submitting the 1535 message. As with RFC2822.Sender, this field is often omitted 1536 when it would merely contain the same address as 1537 RFC2822.Resent-From. 1539 RFC2822.Resent-To/-CC/-BCC: Set by: Mediator Originator 1541 The addresses of the new Recipients who will now be able to 1542 reply to the original author. 1544 RFC2821.MailFrom Set by: Mediator Source 1546 The agent responsible for re-submission (RFC2822.Resent-Sender) 1547 is also responsible for specifying the new MailFrom address. 1549 RFC2821.RcptTo Set by: Mediator Originator 1551 This will contain the address of a new Recipient. 1553 RFC2822.Received Set by: Mediator Dest 1555 When resending a message the submission agent can record a 1556 Received header field, to indicate the transition from original 1557 posting to resubmission. 1559 5.3. Mailing Lists 1561 Mailing lists have explicit email addresses and they re-post messages 1562 to a list of subscribed members. The Mailing List Actor performs a 1563 task that can be viewed as an elaboration of the Re-Director role. 1564 In addition to sending the new message to a potentially large number 1565 of new Recipients, the Mediator can modify content, such as deleting 1566 attachments, converting the format, and adding list-specific 1567 comments. In addition, archiving list messages is common. Still the 1568 message retains characteristics of being "from" the original 1569 Originator. 1571 Identities relevant to a mailing list processor, when submitting a 1572 message, include: 1574 RFC2919.List-Id Set by: Mediator Originator 1576 RFC2369.List-* Set by: Mediator Originator 1578 RFC2822.From Set by: original Originator 1580 Names and email addresses for the original author(s) of the 1581 message content are specified -- or, rather, retained. 1583 RFC2822.Reply-To Set by: original Originator or Mediator 1584 Originator 1586 RFC2822.Sender Set by: Originator Source or Mediator Source 1588 This will usually specify the address of the agent responsible 1589 for mailing list operations. However some mailing lists 1590 operate in a manner very similar to a simple MTA Relay, so that 1591 they preserve as much of the original handling information as 1592 possible, including the original RFC2822.Sender field. 1594 RFC2822.To/.CC Set by: original Originator 1596 These usually contain the original list of Recipient addresses. 1598 RFC2821.MailFrom Set by: Originator Source or Mediator Source 1600 This can contain the original address to be notified of 1601 transmission issues, or the mailing list agent can set it to 1602 contain a new Notification address. Typically the value is set 1603 to a new address, so that mailing list members and posters are 1604 not burdened with transmission-related Bounces. 1606 RFC2821.RcptTo Set by: Mediator Originator 1608 This contains the address of a mailing list member. 1610 RFC2821.Received Set by: Mediator Dest 1612 A Mailing List Agent can record a Received header field, to 1613 indicate the transition from original posting to mailing list 1614 forwarding. The Agent can choose to have the message retain 1615 the original set of Received header fields or can choose to 1616 remove them. In the latter case it can ensure that the 1617 original Received header fields are otherwise available, to 1618 ensure later accountability and diagnostic access to them. 1620 5.4. Gateways 1622 A Gateway performs the basic routing and transfer work of message 1623 relaying, but it also may make any message or address modifications 1624 that are needed to send the message into a messaging environment that 1625 operates according to different standards or potentially incompatible 1626 policies. When a Gateway connects two differing messaging services, 1627 its role is easy to identify and understand. When it connects 1628 environments that have technical similarity, but can have significant 1629 administrative differences, it is easy to think that a Gateway is 1630 merely an MTA. 1632 The critical distinction between an MTA and a Gateway is that the 1633 latter transforms addresses and/or message content, in order to map 1634 between the standards of two, different messaging services. In 1635 virtually all cases, this mapping process results in some degree of 1636 semantic loss. The challenge of Gateway design is to minimize this 1637 loss. 1639 A Gateway can set any identity field available to a regular MUA. 1640 Identities typically relevant to Gateways include: 1642 RFC2822.From Set by: original Originator 1644 Names and email addresses for the original author(s) of the 1645 message content are retained. As for all original addressing 1646 information in the message, the Gateway can translate addresses 1647 in whatever way will allow them continue to be useful in the 1648 target environment. 1650 RFC2822.Reply-To Set by: original Originator 1652 The Gateway SHOULD retain this information, if it is originally 1653 present. The ability to perform a successful reply by a 1654 Gatewayed Recipient is a typical test of Gateway functionality. 1656 RFC2822.Sender Set by: Originator Source or Mediator Source 1658 This can retain the original value or can be set to a new 1659 address. 1661 RFC2822.To/.CC/.BCC Set by: original Recipient 1663 These usually retain their original addresses. 1665 RFC2821.MailFrom Set by: Originator Source or Mediator Source 1667 The agent responsible for gatewaying the message can choose to 1668 specify a new address to receive handling notices. 1670 RFC2822.Received Set by: Mediator Dest 1672 The Gateway can record a Received header field, to indicate the 1673 transition from the original posting environment to the new 1674 messaging environment. 1676 5.5. Boundary Filter 1678 Organizations often enforce security boundaries by subjecting 1679 messages to analysis, for conformance with the organization's safety 1680 policies. An example is detection of content classed as spam or a 1681 virus. A Filter might alter the content, to render it safe, such as 1682 by removing content deemed unacceptable. Typically these actions 1683 will result in the addition of content that records the actions. 1685 6. Considerations 1687 6.1. Security Considerations 1689 This document does not specify any new Internet Mail functionality. 1690 Consequently it is not intended to introduce any security 1691 considerations. 1693 However its discussion of the roles and responsibilities for 1694 different mail service modules, and the information they create, 1695 highlights the considerable degree to which security issues are 1696 present when implementing any component of the Internet Mail service. 1697 In addition, email transfer protocols can operate over authenticated 1698 and/or encrypted links, and message content or authorship can be 1699 authenticated or encrypted. 1701 6.2. IANA Considerations 1703 This document has no actions for IANA. 1705 7. References 1707 7.1. Normative 1709 [RFC0791] Postel, J., "Internet Protocol", 1981 September. 1711 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1712 STD 13, RFC 1034, November 1987. 1714 [RFC1035] Mockapetris, P., "Domain names - implementation and 1715 specification", STD 13, RFC 1035, November 1987. 1717 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1718 STD 53, RFC 1939, May 1996. 1720 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1721 Extensions (MIME) Part One: Format of Internet Message 1722 Bodies", RFC 2045, November 1996. 1724 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1725 Extensions (MIME) Part Two: Media Types", RFC 2046, 1726 November 1996. 1728 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1729 Part Three: Message Header Extensions for Non-ASCII Text", 1730 RFC 2047, November 1996. 1732 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1733 Extensions (MIME) Part Five: Conformance Criteria and 1734 Examples", RFC 2049, November 1996. 1736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1737 Requirement Levels", BCP 14, RFC 2119, March 1997. 1739 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1740 Specification", RFC 2181, July 1997. 1742 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1743 for Core Mail List Commands and their Transport through 1744 Message Header Fields", RFC 2369, July 1998. 1746 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1747 Addresses", RFC 2645, August 1999. 1749 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1750 April 2001. 1752 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1753 April 2001. 1755 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1756 and Namespace for the Identification of Mailing Lists", 1757 RFC 2919, March 2001. 1759 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 1760 RFC 3028, January 2001. 1762 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet 1763 Mail", RFC 2304, October 2001. 1765 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 1766 Negotiation for Messaging Services based on Email", 1767 RFC 3297, July 2002. 1769 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1770 Context for Internet Mail", RFC 3458, January 2003. 1772 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1773 Extension for Delivery Status Notifications (DSNs)", 1774 RFC 3461, January 2003. 1776 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1777 4rev1", RFC 3501, March 2003. 1779 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1780 Notification", RFC 3798, May 2004. 1782 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1783 Procedures for Message Header Fields", RFC 3864, 1784 September 2004. 1786 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 1787 Header Fields", RFC 4021, March 2005. 1789 [RFC4288] Freed, N., Klensin, J., and J. Postel, "Media Type 1790 Specifications and Registration Procedures", BCP 13, 1791 RFC 4288, December 2005. 1793 [RFC4289] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1794 Internet Mail Extensions (MIME) Part Four: Registration 1795 Procedures", BCP 13, RFC 4289, December 2005. 1797 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1798 RFC 4409, April 2006. 1800 [RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support 1801 Diverse Service Environments (Lemonade) Profile", 1802 June 2006. 1804 7.2. Informative 1806 [ID-spamops] 1807 Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 1808 E. Allman, "Email Submission Between Independent 1809 Networks", draft-hutzler-spamops-06 (work in progress), 1810 May 2007. 1812 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 1813 RFC 821, August 1982. 1815 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1816 text messages", STD 11, RFC 822, August 1982. 1818 [RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4", 1819 December 1994. 1821 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 1822 RFC 1767, March 1995. 1824 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1825 October 1996. 1827 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1829 [RFC3801] Vaudreuil, G. and G. Parsons, "", RFC 3801, June 2004. 1831 [RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for 1832 Message Tracking", RFC 3885, September 2004. 1834 [RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for 1835 Internet Mail: FFPIM", December 2005. 1837 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 1838 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1839 ACM SIGCOMM, 2002. 1841 Appendix A. Acknowledgements 1843 This work derives from a section in draft-hutzler-spamops 1844 [ID-spamops]. Discussion of the Source actor role was greatly 1845 clarified during discussions in the IETF's Marid working group. 1847 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1848 insight on the framework and details of the original drafts. 1850 Later reviews and suggestions were provided by Eric Allman, Nathaniel 1851 Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, 1852 Ned Freed, Eric Hall, Tony Hansen, Willemien Hoogendoorn, Brad 1853 Knowles, John Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David 1854 MacQuigg, Alexey Melnikov, der Mouse, S. Moonesamy, Chris Newman, 1855 Daryl Odnert, Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, 1856 Jochen Topf, Greg Vaudreuil. 1858 Diligent proof-reading was performed by Bruce Lilly. 1860 Author's Address 1862 Dave Crocker 1863 Brandenburg InternetWorking 1864 675 Spruce Drive 1865 Sunnyvale, CA 94086 1866 USA 1868 Phone: +1.408.246.8253 1869 Email: dcrocker@bbiw.net 1871 Full Copyright Statement 1873 Copyright (C) The IETF Trust (2007). 1875 This document is subject to the rights, licenses and restrictions 1876 contained in BCP 78, and except as set forth therein, the authors 1877 retain all their rights. 1879 This document and the information contained herein are provided on an 1880 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1881 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1882 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1883 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1884 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1885 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1887 Intellectual Property 1889 The IETF takes no position regarding the validity or scope of any 1890 Intellectual Property Rights or other rights that might be claimed to 1891 pertain to the implementation or use of the technology described in 1892 this document or the extent to which any license under such rights 1893 might or might not be available; nor does it represent that it has 1894 made any independent effort to identify any such rights. Information 1895 on the procedures with respect to rights in RFC documents can be 1896 found in BCP 78 and BCP 79. 1898 Copies of IPR disclosures made to the IETF Secretariat and any 1899 assurances of licenses to be made available, or the result of an 1900 attempt made to obtain a general license or permission for the use of 1901 such proprietary rights by implementers or users of this 1902 specification can be obtained from the IETF on-line IPR repository at 1903 http://www.ietf.org/ipr. 1905 The IETF invites any interested party to bring to its attention any 1906 copyrights, patents or patent applications, or other proprietary 1907 rights that may cover technology that may be required to implement 1908 this standard. Please address the information to the IETF at 1909 ietf-ipr@ietf.org. 1911 Acknowledgment 1913 Funding for the RFC Editor function is provided by the IETF 1914 Administrative Support Activity (IASA).