idnits 2.17.00 (12 Aug 2021) /tmp/idnits49635/draft-crocker-email-arch-08.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 1876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1900. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 20, 2007) is 5479 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: 'RFC3801' is mentioned on line 1823, but not defined == Missing Reference: 'RFC1767' is mentioned on line 1820, but not defined == Missing Reference: 'RFC4142' is mentioned on line 1825, but not defined == Missing Reference: 'Tussle' is mentioned on line 1828, but not defined == Missing Reference: 'ID-spamops' is mentioned on line 1835, but not defined == Missing Reference: 'RFC1733' is mentioned on line 1817, but not defined ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 2033 ** Downref: Normative reference to an Informational RFC: RFC 2442 ** 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) Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 7 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 20, 2007 5 Expires: November 21, 2007 7 Internet Mail Architecture 8 draft-crocker-email-arch-08 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 21, 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 . . . . . . . . . . . . . . . . . . . . . . . 22 76 4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 27 77 4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 29 78 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 5.1. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 33 80 5.2. Re-Sending . . . . . . . . . . . . . . . . . . . . . . . . 34 81 5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 36 82 5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 37 83 5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 38 84 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 39 85 6.1. Security Considerations . . . . . . . . . . . . . . . . . 39 86 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 39 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 88 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 39 89 7.2. Descriptive . . . . . . . . . . . . . . . . . . . . . . . 41 90 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 42 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42 92 Intellectual Property and Copyright Statements . . . . . . . . . . 43 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] 170 +--------+ 171 +---------------->| User | 172 | +--------+ 173 | ^ 174 +--------+ | +--------+ . 175 | User +--+--------->| User | . 176 +--------+ | +--------+ . 177 . | ^ . 178 . | +--------+ . . 179 . +-->| User | . . 180 . +--------+ . . 181 . ^ . . 182 . . . . 183 V . . . 184 +---+----------------+------+------+---+ 185 | . . . . | 186 | +...............>+ . . | 187 | . . . | 188 | +......................>+ . | 189 | . . | 190 | +.............................>+ | 191 | | 192 | Mail Handling Service (MHS) | 193 +--------------------------------------+ 195 Figure 1: Basic Internet Mail Service Model 197 1.2. Service Overview 199 End-to-end Internet Mail exchange is accomplished by using a 200 standardized infrastructure comprising: 202 * An email object 204 * Global addressing 206 * An asynchronous sequence of point-to-point transfer mechanisms 208 * No prior arrangement between Originator and Recipient 210 * No prior arrangement between point-to-point transfer services, 211 over the open Internet 213 * No requirement for Originator and Recipient to be online at the 214 same time. 216 The end-to-end portion of the service is the email object, called a 217 message. Broadly the message, itself, distinguishes between control 218 information for handling, versus the author's message content. 220 A precept to the design of mail over the open Internet is permitting 221 user-to-user and MTA-to-MTA interoperability to take place with no 222 prior, direct arrangement between the independent administrative 223 authorities that are responsible for handling a message. That is, 224 all participants rely on having the core services be universally 225 supported and accessible, either directly or through gateways that 226 translate between Internet Mail standards and other email 227 environments. Given the importance of spontaneity and serendipity in 228 the world of human communications, this lack of prearrangement 229 between participants is a core benefit of Internet Mail and remains a 230 core requirement for it. 232 Within localized networks at the edge of the public Internet, prior 233 administrative arrangement often is required and can include access 234 control, routing constraints and lookup service configuration. In 235 recent years one change to local environments is an increased 236 requirement for authentication or, at least, accountability. In 237 these cases a server performs explicit validation of the client's 238 identity. 240 1.3. Document Conventions 242 In this document, references to structured fields of a message use a 243 two-part dotted notation. The first part cites the document that 244 contains the specification for the field and the second is the name 245 of the field. Hence is the From field in an email 246 content header and is the address in the SMTP 247 "Mail From" command. 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as specified in RFC 2119 [RFC2119]. 253 Discussion venue: Please direct discussion about this document 254 to the IETF-SMTP mailing list . 256 Changes: Removed "associated with" construct, relying only on 257 "set by" 258 Made identity table and discussions more consistent. 260 Restricted "envelope" only to refer to SMTP information, 261 calling RFC2822-level fields "Trace information". 263 Moved "Bounce" to be User Actor. 265 Extended introduction to acronyms in Services and Standards 266 section. 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. 302 Users are customers of this unified service. 304 The following depicts the flow of messages among Actors: 305 +------------+ 306 | |<---------------------------+ 307 | Originator |<----------------+ | 308 | |<----+ | | 309 +-+---+----+-+ | | | 310 | | | | | | 311 | | V | | | 312 | | +---------+-+ | | 313 | | | Recipient | | | 314 | | +-----------+ | | 315 | | | | 316 | | +--------+ | | 317 | | | | | | 318 | V V | | | 319 | +-----------+ +-+-------+-+ | 320 | | Mediator +--->| Recipient | | 321 | +-----------+ +-----------+ | 322 | | 323 | +-----------------------------+ | 324 | | +----------+ | | 325 | | | | | | 326 V V V | | | 327 +-----------+ +-----------+ +---+-+-+---+ 328 | Mediator +--->| Mediator +--->| Recipient | 329 +-----------+ +-----------+ +-----------+ 331 Figure 2: Relationships Among User Actors 333 2.1.1. Originator 335 Also called "Author", this is the user-level participant responsible 336 for creating original content and requesting its transmission. The 337 MHS operates to send and deliver mail among Originators and 338 Recipients. As described below, the MHS has a "Source" role that 339 correlates with the user-level Author role. 341 2.1.2. Recipient 343 The Recipient is a consumer of delivered content. As described 344 below, the MHS has a "Dest[ination]" role that correlates with the 345 user-level Recipient role. 347 A Recipient can close the user-level communication loop by creating 348 and submitting a new message that replies to an Originator. An 349 example of an automated form of reply is the Message Disposition 350 Notification, which informs the Originator about the Recipient's 351 handling of the message. (See Section 4.1.) 353 2.1.3. Bounce Handler 355 The Bounce Handler receives and services notifications that are 356 generated by the MHS, as a result of efforts to transfer or deliver 357 the message. Notices can be about failures or completions and are 358 sent to an address that is specified by the Source. This Bounce 359 handling address (also known as a Return address) might have no 360 visible characteristics in common with the address of the Originator 361 or Source. 363 NOTE: The choice of the label "Bounce" is unfortunate, due to 364 its negative implication and narrow focus. However it is the 365 most popular term for the address. 367 2.1.4. Mediator 369 A Mediator receives, aggregates, reformulates and redistributes 370 messages as part of a potentially-protracted, higher-level exchange 371 among Users. Example Mediators include group dialogue, such as 372 collaboration via mailing lists, and organizational message flow, as 373 occurs with a purchase approval process. Note that it is easy to 374 confuse this user-level activity with the underlying MHS transfer 375 exchanges. However they serve very different purposes and operate in 376 very different ways. Mediators are considered extensively in 377 Section 5. 379 When mail is delivered to a receiving mediator specified in the 380 RFC2821.RcptTo command, the MHS handles it the same way as for any 381 other Recipient. That is, the MHS only sees posting and delivery 382 sources and sinks and does not see (later) re-posting as a 383 continuation of a process. Hence when submitting messages, the 384 Mediator is an Originator. 386 The distinctive aspects of a Mediator are, therefore, above the MHS. 387 A Mediator preserves the Originator information of the message it 388 reformulates, but may make meaningful changes to the content. Hence 389 the MHS sees a new message, but Users receive a message that is 390 interpreted as primarily being from -- or, at least, initiated by -- 391 the author of the original message. The role of a Mediator permits 392 distinct, active creativity, rather than being limited to the more 393 constrained job of merely connecting together other participants. 394 Hence it is really the Mediator that is responsible for the new 395 message. 397 A Mediator's task can be complex and contingent, such as by modifying 398 and adding content or regulating which users are allowed to 399 participate and when. The popular example of this role is a group 400 mailing list. A sequence of Mediators may even perform a series of 401 formal steps, such as reviewing, modifying and approving a purchase 402 request. 404 Because a Mediator originates messages, it can also receive replies. 405 So a Mediator really is a full-fledged User. 407 Gateway: A Gateway is a particularly interesting form of 408 Mediator. It is a hybrid of User and Relay that interconnects 409 heterogeneous mail services. Its goal is to emulate a Relay, 410 and a detailed discussion is in Section 2.2.3. 412 2.2. Mail Handling Service (MHS) Actors 414 The Mail Handling Service (MHS) has the task of performing a single, 415 end-to-end transfer on behalf of the Originator and reaching the 416 Recipient address(es) specified in the original RFC2821.RcptTo 417 commands. Mediated or protracted, iterative exchanges, such as those 418 used for collaboration over time, are part of the User-level service, 419 and are not part of this transfer-level Handling Service. 421 The following depicts the relationships among transfer participants 422 in Internet Mail. It shows the Source as distinct from the 423 Originator, and Dest[ination] as distinct from Recipient, although it 424 is common for each pair to be the same actor. Transfers typically 425 entail one or more Relays. However direct delivery from the Source 426 to Destination is possible. For intra-organization mail services, it 427 is common to have only one Relay. 429 +------------+ +-----------+ 430 | Originator | +--------+ | Recipient | 431 +-----+------+ ..>| Bounce | +-----------+ 432 | . +--------+ ^ 433 | . ^ | 434 /+=================================================+\ 435 || | . | Mail Handling | || 436 || | . | Service (MHS) | || 437 V . | | 438 +---------+ . | +----+----+ 439 | | . | | | 440 | Source +.... +-<-------------+ Dest | 441 | | | | | 442 +----+----+ ^ +---------+ 443 | | ^ 444 | +-------------+-----------------+ | 445 V | | | | 446 +-------+-+ +-+-------+ +-+--+----+ 447 | Relay +-->...-->| Relay +------>| Relay | 448 +---------+ +----+----+ +---------+ 449 | 450 V 451 +---------+ 452 | Gateway +-->... 453 +---------+ 455 Figure 3: Relationships Among MHS Actors 457 2.2.1. Source 459 The Source role is responsible for ensuring that a message is valid 460 for posting and then submitting it to a Relay. Validity includes 461 conformance with Internet Mail standards, as well as with local 462 operational policies. The Source can simply review the message for 463 conformance and reject it if there are errors, or it can create some 464 or all of the necessary information. 466 The Source operates with dual "allegiance". It serves the Originator 467 and often it is the same entity. However its role in assuring 468 validity means that it MUST also represent the local operator of the 469 MHS, that is, the local ADministrative Management Domain (ADMD). 471 The Source also has the responsibility for any post-submission, 472 Originator-related administrative tasks associated with message 473 transmission and delivery. Notably this pertains to error and 474 delivery notices. Hence Source is best held accountable for the 475 message content, even when they did not create any or most of it. 477 2.2.2. Relay 479 A mail Relay performs email transfer-service routing and store-and- 480 forward by (re-)transmitting the message on towards its Recipient(s). 481 A Relay can add trace information. However it does not modify 482 existing envelope information or the message content semantics. It 483 can modify message content syntax, such as a change from text to 484 binary transfer-encoding form, only as required to meet the 485 capabilities of the next hop in the MHS. 487 A set of Relays composes a Mail Handling Service (MHS) network. This 488 is above any underlying packet-switching network that they might be 489 using and below any gateways or other user-level Mediators. 491 In other words, interesting email scenarios can involve three 492 distinct architectural layers of store-and-forward service: 494 * User Mediators 496 * MHS Relays 498 * Packet Switches 500 with the bottom-most usually being the Internet's IP service. The 501 most basic email scenarios involve Relays and Switches. 503 Aborting a message transfer results in having the Relay become an 504 Originator and send an error message to the Bounce address. The 505 potential for looping is avoided by having this message, itself, 506 contain no Bounce address. 508 2.2.3. Gateway 510 A Gateway is a hybrid form of User and Relay that interconnects 511 heterogeneous mail services. Its purpose is simply to emulate a 512 Relay and the closer it comes to this, the better. However it 513 operates at the User level, because it MUST be able to modify message 514 content. 516 Differences between mail services can be as small as minor syntax 517 variations, but usually encompass significant, semantic distinctions. 518 One difference could have the concept of an email address be a 519 hierarchical, machine-specific address, versus having it be a flat, 520 global name space. Another difference could be between text-only 521 content, versus multi-media. Hence the Relay function in a Gateway 522 offers significant design challenges, to make the result be as 523 seamless as possible. The most significant challenge is in ensuring 524 the user-to-user functionality that matches syntax and semantics of 525 independent email standards suites. 527 The basic test of a Gateway's adequacy is, of course, whether an 528 Originator on one side of a Gateway can send a useful message to a 529 Recipient on the other side, without requiring changes to any of the 530 components in the Originator's or Recipient's mail services, other 531 than adding the Gateway. To each of these otherwise independent 532 services, the Gateway will appear to be a "native" participant. 533 However the ultimate test of a Gateway's adequacy is whether the 534 Originator and Recipient can sustain a dialogue. In particular can a 535 Recipient's MUA automatically formulate a valid Reply that will reach 536 the initial Originator? 538 2.3. Administrative Actors 540 Actors often are associated with different organizations, each with 541 its own administrative authority. This operational independence, 542 coupled with the need for interaction between groups, provides the 543 motivation for distinguishing among ADministrative Management Domains 544 (ADMD). Each ADMD can have vastly different operating policies and 545 trust-based decision-making. An obvious example is the distinction 546 between mail that is exchanged within a single organization, versus 547 mail that is exchanged between independent organizations. The rules 548 for handling these two types of traffic tend to be quite different. 549 That difference requires defining the boundaries of each, and this 550 requires the ADMD construct. 552 Operation of Internet Mail services is apportioned to different 553 providers (or operators). Each can be an independent ADMD. This 554 independence of administrative decision-making defines boundaries 555 that distinguish different portions of the Internet Mail service. 556 Examples include an end-user operating their desktop client, a 557 department operating a local Relay, an IT department operating an 558 enterprise Relay and an ISP operating a public shared email service. 559 These can be configured into many combinations of administrative and 560 operational relationships, with each ADMD potentially having a 561 complex arrangement of functional components. Figure 4 depicts 562 relationships among ADMDs. The benefit of having the ADMD construct 563 is to facilitate discussions and designs that need to distinguish 564 between "internal" issues and "external" ones. 566 The architectural impact of needing to have boundaries between ADMD's 567 is discussed in [Tussle]. Most significant is that the entities 568 communicating across ADMD boundaries will typically have an added 569 burden to enforce organizational policies concerning "external" 570 communications. At a more mundane level, the basis for routing mail 571 between ADMDs is often an issue. 573 Basic types of ADMDs include -- 575 Edge: Independent transfer services, in networks at the edge of 576 the open Internet Mail service. 578 User: End-user services. This might be subsumed under the Edge 579 service, such as is common for web-based email access. 581 Transit: These are Mail Service Providers (MSP) offering value- 582 added capabilities for Edge ADMDs, such as aggregation and 583 filtering. 585 Note that Transit services are quite different from packet-level 586 switching operation. Whereas end-to-end packet transfers usually go 587 through intermediate routers, email exchange across the open Internet 588 is often directly between the Boundary MTAs of Edge ADMDs, at the 589 email level. 591 +-------+ +-------+ +-------+ 592 | ADMD1 | | ADMD3 | | ADMD4 | 593 | ----- | | ----- | | ----- | 594 | | +---------------------->| | | | 595 | User | | |-Edge--+--->|-User | 596 | | | | +---------+ +--->| | | | 597 | V | | | ADMD2 | | +-------+ +-------+ 598 | Edge--+---+ | ----- | | 599 | | | | | | 600 +-------+ +----|-Transit-+---+ 601 | | 602 +---------+ 604 Figure 4: ADMD Example 606 Edge networks can use proprietary email standards internally. 607 However the distinction between Transit network and Edge network 608 transfer services is primarily significant because it highlights the 609 need for concern over interaction and protection between independent 610 administrations. In particular this distinction calls for additional 611 care in assessing transitions of responsibility, as well as the 612 accountability and authorization relationships among participants in 613 email transfer. 615 The interactions between functional components within an ADMD are 616 subject to the policies of that domain. Policies can cover such 617 things as reliability, access control, accountability and even 618 content evaluation and modification. They can be implemented in 619 different functional components, according to the needs of the ADMD. 620 For example see [ID-spamops]. 622 User, Edge and Transit services can be offered by providers that 623 operate component services or sets of services. Further it is 624 possible for one ADMD to host services for other ADMDs. 626 Common ADMD examples are -- 628 Enterprise Service Providers: 630 Operating an organization's internal data and/or mail services. 632 Internet Service Providers: 634 Operating underlying data communication services that, in turn, 635 are used by one or more Relays and Users. It is not 636 necessarily their job to perform email functions, but they can, 637 instead, provide an environment in which those functions can be 638 performed. 640 Mail Service Providers: 642 Operating email services, such as for end-users, or mailing 643 lists. 645 Operational pragmatics often dictate that providers be involved in 646 detailed administration and enforcement issues, to help ensure the 647 health of the overall Internet Mail Service. This can include 648 operators of lower-level packet services. 650 3. Identities 652 Internet Mail uses three forms of identity: mailbox, domain name and 653 message-id. Each is required to be globally unique. 655 3.1. Mailbox 657 "A mailbox sends and receives mail. It is a conceptual entity 658 which does not necessarily pertain to file storage." [RFC2822] 660 A mailbox is specified as an Internet Mail address . It 661 has two distinct parts, divided by an at-sign ("@"). The right-hand 662 side is a globally interpreted domain name that is part of an ADMD. 663 Domain Names are discussed in Section 3.2. Formal Internet Mail 664 addressing syntax can support source routes, to indicate the path 665 through which a message should be sent. Although legal, the use of 666 source routes is not part of the modern Internet Mail service and it 667 is ignored in the rest of this document. 669 The portion to the left of the at-sign contains a string that is 670 globally opaque and is called the . It is to be 671 interpreted only by the entity specified by the address's right-hand 672 side domain name. All other entities MUST treat the local-part as a 673 uninterpreted literal string and MUST preserve all of its original 674 details. As such its public distribution is equivalent to sending a 675 Web browser "cookie" that is only interpreted upon being returned to 676 its originator. 678 3.1.1. Global Standards for Local-Part 680 It is common for sites to have local structuring conventions for the 681 left-hand side of an . This permits sub- 682 addressing, such as for distinguishing different discussion groups 683 used by the same participant. However it is worth stressing that 684 these conventions are strictly private to the user's organization and 685 MUST not be interpreted by any domain except the one listed in the 686 right-hand side of the addr-spec, and those specialized services 687 conforming to standardized conventions, as noted in the next 688 paragraph. 690 There are a few types of addresses that have an elaboration on basic 691 email addressing, with a standardized, global schema for the local- 692 part. These are conventions between originating end-systems and 693 Recipient Gateways, and they are invisible to the public email 694 transfer infrastructure. When an Originator is explicitly sending 695 via a Gateway out of the Internet, there are coding conventions for 696 the local-part, so that the Originator can formulate instructions for 697 the Gateway. Standardized examples of this are the telephone 698 numbering formats for VPIM [RFC3801], such as 699 "+16137637582@vpim.example.com", and iFax [RFC3192], such as 700 "FAX=+12027653000/T33S=1387@ifax.example.com". 702 3.1.2. Scope of Email Address Use 704 Email addresses are being used far beyond their original email 705 transfer and delivery role. In practical terms, email strings have 706 become a common form of user identity on the Internet. What is 707 essential, then, is to be clear about the nature and role of an 708 identity string in a particular context and to be clear about the 709 entity responsible for setting that string. 711 3.2. Domain Names 713 A domain name is a global reference to an Internet resource, such as 714 a host, a service or a network. A domain name usually maps to one or 715 more IP Addresses. Conceptually the name might encompass an entire 716 organization, a collection of machines integrated into a homogeneous 717 service, or only a single machine. A domain name can be administered 718 to refer to individual users, but this is not common practice. The 719 name is structured as a hierarchical sequence of sub-names, separated 720 by dots ("."), with the top of the hierarchy being on the right-end 721 of the sequence. Domain names are defined and operated through the 722 Domain Name Service (DNS) [RFC1034], [RFC1035], [RFC2181]. 724 When not part of a mailbox address, a domain name is used in Internet 725 Mail to refer to the ADMD or the host that took action upon the 726 message, such as providing the administrative scope for a message 727 identifier, or performing transfer processing. 729 3.3. Message Identifier 731 There are two standardized tags, for identifying messages: Message-ID 732 and ENVID. 734 3.3.1. Message-ID 736 The Message-ID is a user-level tag, primarily used for threading and 737 for eliminating duplicates. [RFC2822]. Any actor within the 738 originating ADMD might assign the Message-ID, although it is 739 typically created by an actor within the Originating ADMD.. The 740 recipient's ADMD is the intended consumer of the Message-ID, although 741 any actor along the transfer path might use it. Internet Mail 742 standards provide for a single Message-ID; however more than one is 743 sometimes assigned. 745 Like a mailbox address, a Message-ID has two distinct parts, divided 746 by an at-sign ("@"). The right-hand side is globally interpreted and 747 specifies the ADMD or host assigning the identifier. The left-hand 748 side contains a string that is globally opaque and serves to uniquely 749 identify the message within the domain referenced on the right-hand 750 side. The duration of uniqueness for the message identifier is 751 undefined. 753 When a message is revised in any way, the question of whether to 754 assign a new Message-ID requires a subjective assessment, deciding 755 whether the editorial content has been changed enough to constitute a 756 new message. [RFC2822] says "a message identifier pertains to 757 exactly one instantiation of a particular message; subsequent 758 revisions to the message each receive new message identifiers." 759 However real-world experience dictates some flexibility. An 760 impossible test is whether the recipient will consider the new 761 message to be equivalent to the old. For most components of Internet 762 Mail, there is no way to predict a specific recipient's preferences 763 on this matter. Both creating and failing to create a new Message-ID 764 have their downsides. 766 The best that can be offered, here, are some guidelines and examples: 768 * If a message is changed only in terms of form, such as 769 character-encoding, it clearly is still the same message. 771 * If a message has minor additions to the content, such as a 772 mailing list tag at the beginning of the RFC2822.Subject header 773 field, or some mailing list administrative information added to 774 the end of the primary body-part's text, then it probably is 775 still the same message. 777 * If a message has viruses deleted from it, it probably is still 778 the same message. 780 * If a message has offensive words deleted from it, then some 781 recipients will consider it the same message, but some will 782 not. 784 * If a message is translated into a different language, then some 785 recipients will consider it the same message, but some will 786 not. 788 The absence of objective, precise criteria for Message-ID re- 789 generation, along with the absence of strong protection associated 790 with the string, means that the presence of an ID can permit an 791 assessment that is marginally better than a heuristic, but the ID 792 certainly has no value on its own for strict formal reference or 793 comparison. Hence it is not appropriate to use the Message-ID for 794 any process that might be called "security". 796 3.3.2. ENVID 798 The ENVID (envelope identifier) is a tag that is primarily for use 799 within Delivery Status Notifications (DSN), so that the Bounce 800 Address (RFC2821.MailFrom) recipient can correlate the DSN with a 801 particular message. [RFC3461] The ENVID is therefore used from one 802 message posting, until the directly-resulting message deliveries. It 803 does not survive re-postings. 805 The format of an ENVID is free-form. Although its creator might 806 choose to impose structure on the string, none is imposed by Internet 807 standards. By implication, the scope of the string is defined by the 808 domain name of the Bounce Address. 810 4. Services and Standards 812 Internet Mail's architecture distinguishes among six basic types of 813 functional components, arranged to support a store-and-forward 814 service architecture. As shown in Figure 5 these types can have 815 multiple instances, some of which represent specialized sub-roles. 816 This section considers the activities and relationships among these 817 components, and the Internet Mail standards used among them. 819 1. Message 821 2. Mail User Agent (MUA) 823 + Originating MUA (oMUA) 825 + Receiving MUA (rMUA) 827 3. Message Submission Agent (MSA) 829 + Originator-focussed MSA functions (oMSA) 831 + MHS-focussed MSA functions (hMSA) 833 4. Message Transfer Agent (MTA) 835 5. Message Delivery Agent (MDA) 836 + Recipient-focused MDA functions (rMDA) 838 + MHS-focussed MDA functions (hMDA) 840 6. Message Store (MS) 842 + Originator MS (oMS) 844 - oMS on a remote server (soMS) 846 - oMS co-located with the oMUA (uoMS) 848 + Recipient MS (rms) 850 - rMS on a remote server (srM) 852 - rMS co-located with the rMUA (urMS) 854 This section describes each functional component for Internet Mail, 855 and the standards-based protocols that are associated with their 856 operation. 858 Software implementations of these architectural components often 859 compress them, such as having the same software do MSA, MTA and MDA 860 functions. However the requirements for each of these components of 861 the service are becoming more extensive. So their separation is 862 increasingly common. 864 NOTE: A discussion about any interesting system architecture is 865 often complicated by confusion between architecture versus 866 implementation. An architecture defines the conceptual 867 functions of a service, divided into discrete conceptual 868 modules. An implementation of that architecture can combine or 869 separate architectural components, as needed for a particular 870 operational environment. It is important not to confuse the 871 engineering decisions that are made to implement a product, 872 with the architectural abstractions used to define conceptual 873 functions. 875 The following figure shows function modules and the standardized 876 protocols used between them. Additional protocols and configurations 877 are possible. Boxes defined by asterisks (*) represent functions 878 that often are distributed among two or more systems. 880 +------+ +-------+ 881 ............+ oMUA |..............................| Disp | 882 . +--+-+-+ +-------+ 883 . local,imap}| |{smtp,submission ^ 884 . | | +---------+ | 885 . ******* | | .......................| Bounces | | 886 . * oMS *<-----+ | . +---------+ | 887 . ******* | . ***************** ^ | 888 . +------V-.---*------------+ * | | 889 . MSA | +-------+ * +------+ | * | | 890 . | | oMSA +--O-->| hMSA | | * | | 891 . | +-------+ * +--+---+ | * | | 892 . +------------*------+-----+ * | | 893 /+==========+\ * V {smtp * | | 894 || MESSAGE || * +------+ * /+===+===+\ | 895 ||----------|| MHS * | MTA | * || dsn || | 896 || Envelope || * +--+---+ * \+=======+/ | 897 || SMTP || * V {smtp * ^ ^ | 898 || Content || * +------+ * | | /+==+==+\ 899 || RFC2822 || * | MTA +----*-----+ | || mdn || 900 || MIME || * +--+---+ * | \+=====+/ 901 \+==========+/ * smtp}| {local * | | 902 MDA * | {lmtp * | | 903 . +------------+------V-----+ * | | 904 . | +------+ * +------+ | * | | 905 . | | | * | | +--*---------+ | 906 . | | rMDA |<--O---+ hMDA | | * | 907 . | | | * | | |<-*-------+ | 908 . | +-+----+ * +------+ | * | | 909 . +---+--+-----*------------+ * | | 910 . | | ***************** | | 911 . pop} +--+ +---+ | | 912 . imap} | | {local | | 913 . ******************V******** | | 914 . * | +------+ * rMS /+===+===+\ | 915 . * | | srMS | * || sieve || | 916 . * V +--+-+-+ * \+=======+/ | 917 . * +------+ pop} | | * ^ | 918 . * | urMS |<-------+ | * | | 919 . * +--+---+ imap} | * | | 920 . *************************** | | 921 . local}| +------+ |{pop,imap | | 922 . +->| |<------+ | | 923 ...........>| rMUA +---------------------------+ | 924 | +-----------------------------------+ 925 +------+ 927 Figure 5: Protocols and Services 929 4.1. Message Data 931 The purpose of the Mail Handling Service (MHS) is to exchange a 932 message object among participants. , [RFC2822] [RFC0822] Hence all of 933 its underlying mechanisms are merely in the service of getting that 934 message from its Originator to its Recipients. A message can be 935 explicitly labeled as to its nature. [RFC3458] 937 A message comprises a transit handling envelope and the message 938 content. The envelope contains information used by the MHS. The 939 content is divided into a structured header and the body. The header 940 comprises transit trace information and end-user structured fields. 941 The body may be unstructured simple lines of text, or it may be a 942 MIME tree of multi-media subordinate objects, called body-parts, or 943 attachments. [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], 944 [RFC2049]. 946 In addition, Internet Mail has a few conventions for special control 947 data -- 949 Delivery Status Notification (DSN): 951 A Delivery Status Notification (DSN) is a message that can be 952 generated by the MHS (MSA, MTA or MDA) and sent to the 953 RFC2821.MailFrom address. The mailbox for this is shown as 954 Bounces in Figure 5. DSNs provide information about message 955 transit, such as transmission errors or successful delivery. 956 [RFC3461] 958 Message Disposition Notification (MDN): 960 A Message Disposition Notification (MDN) is a message that 961 provides information about user-level, Recipient-side message 962 processing, such as indicating that the message has been 963 displayed [RFC3798] or the form of content that can be 964 supported. [RFC3297] It can be generated by an rMUA and is 965 sent to the Disposition-Notification-To address(es). The 966 mailbox for this is shown as Disp in Figure 5. 968 Message Filtering (SIEVE): 970 SIEVE is a scripting language that permits specifying 971 conditions for differential handling of mail, typically at the 972 time of delivery. [RFC3028] It can be conveyed in a variety of 973 ways, as a MIME part. Figure 5 shows a Sieve specification 974 going from the rMUA to the MDA. However filtering can be done 975 at many different points along the transit path and any one or 976 more of them might be subject to Sieve directives, especially 977 within a single ADMD. Hence the Figure shows only one 978 relationship, for (relative) simplicity. 980 4.1.1. Envelope 982 Internet Mail has a fragmented framework for transit-related 983 "handling" information. Information that is directly used by the MHS 984 is called the "envelope". It directs handling activities by the 985 transfer service as is carried in transfer service commands. That 986 is, The envelope exists in the transfer protocol SMTP [RFC2821]. 988 Trace information records handling activity and is recorded in the 989 message Header. 991 4.1.2. Header Fields 993 Header fields are attribute name/value pairs covering an extensible 994 range of email service, user content and user transaction meta- 995 information. The core set of header fields is defined in [RFC2822], 996 [RFC0822]. It is common to extend this set, for different 997 applications. Procedures for registering header fields are defined 998 in [RFC4021]. An extensive set of existing header field 999 registrations is provided in [RFC3864]. 1001 One danger with placing additional information in header fields is 1002 that Gateways often alter or delete them. 1004 4.1.3. Body 1006 The body of a message might simply be lines of ASCII text or it might 1007 be hierarchically structured into a composition of multi-media body- 1008 part attachments, using MIME. [RFC2045], [RFC2046], [RFC2047], 1009 [RFC4288], [RFC2049] MIME structures each body-part into a recursive 1010 set of MIME header field meta-data and MIME Content sections. 1012 4.1.4. Identity References in a Message 1014 For a message in transit, the core uses of identifiers combine into: 1016 +-----------------------+----------------+---------------------+ 1017 | Layer | Field | Set By | 1018 +-----------------------+----------------+---------------------+ 1019 | Message Body | MIME Header | Originator | 1020 | Message header fields | From | Originator | 1021 | | Sender | Source | 1022 | | Reply-To | Originator | 1023 | | To, CC, BCC | Originator | 1024 | | Message-ID | Source | 1025 | | Received | Source, Relay, Dest | 1026 | | Return-Path | MDA, from MailFrom | 1027 | | Resent-* | Mediator | 1028 | SMTP | HELO | Latest Relay Client | 1029 | | ENVID | Source | 1030 | | MailFrom | Source | 1031 | | RcptTo | Originator | 1032 | IP | Source Address | Latest Relay Client | 1033 +-----------------------+----------------+---------------------+ 1035 Layered Identities 1037 The most common address-related fields are: 1039 RFC2822.From Set by: Originator 1041 Names and addresses for author(s) of the message content are 1042 listed in the From field. 1044 RFC2822.Reply-To Set by: Originator 1046 If a message Recipient sends a reply message that would otherwise 1047 use the RFC2822.From field address(es) that are contained in the 1048 original message, then they are instead to use the address(es) in 1049 the RFC2822.Reply-To field. In other words this field is a direct 1050 override of the From field, for responses from Recipients. 1052 RFC2822.Sender Set by: Source 1054 This specifies the address responsible for submitting the message 1055 into the transfer service. For efficiency this field can be 1056 omitted if it contains the same address as RFC2822.From. However 1057 this does not mean there is no Sender specified. Rather it means 1058 that that header field is virtual and that the address in the From 1059 field MUST be used. 1061 Specification of the error return addresses -- the "Bounce" 1062 address, contained in RFC2821.MailFrom -- is made by the 1063 RFC2822.Sender. Typically the Bounce address is the same as the 1064 Sender address. However some usage scenarios require it to be 1065 different. 1067 RFC2822.To/.CC Set by: Originator 1069 These specify MUA Recipient addresses. However some or all of the 1070 addresses in these fields might not be present in the 1071 RFC2821.RcptTo commands, due to handling process that might 1072 transfer from the former to the latter. 1074 The distinction between To and CC is subjective. Generally a To 1075 addressee is considered primary and is expected to take action on 1076 the message. A CC addressee typically receives a copy only for 1077 their information. 1079 RFC2822.BCC Set by: Originator 1081 A message might be copied to an addressee whose participation is 1082 not to be disclosed to the RFC2822.To or RFC2822.CC Recipients 1083 and, usually, not to the other BCC Recipients. The BCC header 1084 field indicates a message copy to such a Recipient. 1086 Typically, the field lists no addresses or only lists the address 1087 of the Recipient receiving this copy. An MUA will typically make 1088 separate postings for TO and CC Recipients, versus BCC Recipients. 1089 The former will see no indication that any BCCs were sent, whereas 1090 the latter have a BCC field present. It might be empty, contain a 1091 comment, or contain one or more BCC addresses, depending upon the 1092 preferences of the Originator. 1094 RFC2821.HELO/.EHLO Set by: Source 1096 The MSA can specify its hosting domain identity for the SMTP HELO 1097 or EHLO command operation. 1099 RFC3461.ENVID Set by: Source 1101 The MSA can specify an opaque string, to be included in a DSN, as 1102 a means of assisting the Bounce address recipient in identifying 1103 the message that produced a DSN. 1105 RFC2821.MailFrom Set by: Source 1106 This is an end-to-end string that specifies an email address for 1107 receiving return control information, such as "bounces". The name 1108 of this field is misleading, because it is not required to specify 1109 either the author or the agent responsible for submitting the 1110 message. Rather, the agent responsible for submission specifies 1111 the RFC2821.MailFrom address. Ultimately the simple basis for 1112 deciding what address needs to be in the RFC2821.MailFrom is to 1113 determine what address needs to be informed about transmission- 1114 level problems (and, possibly, successes.) 1116 RFC2821.RcptTo Set by: Originator 1118 This specifies the MUA mailbox address of a recipient. The string 1119 might not be visible in the message content header. For example, 1120 the message destination address header fields, such as RFC2822.To, 1121 might specify a mailing list mailbox, while the RFC2821.RcptTo 1122 address specifies a member of that list. 1124 RFC2821.Received Set by: Source, Relay, Mediator, Dest 1126 This indicates trace information, including originating host, 1127 relays, Mediators, and MSA host domain names and/or IP Addresses. 1129 RFC2821.Return-Path Set by: Source 1131 The MDA records the RFC2821.MailFrom address into the 1132 RFC2822.Return-Path field. 1134 RFC2919.List-Id Set by: Mediator Originator 1136 This provides a globally unique mailing list naming framework that 1137 is independent of particular hosts. [RFC2919] 1139 The identifier is in the form of a domain name; however the string 1140 usually is constructed by combining the two parts of an email 1141 address and the result rarely is a true domain name, listed in the 1142 domain name service -- although it can be. 1144 RFC2369.List-* Set by: Mediator Originator 1146 [RFC2369] defines a collection of message header fields for use by 1147 mailing lists. In effect they supply list-specific parameters for 1148 common mailing list user operations. The identifiers for these 1149 operations are for the list, itself, and the user-as-subscriber. 1150 [RFC2369] 1152 RFC0791.SourceAddr Set by: The Client SMTP sending host immediately 1153 preceding the current receiving SMTP server. 1155 [RFC0791] defines the basic unit of data transfer for the 1156 Internet, the IP Datagram. It contains a "Source Address" field 1157 that specifies the IP Address for the host (interface) from which 1158 the datagram was sent. This information is set and provided by 1159 the IP layer, and is therefore independent of mail-level 1160 mechanisms. As such, it is often taken to be authoritative, 1161 although it is possible to provide false addresses. 1163 4.2. User-Level Services 1165 Interactions at the user level entail protocol exchanges, distinct 1166 from those that occur at lower layers of the Internet Mail 1167 architecture, which is above the Internet Transport layer. Because 1168 the motivation for email, and much of its use, is for interaction 1169 among humans, the nature and details of these protocol exchanges 1170 often are determined by the needs of human and group communication. 1171 In terms of efforts to specify behaviors, one effect of this is to 1172 require subjective guidelines, rather than strict rules, for some 1173 aspects of system behavior. Mailing Lists provide particularly 1174 salient examples of this. 1176 4.2.1. Mail User Agent (MUA) 1178 A Mail User Agent (MUA) works on behalf of end-users and end-user 1179 applications. It is their "representative" within the email service. 1181 The Origination-side MUA (oMUA) creates a message and performs 1182 initial "submission" into the transfer infrastructure, via a Mail 1183 Submission Agent (MSA). It can also perform any creation- and 1184 posting-time archival in its Message Store (oMS). An MUA's oMS will 1185 typically include a folder for messages under development (Drafts), a 1186 folder for messages waiting to be sent (Queued or Unsent) and a 1187 folder for messages that have been successfully posted for 1188 transmission (Sent). 1190 The Recipient-side MUA (rMUA) works on behalf of the end-user 1191 Recipient to process received mail. This includes generating user- 1192 level return control messages, displaying and disposing of the 1193 received message, and closing or expanding the user communication 1194 loop, by initiating replies and forwarding new messages. 1196 NOTE: Although not shown in Figure 5, an MUA can, itself, have a 1197 distributed implementation, such as a "thin" user interface 1198 module on a limited end-user device, with the bulk of the MUA 1199 functionality operated remotely on a more capable server. An 1200 example of such an architecture might use IMAP [RFC3501] for 1201 most of the interactions between an MUA client and an MUA 1202 server. A standardized approach for such scenarios is defined 1203 by [RFC4550]. 1205 A Mediator is special class of MUA. It performs message re-posting, 1206 as discussed in Section 2.1. 1208 Identity fields relevant to a typical end-user MUA include: 1210 RFC2822.From 1212 RFC2822.Reply-To 1214 RFC2822.Sender 1216 RFC2822.To, RFC2822.CC 1218 RFC2822.BCC 1220 4.2.2. Message Store (MS) 1222 An MUA can employ a long-term Message Store (MS). Figure 5 depicts 1223 an Origination-side Ms (oMS) and a Recipient-side MS (rMS). There is 1224 a rich set of choices for configuring a store, because any MS may 1225 comprise a distributed set of component stores. In Figure 5, the rMS 1226 demonstrates this by showing an rMS that is located on a remote 1227 server (srMS) and an rMS that is on the same machine as the MUA 1228 (urMS). The relationship between two message stores, themselves, can 1229 vary. 1231 As discussed in [RFC1733] the operational relationship among MSs can 1232 be -- 1234 Online: Only a remote MS is used, with messages being accessible 1235 only when the MUA is attached to the MS, and the MUA repeatedly 1236 fetches all or part of a message, from one session to the next. 1238 Offline: The MS is local to the user, and messages are 1239 completely moved from any remote store, rather than (also) 1240 being retained there. 1242 Disconnected: An rMS and a uMS are kept synchronized, for all or 1243 part of their contents, while there is a connection between 1244 them. While they are disconnected, mail can continue to arrive 1245 at the rMS and the user may continue to make changes to the 1246 uMS. Upon reconnection, the two stores are re-synchronized. 1248 4.3. MHS-Level Services 1250 4.3.1. Mail Submission Agent (MSA) 1252 A Mail Submission Agent (MSA) accepts the message submission from the 1253 oMUA and enforces the policies of the hosting ADMD and the 1254 requirements of Internet standards. An MSA represents an unusual 1255 functional dichotomy. A portion of its task is to represent MUA 1256 (uMSA) interests during message posting, to facilitate posting 1257 success, and another portion is to represent MHS (hMSA) interests. 1258 This is best modeled, as shown in Figure 5, with two sub-components, 1259 one for the oMUA (oMSA) and one for the MHS (hMSA) 1261 The hMSA's function is to take transit responsibility for a message 1262 that conforms to the relevant Internet standards and to local site 1263 policies. It rejects messages that are not in conformance. The 1264 oMSA's is to perform final message preparation for submission and to 1265 effect the transfer of responsibility to the MHS, via the hMSA. The 1266 amount of preparation will depend upon the local implementations. 1267 Examples of oMSA tasks could be to add header fields, such as Date: 1268 and Message-ID, to modify portions of the message from local 1269 notations to Internet standards, such as expanding an address to its 1270 formal RFC2822 representation. 1272 Historically, standards-based MUA/MSA interactions have used SMTP 1273 [RFC2821]. A recent alternative is SUBMISSION [RFC4409]. Although 1274 SUBMISSION derives from SMTP, it uses a separate TCP port and imposes 1275 distinct requirements, such as access authorization. 1277 Identities relevant to the MSA include: 1279 RFC2821.HELO/.EHLO 1280 RFC3461.ENVID 1282 RFC2821.MailFrom 1284 RFC2821.RcptTo 1286 RFC2821.Received 1288 4.3.2. Mail Transfer Agent (MTA) 1290 A Mail Transfer Agent (MTA) relays mail for one application-level 1291 "hop". It is like a packet-switch or IP router in that its job is to 1292 make routing assessments and to move the message closer to the 1293 Recipient(s). Relaying is performed by a sequence of MTAs, until the 1294 message reaches a destination MDA. Hence an MTA implements both 1295 client and server MTA functionality. It does not make changes to 1296 addresses in the envelope or reformulate the editorial content. 1297 Hence a change in data form, such as to the MIME Content-Transfer- 1298 Encoding, is within the purview of an MTA, whereas removal or 1299 replacement of body content is not. Also it can add trace 1300 information. Of course email objects are typically much larger than 1301 the payload of a packet or datagram, and the end-to-end latencies are 1302 typically much higher. 1304 Internet Mail primarily uses SMTP [RFC2821], [RFC0821] to effect 1305 point-to-point transfers between peer MTAs. Other transfer 1306 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1307 most network layer mechanisms, Internet Mail's SMTP supports a basic 1308 level of reliability, by virtue of providing for retransmission after 1309 a temporary transfer failure. Contrary to typical packet switches 1310 (and Instant Messaging services) Internet Mail MTAs typically store 1311 messages in a manner that allows recovery across service 1312 interruptions, such as host system shutdown. However the degree of 1313 such robustness and persistence by an MTA can be highly variable. 1315 The primary "routing" mechanism for Internet Mail is the DNS MX 1316 record [RFC1035], which specifies a host through which the queried 1317 domain can be reached. This presumes a public -- or at least a 1318 common -- backbone that permits any attached host to connect to any 1319 other. 1321 Identities relevant to the MTA include: 1323 RFC2821.HELO/.EHLO 1325 RFC3461.ENVID 1327 RFC2821.MailFrom 1329 RFC2821.RcptTo 1331 RFC2822.Received Set by: Relay Server 1333 4.3.3. Mail Delivery Agent (MDA) 1335 A Mail Delivery Agent (MDA) delivers email to the Recipient's 1336 mailbox. It can provide distinctive, address-based functionality, 1337 made possible by its detailed knowledge of the properties of the 1338 destination address. This knowledge might also be present elsewhere 1339 in the Recipient's ADMD, such as at an organizational border 1340 (Boundary) Relay. However it is required for the MDA, if only 1341 because the MDA must know where to deliver the message. 1343 As with an MSA, an MDA serves two roles, as depicted in Figure 5. 1344 Formal transfer of responsibility, called "delivery" is effected 1345 between the two components that embody these roles. The MHS portion 1346 (hMDA) primarily functions as a server SMTP engine. A common 1347 additional role is to re-direct the message to an alternative 1348 address, as specified by the recipient addressee's preferences. The 1349 job of the recipient portion of the MDA (rMDA) is to perform any 1350 delivery-actions are desired by the recipient. 1352 Using Internet protocols, delivery can be effected by a variety of 1353 standard protocols. When coupled with an internal local mechanism, 1354 SMTP [RFC2821] and LMTP [RFC2033] permit "push" delivery to the 1355 Recipient system, at the initiative of the upstream email service. 1356 POP [RFC1939] and IMAP [RFC3501] are used for "pull" delivery at the 1357 initiative of the Recipient system. POP and IMAP can also be used 1358 for repeated access to messages on a remote MS. 1360 Identities relevant to the MDA include: 1362 RFC2821.Return-Path Set by: Originator Source or Mediator Source 1364 The MDA records the RFC2821.MailFrom address into the 1365 RFC2822.Return-Path field. 1367 RFC2822.Received Set by: MDA server 1369 An MDA can record a Received header field to indicate trace 1370 information, including source host and receiving host domain 1371 names and/or IP Addresses. 1373 5. Mediators 1375 Basic email transfer from an Originator to the specified Recipients 1376 is accomplished by using an asynchronous, store-and-forward 1377 communication infrastructure, in a sequence of independent 1378 transmissions through some number of MTAs. A very different task is 1379 a User-level sequence of postings and deliveries, through Mediators. 1380 A Mediator forwards a message, through a re-posting process. The 1381 Mediator does share some functionality with basic MTA relaying, but 1382 it enjoys a degree of freedom with both addressing and content that 1383 is not available to MTAs. 1385 RFC2821.HELO/.EHLO Set by: Mediator Source 1387 RFC3461.ENVID Set by: Originator Source or Mediator Source 1389 RFC2821.MailFrom Set by: Originator Source or Mediator Source 1391 RFC2821.RcptTo Set by: Mediator Originator 1393 RFC2821.Received Set by: Mediator Dest 1395 The salient aspect of a Mediator, that distinguishes it from any 1396 other MUA creating an entirely new message, is that a Mediator 1397 preserves the integrity and tone of the original message, including 1398 the essential aspects of its origination information. The Mediator 1399 might also add commentary. 1401 Examples of MUA message creation that are NOT performed by Mediators 1402 include -- 1404 New message that forwards an existing message: 1406 This action rather curiously provides a basic template for a 1407 class of Mediators. However for its typical occurrence it is 1408 not itself an example of a Mediator. The new message is viewed 1409 as being from the Agent doing the forwarding, rather than being 1410 from the original Originator. 1412 A new message encapsulates the original message and is seen as 1413 strictly "from" the Mediator. The Mediator might add 1414 commentary and certainly has the opportunity to modify the 1415 original message content. The forwarded message is therefore 1416 independent of the original message exchange and creates a new 1417 message dialogue. However the final Recipient sees the 1418 contained message as from the original Originator. 1420 Reply: 1422 When a Recipient formulates a response back to the original 1423 message's author, the new message is not typically viewed as 1424 being a "forwarding" of the original. Its focus is the new 1425 content, although it might contain all or part of the material 1426 in the original message. Therefore the earlier material is 1427 merely contextual and secondary. 1429 Annotation: 1431 The integrity of the original message is usually preserved, but 1432 one or more comments about the message are added in a manner 1433 that distinguishes commentary from original text. The tone of 1434 the new message is that it is primarily commentary from a new 1435 Originator, similar to a Reply. 1437 The remainder of this section describes common examples of Mediators. 1439 5.1. Aliasing 1441 Aliasing is a simple re-addressing facility that is available in most 1442 MDA implementations. It is performed just before placing a message 1443 into the specified Recipient's mailbox. Instead the message is 1444 submitted back to the transfer service, for delivery to one or more 1445 alternate addresses. Although typically implemented as part of an 1446 MDA, this facility is strictly a Recipient user function. It 1447 resubmits the message, replacing the envelope address, on behalf of 1448 the mailbox address that was listed in the envelope. 1450 What is most distinctive about this forwarding mechanism is how 1451 closely it compares to normal MTA store-and-forward Relaying. Its 1452 only interesting difference is that it changes the RFC2821.RcptTo 1453 value. Having the change be this small makes it easy to view 1454 aliasing as a part of the lower-level mail relaying activity. 1455 However the small change has a large semantic impact: The designated 1456 recipient has chosen a new recipient. Hence that original recipient 1457 SHOULD become responsible for any handling issues. This change would 1458 be reflected by replacing the message's RFC2821.MailFrom address to 1459 be one within the scope of the ADMD doing the aliasing. 1461 An MDA that is re-posting a message to an alias typically changes 1462 only envelope information: 1464 RFC2822.To/.CC/.BCC Set by: Originator 1466 These retain their original addresses. 1468 RFC2821.RcptTo Set by: Mediator Originator 1470 This field contains an alias address. 1472 RFC2821.MailFrom Set by: Originator Source or Mediator Source 1474 The agent responsible for submission to an alias address will 1475 often retain the original address to receive handling Bounces. 1476 The benefit of retaining the original MailFrom value is to 1477 ensure that the origination-side agent knows that there has 1478 been a delivery problem. On the other hand, the responsibility 1479 for the problem usually lies with the Recipient, since the 1480 Alias mechanism is strictly under the Recipient's control. 1482 RFC2821.Received Set by: Mediator Dest 1484 The agent can record Received information, to indicate the 1485 delivery to the original address and submission to the alias 1486 address. The trace of Received header fields can therefore 1487 include everything from original posting through final delivery 1488 to a final delivery. 1490 5.2. Re-Sending 1492 Also called Re-Directing, Re-Sending differs from Forwarding by 1493 virtue of having the Mediator "splice" a message's addressing 1494 information, to connect the Originator of the original message and 1495 the Recipient of the new message. This permits them to have direct 1496 exchange, using their normal MUA Reply functions. Hence the new 1497 Recipient sees the message as being From the original Originator, 1498 even if the Mediator adds commentary. 1500 Identities specified in a resent message include 1502 RFC2822.From Set by: original Originator 1504 Names and email addresses for the original author(s) of the 1505 message content are retained. The free-form (display-name) 1506 portion of the address might be modified to provide informal 1507 reference to the agent responsible for the redirection. 1509 RFC2822.Reply-To Set by: original Originator 1511 If this field is present in the original message, it is 1512 retained in the Resent message. 1514 RFC2822.Sender Set by: Originator Source or Mediator Source. 1516 RFC2822.To/.CC/.BCC Set by: original Originator 1518 These specify the original message Recipients. 1520 RFC2822.Resent-From Set by: Mediator Originator 1522 The address of the original Recipient who is redirecting the 1523 message. Otherwise the same rules apply for the Resent-From 1524 field as for an original RFC2822.From field. 1526 RFC2822.Resent-Sender Set by: Mediator Source 1528 The address of the agent responsible for re-submitting the 1529 message. As with RFC2822.Sender, this field is often omitted 1530 when it would merely contain the same address as 1531 RFC2822.Resent-From. 1533 RFC2822.Resent-To/-CC/-BCC: Set by: Mediator Originator 1535 The addresses of the new Recipients who will now be able to 1536 reply to the original author. 1538 RFC2821.MailFrom Set by: Mediator Source 1540 The agent responsible for re-submission (RFC2822.Resent-Sender) 1541 is also responsible for specifying the new MailFrom address. 1543 RFC2821.RcptTo Set by: Mediator Originator 1545 This will contain the address of a new Recipient. 1547 RFC2822.Received Set by: Mediator Dest 1549 When resending a message the submission agent can record a 1550 Received header field, to indicate the transition from original 1551 posting to resubmission. 1553 5.3. Mailing Lists 1555 Mailing lists have explicit email addresses and they re-post messages 1556 to a list of subscribed members. The Mailing List Actor performs a 1557 task that can be viewed as an elaboration of the Re-Director role. 1558 In addition to sending the new message to a potentially large number 1559 of new Recipients, the Mediator can modify content, such as deleting 1560 attachments, formatting conversion, and adding list-specific 1561 comments. In addition, archiving list messages is common. Still the 1562 message retains characteristics of being "from" the original 1563 Originator. 1565 Identities relevant to a mailing list processor, when submitting a 1566 message, include: 1568 RFC2919.List-Id Set by: Mediator Originator 1570 RFC2369.List-* Set by: Mediator Originator 1572 RFC2822.From Set by: original Originator 1574 Names and email addresses for the original author(s) of the 1575 message content are specified -- or, rather, retained. 1577 RFC2822.Reply-To Set by: original Originator or Mediator 1578 Originator 1580 RFC2822.Sender Set by: Originator Source or Mediator Source 1582 This will usually specify the address of the agent responsible 1583 for mailing list operations. However some mailing lists 1584 operate in a manner very similar to a simple MTA Relay, so that 1585 they preserve as much of the original handling information as 1586 possible, including the original RFC2822.Sender field. 1588 RFC2822.To/.CC Set by: original Originator 1590 These usually contain the original list of Recipient addresses. 1592 RFC2821.MailFrom Set by: Originator Source or Mediator Source 1594 This can contain the original address to be notified of 1595 transmission issues, or the mailing list agent can set it to 1596 contain a new Notification address. Typically the value is set 1597 to a new address, so that mailing list members and posters are 1598 not burdened with transmission-related Bounces. 1600 RFC2821.RcptTo Set by: Mediator Originator 1602 This contains the address of a mailing list member. 1604 RFC2821.Received Set by: Mediator Dest 1606 A Mailing List Agent can record a Received header field, to 1607 indicate the transition from original posting to mailing list 1608 forwarding. The Agent can choose to have the message retain 1609 the original set of Received header fields or can choose to 1610 remove them. In the latter case it can ensure that the 1611 original Received header fields are otherwise available, to 1612 ensure later accountability and diagnostic access to them. 1614 5.4. Gateways 1616 A Gateway performs the basic routing and transfer work of message 1617 relaying, but it also may make any message or address modifications 1618 that are needed to send the message into a messaging environment that 1619 operates according to different standards or potentially incompatible 1620 policies. When a Gateway connects two differing messaging services, 1621 its role is easy to identify and understand. When it connects 1622 environments that have technical similarity, but can have significant 1623 administrative differences, it is easy to think that a Gateway is 1624 merely an MTA. 1626 The critical distinction between an MTA and a Gateway is that the 1627 latter transforms addresses and/or message content, in order to map 1628 between the standards of two, different messaging services. In 1629 virtually all cases, this mapping process results in some degree of 1630 semantic loss. The challenge of Gateway design is to minimize this 1631 loss. 1633 A Gateway can set any identity field available to a regular MUA. 1634 Identities typically relevant to Gateways include: 1636 RFC2822.From Set by: original Originator 1638 Names and email addresses for the original author(s) of the 1639 message content are retained. As for all original addressing 1640 information in the message, the Gateway can translate addresses 1641 in whatever way will allow them continue to be useful in the 1642 target environment. 1644 RFC2822.Reply-To Set by: original Originator 1646 The Gateway SHOULD retain this information, if it is originally 1647 present. The ability to perform a successful reply by a 1648 Gatewayed Recipient is a typical test of Gateway functionality. 1650 RFC2822.Sender Set by: Originator Source or Mediator Source 1652 This can retain the original value or can be set to a new 1653 address. 1655 RFC2822.To/.CC/.BCC Set by: original Recipient 1657 These usually retain their original addresses. 1659 RFC2821.MailFrom Set by: Originator Source or Mediator Source 1661 The agent responsible for gatewaying the message can choose to 1662 specify a new address to receive handling notices. 1664 RFC2822.Received Set by: Mediator Dest 1666 The Gateway can record a Received header field, to indicate the 1667 transition from original posting to the new messaging 1668 environment. 1670 5.5. Boundary Filter 1672 Organizations often enforce security boundaries by subjecting 1673 messages to analysis, for conformance with the organization's safety 1674 policies. An example is detection of content classed as spam or a 1675 virus. A Filter might alter the content, to render it safe, such as 1676 by removing content deemed unacceptable. Typically these actions 1677 will result in the addition of content that records the actions. 1679 6. Considerations 1681 6.1. Security Considerations 1683 This document does not specify any new Internet Mail functionality. 1684 Consequently it is not intended to introduce any security 1685 considerations. 1687 However its discussion of the roles and responsibilities for 1688 different mail service modules, and the information they create, 1689 highlights the considerable degree to which security issues are 1690 present when implementing any component of the Internet Mail service. 1691 In addition, email transfer protocols can operate over authenticated 1692 and/or encrypted links, and message content or authorship can be 1693 authenticated or encrypted. 1695 6.2. IANA Considerations 1697 This document has no actions for IANA. 1699 7. References 1701 7.1. Normative 1703 [RFC0791] Postel, J., "Internet Protocol", 1981 September. 1705 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 1706 RFC 821, August 1982. 1708 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1709 text messages", STD 11, RFC 822, August 1982. 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 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1721 October 1996. 1723 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1724 Extensions (MIME) Part One: Format of Internet Message 1725 Bodies", RFC 2045, November 1996. 1727 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1728 Extensions (MIME) Part Two: Media Types", RFC 2046, 1729 November 1996. 1731 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1732 Part Three: Message Header Extensions for Non-ASCII Text", 1733 RFC 2047, November 1996. 1735 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1736 Extensions (MIME) Part Five: Conformance Criteria and 1737 Examples", RFC 2049, November 1996. 1739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1740 Requirement Levels", BCP 14, RFC 2119, March 1997. 1742 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1743 Specification", RFC 2181, July 1997. 1745 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1746 for Core Mail List Commands and their Transport through 1747 Message Header Fields", RFC 2369, July 1998. 1749 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1751 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1752 Addresses", RFC 2645, August 1999. 1754 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1755 April 2001. 1757 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1758 April 2001. 1760 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1761 and Namespace for the Identification of Mailing Lists", 1762 RFC 2919, March 2001. 1764 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 1765 RFC 3028, January 2001. 1767 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet 1768 Mail", RFC 2304, October 2001. 1770 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 1771 Negotiation for Messaging Services based on Email", 1772 RFC 3297, July 2002. 1774 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1775 Context for Internet Mail", RFC 3458, January 2003. 1777 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1778 Extension for Delivery Status Notifications (DSNs)", 1779 RFC 3461, January 2003. 1781 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1782 4rev1", RFC 3501, March 2003. 1784 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1785 Notification", RFC 3798, May 2004. 1787 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1788 Procedures for Message Header Fields", RFC 3864, 1789 September 2004. 1791 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 1792 Header Fields", RFC 4021, March 2005. 1794 [RFC4288] Freed, N., Klensin, J., and J. Postel, "Media Type 1795 Specifications and Registration Procedures", BCP 13, 1796 RFC 4288, December 2005. 1798 [RFC4289] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1799 Internet Mail Extensions (MIME) Part Four: Registration 1800 Procedures", BCP 13, RFC 4289, December 2005. 1802 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1803 RFC 4409, April 2006. 1805 [RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support 1806 Diverse Service Environments (Lemonade) Profile", 1807 June 2006. 1809 7.2. Descriptive 1811 [ID-spamops] 1812 Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 1813 E. Allman, "Email Submission Between Independent 1814 Networks", draft-spamops-00 (work in progress), 1815 March 2004. 1817 [RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4", 1818 December 1994. 1820 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 1821 RFC 1767, March 1995. 1823 [RFC3801] Vaudreuil, G. and G. Parsons, "", RFC 3801, June 2004. 1825 [RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for 1826 Internet Mail: FFPIM", December 2005. 1828 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 1829 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1830 ACM SIGCOMM, 2002. 1832 Appendix A. Acknowledgements 1834 This work derives from a section in draft-hutzler-spamops. 1835 [ID-spamops] Discussion of the Source actor role was greatly 1836 clarified during discussions in the IETF's Marid working group. 1838 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1839 insight on the framework and details of the original drafts. 1841 Later reviews and suggestions were provided by Eric Allman, Nathaniel 1842 Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Willemien 1843 Hoogendoorn, Tony Finch, Ned Freed, Eric Hall, Brad Knowles, John 1844 Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, 1845 Alexey Melnikov, der Mouse, S. Moonesamy, Chris Newman, Daryl Odnert, 1846 Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, 1847 Greg Vaudreuil. 1849 Diligent proof-reading was performed by Bruce Lilly. 1851 Author's Address 1853 Dave Crocker 1854 Brandenburg InternetWorking 1855 675 Spruce Drive 1856 Sunnyvale, CA 94086 1857 USA 1859 Phone: +1.408.246.8253 1860 Email: dcrocker@bbiw.net 1862 Full Copyright Statement 1864 Copyright (C) The IETF Trust (2007). 1866 This document is subject to the rights, licenses and restrictions 1867 contained in BCP 78, and except as set forth therein, the authors 1868 retain all their rights. 1870 This document and the information contained herein are provided on an 1871 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1872 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1873 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1874 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1875 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1876 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1878 Intellectual Property 1880 The IETF takes no position regarding the validity or scope of any 1881 Intellectual Property Rights or other rights that might be claimed to 1882 pertain to the implementation or use of the technology described in 1883 this document or the extent to which any license under such rights 1884 might or might not be available; nor does it represent that it has 1885 made any independent effort to identify any such rights. Information 1886 on the procedures with respect to rights in RFC documents can be 1887 found in BCP 78 and BCP 79. 1889 Copies of IPR disclosures made to the IETF Secretariat and any 1890 assurances of licenses to be made available, or the result of an 1891 attempt made to obtain a general license or permission for the use of 1892 such proprietary rights by implementers or users of this 1893 specification can be obtained from the IETF on-line IPR repository at 1894 http://www.ietf.org/ipr. 1896 The IETF invites any interested party to bring to its attention any 1897 copyrights, patents or patent applications, or other proprietary 1898 rights that may cover technology that may be required to implement 1899 this standard. Please address the information to the IETF at 1900 ietf-ipr@ietf.org. 1902 Acknowledgment 1904 Funding for the RFC Editor function is provided by the IETF 1905 Administrative Support Activity (IASA).