idnits 2.17.00 (12 Aug 2021) /tmp/idnits53968/draft-crocker-email-arch-07.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 1933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1944. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1951. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1957. 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 6, 2007) is 5493 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 1881, but not defined == Missing Reference: 'RFC1767' is mentioned on line 1878, but not defined == Missing Reference: 'RFC4142' is mentioned on line 1883, but not defined == Missing Reference: 'Tussle' is mentioned on line 1886, but not defined == Missing Reference: 'ID-spamops' is mentioned on line 1893, but not defined == Missing Reference: 'RFC1733' is mentioned on line 1875, 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 6, 2007 5 Expires: November 7, 2007 7 Internet Mail Architecture 8 draft-crocker-email-arch-07 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 7, 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 . . . . . . . . . . . . . . . . . . . 6 67 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.2. Mail Handling Service (MHS) Actors . . . . . . . . . . . . 10 69 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 13 70 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 3.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 16 73 3.3. Message Identifier . . . . . . . . . . . . . . . . . . . . 17 74 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 18 75 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 21 76 4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 26 77 4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 28 78 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 31 79 5.1. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 32 80 5.2. Re-Sending . . . . . . . . . . . . . . . . . . . . . . . . 34 81 5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 36 82 5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 37 83 5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 39 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 87 8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 39 88 8.2. Descriptive . . . . . . . . . . . . . . . . . . . . . . . 42 89 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 42 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 91 Intellectual Property and Copyright Statements . . . . . . . . . . 44 93 1. Introduction 95 Over its thirty-five year history Internet Mail has undergone 96 significant changes in scale and complexity, as it has become a 97 global infrastructure service. The changes have been evolutionary, 98 rather than revolutionary, reflecting a strong desire to preserve its 99 installed base of users and utility. Today, Internet Mail is marked 100 by many independent operators, many different components for 101 providing service to users and many other components for performing 102 message transfer. 104 Public collaboration on email technical, operations and policy 105 activities, including those responding to the challenges of email 106 abuse, has brought in a much wider range of participants than email's 107 technical community originally had. In order to do work on a large, 108 complex system, they need to share the same view of how it is put 109 together, as well as what terms to use to refer to the pieces and 110 their activities. Otherwise, it is difficult to know exactly what 111 another participant means. It is these differences in each person's 112 perspective that motivates this document, to describe the realities 113 of the current system. Internet mail is the subject of ongoing 114 technical, operations and policy work, and the discussions often are 115 hindered by different models of email service design and different 116 meanings for the same terms. This architecture document seeks to 117 facilitate clearer and more efficient technical, operations and 118 policy exchanges about email. 120 This document offers an enhanced Internet Mail architecture to 121 reflect the current service. In particular it: 123 * Documents refinements to the email model 125 * Clarifies functional roles for the architectural components 127 * Clarifies identity-related issues, across the email service 129 * Defines terminology for architectural components and their 130 interactions 132 1.1. Background 134 The first standardized architecture for networked email specified a 135 simple split between the user world, in the form of Mail User Agents 136 (MUA), and the transmission world, in the form of the Mail Handling 137 Service (MHS) composed of Mail Transfer Agents (MTA). The MHS is 138 responsible for accepting a message from one User and delivering it 139 to one or more others, creating a virtual MUA-to-MUA exchange 140 environment. 142 As shown in Figure 1 this defines two logical "layers" of 143 interoperability. One is directly between Users. The other is 144 between the neighboring components, along the transfer path. In 145 addition, there is interoperability between the layers, first when a 146 message is posted from the User to the MHS and later when it is 147 delivered from the MHS to the User. 149 +--------+ 150 +---------------->| User | 151 | +--------+ 152 | ^ 153 +--------+ | +--------+ . 154 | User +--+--------->| User | . 155 +--------+ | +--------+ . 156 . | ^ . 157 . | +--------+ . . 158 . +-->| User | . . 159 . +--------+ . . 160 . ^ . . 161 . . . . 162 V . . . 163 +---+----------------+------+------+---+ 164 | . . . . | 165 | +...............>+ . . | 166 | . . . | 167 | +......................>+ . | 168 | . . | 169 | +.............................>+ | 170 | | 171 | Mail Handling Service (MHS) | 172 +--------------------------------------+ 174 Figure 1: Basic Internet Mail Service Model 176 As it has evolved, the operational service has sub-divided each of 177 these layers into more specialized modules. Core aspects of the 178 service, such as mailbox addressing and message format style, have 179 remained remarkably constant. So the original distinction between 180 user-level concerns and transfer-level concerns is retained, but with 181 an elaboration to each level of the architecture. The term "Internet 182 Mail" is used to refer to the entire collection of user and transfer 183 components and services. 185 For Internet Mail the term "end-to-end" usually refers to a single 186 posting and the set of deliveries directly resulting from its single 187 transiting of the MHS. A common exception is with group dialogue 188 that is mediated via a mailing list, so that two postings occur 189 before intended recipients receive an originator's message, as 190 discussed in Section 2.1.3. In fact some uses of email consider the 191 entire email service -- including Originator and Recipient -- as a 192 subordinate component. For these services "end-to-end" refers to 193 points outside of the email service. Examples are voicemail over 194 email [RFC3801], EDI over email [RFC1767] and facsimile over email. 195 [RFC4142] 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 to 254 the IETF-SMTP mailing list . 256 Changes: 258 Added text to explain utility of having an architecture document. 260 Added text explaining benefit of the ADMD construct. 262 Added commentary on List-ID. 264 Moved Bounce out of MHS in figure. 266 Moved "generic" Identity field case-analysis text into common area 267 after Table 1, reserving per-role text for per-role peculiarities. 269 Extensive word-smithing and cleanup. 271 2. Responsible Actor Roles 273 Internet Mail is a highly distributed service, with a variety of 274 actors serving different roles. These divide into 3 basic types: 276 * User 277 * Mail Handling Service (MHS) 279 * ADministrative Management Domain (ADMD) 281 Although related to a technical architecture, the focus on Actors 282 concerns participant responsibilities, rather than on functionality 283 of modules. Hence the labels used are different than for classic 284 email architecture diagrams. 286 2.1. User Actors 288 Users are the sources and sinks of messages. They can be humans or 289 processes. They can have an exchange that iterates and they can 290 expand or contract the set of users participating in a set of 291 exchanges. In Internet Mail there are three types of user-level 292 Actors: 294 * Originators 296 * Recipients 298 * Mediators 300 From the User-level perspective all mail transfer activities are 301 performed by a monolithic Mail Handling Service (MHS), even though 302 the actual service can be provided by many independent organizations. 303 Users are customers of this unified service. 305 The following depicts the flow of messages among Actors: 307 +------------+ 308 | |<---------------------------+ 309 | Originator |<----------------+ | 310 | |<----+ | | 311 +-+---+----+-+ | | | 312 | | | | | | 313 | | V | | | 314 | | +---------+-+ | | 315 | | | Recipient | | | 316 | | +-----------+ | | 317 | | | | 318 | | +--------+ | | 319 | | | | | | 320 | V V | | | 321 | +-----------+ +-+-------+-+ | 322 | | Mediator +--->| Recipient | | 323 | +-----------+ +-----------+ | 324 | | 325 | +-----------------------------+ | 326 | | +----------+ | | 327 | | | | | | 328 V V V | | | 329 +-----------+ +-----------+ +---+-+-+---+ 330 | Mediator +--->| Mediator +--->| Recipient | 331 +-----------+ +-----------+ +-----------+ 333 Figure 2: Relationships Among User Actors 335 2.1.1. Originator 337 Also called "Author", this is the user-level participant responsible 338 for creating original content and requesting its transmission. The 339 MHS operates to send and deliver mail among Originators and 340 Recipients. As described below, the MHS has a "Source" role that 341 correlates with the user-level Author role. 343 2.1.2. Recipient 345 The Recipient is a consumer of delivered content. As described 346 below, the MHS has a "Dest[ination]" role that correlates with the 347 user-level Recipient role. 349 A Recipient can close the user-level communication loop by creating 350 and submitting a new message that replies to an Originator. An 351 example of an automated form of reply is the Message Disposition 352 Notification, which informs the Originator about the Recipient's 353 handling of the message. (See Section 4.1.) 355 2.1.3. Mediator 357 A Mediator receives, aggregates, reformulates and redistributes 358 messages as part of a potentially-protracted, higher-level exchange 359 among Users. Example Mediators include group dialogue, such as 360 collaboration via mailing lists, and organizational message flow, as 361 occurs with a purchase approval process. Note that it is easy to 362 confuse this user-level activity with the underlying MHS transfer 363 exchanges. However they serve very different purposes and operate in 364 very different ways. Mediators are considered extensively in 365 Section 5. 367 When mail is delivered to a receiving mediator specified in the 368 RFC2821.RcptTo command, the MHS handles it the same way as for any 369 other Recipient. That is, the MHS only sees posting and delivery 370 sources and sinks and does not see (later) re-posting as a 371 continuation of a process. Hence when submitting messages, the 372 Mediator is an Originator. 374 The distinctive aspects of a Mediator are, therefore, above the MHS. 375 A Mediator preserves the Originator information of the message it 376 reformulates, but may make meaningful changes to the content. Hence 377 the MHS sees a new message, but Users receive a message that is 378 interpreted as primarily being from -- or, at least, initiated by -- 379 the author of the original message. The role of a Mediator permits 380 distinct, active creativity, rather than being limited to the more 381 constrained job of merely connecting together other participants. 382 Hence it is really the Mediator that is responsible for the new 383 message. 385 A Mediator's task can be complex and contingent, such as by modifying 386 and adding content or regulating which users are allowed to 387 participate and when. The popular example of this role is a group 388 mailing list. A sequence of Mediators may even perform a series of 389 formal steps, such as reviewing, modifying and approving a purchase 390 request. 392 Because a Mediator originates messages, it can also receive replies. 393 So a Mediator really is a full-fledged User. 395 Gateway: A Gateway is a particularly interesting form of Mediator. 396 It is a hybrid of User and Relay that interconnects heterogeneous 397 mail services. Its goal is to emulate a Relay, and a detailed 398 discussion is in Section 2.2.4. 400 2.2. Mail Handling Service (MHS) Actors 402 The Mail Handling Service (MHS) has the task of performing a single, 403 end-to-end transfer on behalf of the Originator and reaching the 404 Recipient address(es) specified in the original RFC2821.RcptTo 405 commands. Mediated or protracted, iterative exchanges, such as those 406 used for collaboration over time, are part of the User-level service, 407 and are not part of this transfer-level Handling Service. 409 The following depicts the relationships among transfer participants 410 in Internet Mail. It shows the Source as distinct from the 411 Originator, and Dest[ination] as distinct from Recipient, although it 412 is common for each pair to be the same actor. Transfers typically 413 entail one or more Relays. However direct delivery from the Source 414 to Destination is possible. For intra-organization mail services, it 415 is common to have only one Relay. 417 +------------+ +-----------+ 418 | Originator | +--------+ | Recipient | 419 +-----+------+ ..>| Bounce | +-----------+ 420 | . +--------+ ^ 421 | . ^ | 422 /+=================================================+\ 423 || | . | Mail Handling | || 424 || | . | Service (MHS) | || 425 V . | | 426 +---------+ . | +----+----+ 427 | | . | | | 428 | Source +.... +-<-------------+ Dest | 429 | | | | | 430 +----+----+ ^ +---------+ 431 | | ^ 432 | +-------------+-----------------+ | 433 V | | | | 434 +-------+-+ +-+-------+ +-+--+----+ 435 | Relay +-->...-->| Relay +------>| Relay | 436 +---------+ +----+----+ +---------+ 437 | 438 V 439 +---------+ 440 | Gateway +-->... 441 +---------+ 443 Figure 3: Relationships Among MHS Actors 445 2.2.1. Source 447 The Source role is responsible for ensuring that a message is valid 448 for posting and then submitting it to a Relay. Validity includes 449 conformance with Internet Mail standards, as well as with local 450 operational policies. The Source can simply review the message for 451 conformance and reject it if there are errors, or it can create some 452 or all of the necessary information. 454 The Source operates with dual "allegiance". It serves the Originator 455 and often it is the same entity. However its role in assuring 456 validity means that it MUST also represent the local operator of the 457 MHS, that is, the local ADministrative Management Domain (ADMD). 459 The Source also has the responsibility for any post-submission, 460 Originator-related administrative tasks associated with message 461 transmission and delivery. Notably this pertains to error and 462 delivery notices. Hence Source is best held accountable for the 463 message content, even when they did not create any or most of it. 465 2.2.2. Bounce Handler 467 The Bounce Handler processes service notifications that are generated 468 by the MHS, as a result of its efforts to transfer or deliver the 469 message. Notices can be about failures or completions and are sent 470 to an address that is specified by the Source. This Bounce handling 471 address (also known as a Return address) might have no visible 472 characteristics in common with the address of the Originator or 473 Source. 475 NOTE: 477 The choice of the label "Bounce" is unfortunate, due to its 478 negative implication and narrow focus. However it is the most 479 popular term for the address. 481 2.2.3. Relay 483 A mail Relay performs email transfer-service routing and store-and- 484 forward by (re-)transmitting the message on towards its Recipient(s). 485 A Relay can add information to the envelope, such as with trace 486 information. However it does not modify existing envelope 487 information or the message content semantics. It can modify message 488 content syntax, such as a change from text to binary transfer- 489 encoding form, only as required to meet the capabilities of the next 490 hop in the MHS. 492 A set of Relays composes a Mail Handling Service (MHS) network. This 493 is above any underlying packet-switching network that they might be 494 using and below any gateways or other user-level Mediators. 496 In other words, interesting email scenarios can involve three 497 distinct architectural layers of store-and-forward service: 499 * User Mediators 501 * MHS Relays 503 * Packet Switches 505 with the bottom-most usually being the Internet's IP service. The 506 most basic email scenarios involve Relays and Switches. 508 Aborting a message transfer results in having the Relay become an 509 Originator and send an error message to the Bounce address. The 510 potential for looping is avoided by having this message, itself, 511 contain no Bounce address. 513 2.2.4. Gateway 515 A Gateway is a hybrid form of User and Relay that interconnects 516 heterogeneous mail services. Its purpose is simply to emulate a 517 Relay and the closer it comes to this, the better. However it 518 operates at the User level, because it MUST be able to modify message 519 content. 521 Differences between mail services can be as small as minor syntax 522 variations, but usually encompass significant, semantic distinctions. 523 One difference could have the concept of an email address be a 524 hierarchical, machine-specific address, versus having it be a flat, 525 global name space. Another difference could be between text-only 526 content, versus multi-media. Hence the Relay function in a Gateway 527 offers significant design challenges, to make the result be as 528 seamless as possible. The most significant challenge is in ensuring 529 the user-to-user functionality that matches syntax and semantics of 530 independent email standards suites. 532 The basic test of a Gateway's adequacy is, of course, whether an 533 Originator on one side of a Gateway can send a useful message to a 534 Recipient on the other side, without requiring changes to any of the 535 components in the Originator's or Recipient's mail services, other 536 than adding the Gateway. To each of these otherwise independent 537 services, the Gateway will appear to be a "native" participant. 538 However the ultimate test of a Gateway's adequacy is whether the 539 Originator and Recipient can sustain a dialogue. In particular can a 540 Recipient's MUA automatically formulate a valid Reply that will reach 541 the initial Originator? 543 2.3. Administrative Actors 545 Actors often will are associated with different organizations, each 546 with its own administrative authority. This operational 547 independence, coupled with the need for interaction between groups, 548 provides the motivation for distinguishing among ADministrative 549 Management Domains (ADMD). Each ADMD can have vastly different 550 operating policies and trust-based decision-making. An obvious 551 example is the distinction between mail that is exchanged within a 552 single organization, versus mail that is exchanged between 553 independent organizations. The rules for handling these two types of 554 traffic tend to be quite different. That difference requires 555 defining the boundaries of each, and this requires the ADMD 556 construct. 558 Operation of Internet Mail services is apportioned to different 559 providers (or operators). Each can be an independent ADMD. This 560 independence of administrative decision-making defines boundaries 561 that distinguish different portions of the Internet Mail service. 562 Examples include an end-user operating their desktop client, a 563 department operating a local Relay, an IT department operating an 564 enterprise Relay and an ISP operating a public shared email service. 565 These can be configured into many combinations of administrative and 566 operational relationships, with each ADMD potentially having a 567 complex arrangement of functional components. Figure 4 depicts 568 relationships among ADMDs. The benefit of having the ADMD construct 569 is to facilitate discussions and designs that need to distinguish 570 between "internal" issues and "external" ones. 572 The architectural impact of needing to have boundaries between ADMD's 573 is discussed in [Tussle]. Most significant is that the entities 574 communicating across ADMD boundaries will typically have an added 575 burden to enforce organizational policies concerning "external" 576 communications. At a more mundane level, the basis for routing mail 577 between ADMDs is often an issue. 579 Basic types of ADMDs include -- 581 Edge: Independent transfer services, in networks at the edge of 582 the open Internet Mail service. 584 User: End-user services. This might be subsumed under the Edge 585 service, such as is common for web-based email access. 587 Transit: These are Mail Service Providers (MSP) offering value- 588 added capabilities for Edge ADMDs, such as aggregation and 589 filtering. 591 Note that Transit services are quite different from packet-level 592 switching operation. Whereas end-to-end packet transfers usually go 593 through intermediate routers, email exchange across the open Internet 594 is often directly between the Boundary MTAs of Edge ADMDs, at the 595 email level. 597 +-------+ +-------+ +-------+ 598 | ADMD1 | | ADMD3 | | ADMD4 | 599 | ----- | | ----- | | ----- | 600 | | +---------------------->| | | | 601 | User | | |-Edge--+--->|-User | 602 | | | | +---------+ +--->| | | | 603 | V | | | ADMD2 | | +-------+ +-------+ 604 | Edge--+---+ | ----- | | 605 | | | | | | 606 +-------+ +----|-Transit-+---+ 607 | | 608 +---------+ 610 Figure 4: ADministrative Management Domains (ADMD) Example 612 Edge networks can use proprietary email standards internally. 613 However the distinction between Transit network and Edge network 614 transfer services is primarily significant because it highlights the 615 need for concern over interaction and protection between independent 616 administrations. In particular this distinction calls for additional 617 care in assessing transitions of responsibility, as well as the 618 accountability and authorization relationships among participants in 619 email transfer. 621 The interactions between functional components within an ADMD are 622 subject to the policies of that domain. Policies can cover such 623 things as reliability, access control, accountability and even 624 content evaluation and modification. They can be implemented in 625 different functional components, according to the needs of the ADMD. 626 For example see [ID-spamops]. 628 User, Edge and Transit services can be offered by providers that 629 operate component services or sets of services. Further it is 630 possible for one ADMD to host services for other ADMDs. 632 Common ADMD examples are -- 634 Enterprise Service Providers: 636 Operating an organization's internal data and/or mail services. 638 Internet Service Providers: 640 Operating underlying data communication services that, in turn, 641 are used by one or more Relays and Users. It is not 642 necessarily their job to perform email functions, but they can, 643 instead, provide an environment in which those functions can be 644 performed. 646 Mail Service Providers: 648 Operating email services, such as for end-users, or mailing 649 lists. 651 Operational pragmatics often dictate that providers be involved in 652 detailed administration and enforcement issues, to help ensure the 653 health of the overall Internet Mail Service. This can include 654 operators of lower-level packet services. 656 3. Identities 658 Internet Mail uses three forms of identity: mailbox, domain name and 659 message-id. Each is required to be globally unique. 661 3.1. Mailbox 663 "A mailbox sends and receives mail. It is a conceptual entity 664 which does not necessarily pertain to file storage." [RFC2822] 666 A mailbox is specified as an Internet Mail address . It 667 has two distinct parts, divided by an at-sign ("@"). The right-hand 668 side is a globally interpreted domain name that is part of an ADMD. 669 Domain Names are discussed in Section 3.2. Formal Internet Mail 670 addressing syntax can support source routes, to indicate the path 671 through which a message should be sent. Although legal, the use of 672 source routes is not part of the modern Internet Mail service and it 673 is ignored in the rest of this document. 675 The portion to the left of the at-sign contains a string that is 676 globally opaque and is called the . It is to be 677 interpreted only by the entity specified by the address's right-hand 678 side domain name. All other entities MUST treat the local-part as a 679 uninterpreted literal string and MUST preserve all of its original 680 details. As such its public distribution is equivalent to sending a 681 Web browser "cookie" that is only interpreted upon being returned to 682 its originator. 684 3.1.1. Global Standards for Local-Part 686 It is common for sites to have local structuring conventions for the 687 left-hand side of an . This permits sub- 688 addressing, such as for distinguishing different discussion groups 689 used by the same participant. However it is worth stressing that 690 these conventions are strictly private to the user's organization and 691 MUST not be interpreted by any domain except the one listed in the 692 right-hand side of the addr-spec, and those specialized services 693 conforming to standardized conventions, as noted in the next 694 paragraph. 696 There are a few types of addresses that have an elaboration on basic 697 email addressing, with a standardized, global schema for the local- 698 part. These are conventions between originating end-systems and 699 Recipient Gateways, and they are invisible to the public email 700 transfer infrastructure. When an Originator is explicitly sending 701 via a Gateway out of the Internet, there are coding conventions for 702 the local-part, so that the Originator can formulate instructions for 703 the Gateway. Standardized examples of this are the telephone 704 numbering formats for VPIM [RFC3801], such as 705 "+16137637582@vpim.example.com", and iFax [RFC3192], such as 706 "FAX=+12027653000/T33S=1387@ifax.example.com". 708 3.1.2. Scope of Email Address Use 710 Email addresses are being used far beyond their original email 711 transfer and delivery role. In practical terms, email strings have 712 become a common form of user identity on the Internet. What is 713 essential, then, is to be clear about the nature and role of an 714 identity string in a particular context and to be clear about the 715 entity responsible for setting that string. 717 3.2. Domain Names 719 A domain name is a global reference to an Internet resource, such as 720 a host, a service or a network. A domain name usually maps to one or 721 more IP Addresses. Conceptually the name might encompass an entire 722 organization, a collection of machines integrated into a homogeneous 723 service, or only a single machine. A domain name can be administered 724 to refer to individual users, but this is not common practice. The 725 name is structured as a hierarchical sequence of sub-names, separated 726 by dots ("."), with the top of the hierarchy being on the right-end 727 of the sequence. Domain names are defined and operated through the 728 Domain Name Service (DNS) [RFC1034], [RFC1035], [RFC2181]. 730 When not part of a mailbox address, a domain name is used in Internet 731 Mail to refer to the ADMD or the host that took action upon the 732 message, such as providing the administrative scope for a message 733 identifier, or performing transfer processing. 735 3.3. Message Identifier 737 There are two standardized tags, for identifying messages: Message-ID 738 and ENVID. 740 3.3.1. Message-ID 742 The Message-ID is a user-level tag, primarily used for threading and 743 for eliminating duplicates. [RFC2822]. It is associated with the 744 RFC2822.From field, although any actor within the originating ADMD 745 might assign it. The recipient's ADMD is the intended consumer of 746 the Message-ID, although any actor along the transfer path might use 747 it. Internet Mail standards provide for a single Message-ID; however 748 more than one is sometimes assigned. 750 Like a mailbox address, a Message-ID has two distinct parts, divided 751 by an at-sign ("@"). The right-hand side is globally interpreted and 752 specifies the ADMD or host assigning the identifier. The left-hand 753 side contains a string that is globally opaque and serves to uniquely 754 identify the message within the domain referenced on the right-hand 755 side. The duration of uniqueness for the message identifier is 756 undefined. 758 When a message is revised in any way, the question of whether to 759 assign a new Message-ID requires a subjective assessment, deciding 760 whether the editorial content has been changed enough to constitute a 761 new message. [RFC2822] says "a message identifier pertains to 762 exactly one instantiation of a particular message; subsequent 763 revisions to the message each receive new message identifiers." 764 However real-world experience dictates some flexibility. An 765 impossible test is whether the recipient will consider the new 766 message to be equivalent to the old. For most components of Internet 767 Mail, there is no way to predict a specific recipient's preferences 768 on this matter. Both creating and failing to create a new Message-ID 769 have their downsides. 771 The best that can be offered, here, are some guidelines and examples: 773 o If a message is changed only in terms of form, such as character- 774 encoding, it clearly is still the same message. 776 o If a message has minor additions to the content, such as a mailing 777 list tag at the beginning of the RFC2822.Subject header field, or 778 some mailing list administrative information added to the end of 779 the primary body-part's text, then it probably is still the same 780 message. 782 o If a message has viruses deleted from it, it probably is still the 783 same message. 785 o If a message has offensive words deleted from it, then some 786 recipients will consider it the same message, but some will not. 788 o If a message is translated into a different language, then some 789 recipients will consider it the same message, but some will not. 791 The absence of objective, precise criteria for Message-ID re- 792 generation, along with the absence of strong protection associated 793 with the string, means that the presence of an ID can permit an 794 assessment that is marginally better than a heuristic, but the ID 795 certainly has no value on its own for strict formal reference or 796 comparison. Hence it is not appropriate to use the Message-ID for 797 any process that might be called "security". 799 3.3.2. ENVID 801 The ENVID (envelope identifier) is a tag that is primarily for use 802 within Delivery Status Notifications (DSN), so that the Bounce 803 Address (RFC2821.MailFrom) recipient can correlate the DSN with a 804 particular message. [RFC3461] The ENVID is therefore used from one 805 message posting, until the directly-resulting message deliveries. It 806 does not survive re-postings. 808 The format of an ENVID is free-form. Although its creator might 809 choose to impose structure on the string, none is imposed by Internet 810 standards. By implication, the scope of the string is defined by the 811 domain name of the Bounce Address. 813 4. Services and Standards 815 Internet Mail's architecture distinguishes among six different types 816 of functional components, arranged to support a store-and-forward 817 service architecture: 819 * Message 821 * Mail User Agent (MUA) 823 * Message Submission Agent (MSA) 825 * Message Transfer Agent (MTA) 827 * Message Delivery Agent (MDA) 829 * Message Store (MS) 831 This section describes each functional component for Internet Mail, 832 and the standards-based protocols that are associated with their 833 operation. 835 Software implementations of these architectural components often 836 compress them, such as having the same software do MSA, MTA and MDA 837 functions. However the requirements for each of these components of 838 the service are becoming more extensive. So their separation is 839 increasingly common. 841 NOTE: 843 A discussion about any interesting system architecture is often 844 complicated by confusion between architecture versus 845 implementation. An architecture defines the conceptual functions 846 of a service, divided into discrete conceptual modules. An 847 implementation of that architecture can combine or separate 848 architectural components, as needed for a particular operational 849 environment. It is important not to confuse the engineering 850 decisions that are made to implement a product, with the 851 architectural abstractions used to define conceptual functions. 853 The following figure shows function modules and the standardized 854 protocols used between them. Additional protocols and configurations 855 are possible. Boxes defined by asterisks (*) represent functions 856 that often are distributed among two or more systems. 858 +------+ +-------+ 859 ............+ oMUA |..............................| Disp | 860 . +--+-+-+ +-------+ 861 . local,imap}| |{smtp,submission ^ 862 . | | +---------+ | 863 . ******* | | .......................| Bounces | | 864 . * oMS *<-----+ | . +---------+ | 865 . ******* | . ***************** ^ | 866 . +------V-.---*------------+ * | | 867 . MSA | +-------+ * +------+ | * | | 868 . | | oMSA +--O-->| hMSA | | * | | 869 . | +-------+ * +--+---+ | * | | 870 . +------------*------+-----+ * | | 871 /+==========+\ * V {smtp * | | 872 || MESSAGE || * +------+ * /+===+===+\ | 873 ||----------|| MHS * | MTA | * || dsn || | 874 || Envelope || * +--+---+ * \+=======+/ | 875 || SMTP || * V {smtp * ^ ^ | 876 || RFC2822 || * +------+ * | | /+==+==+\ 877 || Content || * | MTA +----*-----+ | || mdn || 878 || RFC2822 || * +--+---+ * | \+=====+/ 879 || MIME || * smtp}| {local * | | 880 \+==========+/ MDA * | {lmtp * | | 881 . +------------+------V-----+ * | | 882 . | +------+ * +------+ | * | | 883 . | | | * | | +--*---------+ | 884 . | | rMDA |<--O---+ hMDA | | * | 885 . | | | * | | |<-*-------+ | 886 . | +-+----+ * +------+ | * | | 887 . +---+--+-----*------------+ * | | 888 . | | ***************** | | 889 . pop} +--+ +---+ | | 890 . imap} | | {local | | 891 . ******************V******** | | 892 . * | +------+ * rMS /+===+===+\ | 893 . * | | srMS | * || sieve || | 894 . * V +--+-+-+ * \+=======+/ | 895 . * +------+ pop} | | * ^ | 896 . * | urMS |<-------+ | * | | 897 . * +--+---+ imap} | * | | 898 . *************************** | | 899 . local}| +------+ |{pop,imap | | 900 . +->| |<------+ | | 901 ...........>| rMUA +---------------------------+ | 902 | +-----------------------------------+ 903 +------+ 905 Figure 5: Protocols and Services 907 4.1. Message Data 909 The purpose of the Mail Handling Service (MHS) is to exchange a 910 message object among participants. , [RFC2822] [RFC0822] Hence all of 911 its underlying mechanisms are merely in the service of getting that 912 message from its Originator to its Recipients. A message can be 913 explicitly labeled as to its nature. [RFC3458] 915 A message comprises a transit handling envelope and the end-user 916 message content. The envelope contains handling information used by 917 the MHS, or generated by it. The content is divided into a 918 structured header and the body. The body may be unstructured simple 919 lines of text, or it may be a MIME tree of multi-media subordinate 920 objects, called body-parts, or attachments. [RFC2045], [RFC2046], 921 [RFC2047], [RFC4288], [RFC4289], [RFC2049]. 923 In addition, Internet Mail has a few conventions for special control 924 data: 926 Delivery Status Notification (DSN): 928 A Delivery Status Notification (DSN) is a message that can be 929 generated by the MHS (MSA, MTA or MDA) and sent to the 930 RFC2821.MailFrom address. The mailbox for this is shown as 931 Bounces in Figure 5. It provides information about message 932 transit, such as transmission errors or successful delivery. 933 [RFC3461] 935 Message Disposition Notification (MDN): 937 A Message Disposition Notification (MDN) is a message that 938 provides information about user-level, Recipient-side message 939 processing, such as indicating that the message has been 940 displayed [RFC3798] or the form of content that can be 941 supported. [RFC3297] It can be generated by an rMUA and is 942 sent to the Disposition-Notification-To address(es). The 943 mailbox for this is shown as Disp in Figure 5. It 945 Message Filtering (SIEVE): 947 SIEVE is a scripting language that permits specifying 948 conditions for differential handling of mail, typically at the 949 time of delivery. [RFC3028] It can be conveyed in a variety of 950 ways, as a MIME part. Figure 5 shows a Sieve specification 951 going from the rMUA to the MDA. However filtering can be done 952 at many different points along the transit path and any one or 953 more of them might be subject to Sieve directives, especially 954 within a single ADMD. Hence the Figure shows only one 955 relationship, for (relative) simplicity. 957 4.1.1. Envelope 959 Information that is directly used by, or produced by, the MHS is 960 called the "envelope". It controls and records handling activities 961 by the transfer service. Internet Mail has a fragmented framework 962 for handling this "handling" information. The envelope exists partly 963 in the transfer protocol SMTP [RFC2821] and partly in the message 964 object [RFC2822]. The SMTP specification uses the term to refer only 965 to the transfer-protocol information. 967 NOTE: 969 Due to the frequent use of the term "envelope" to refer only to 970 SMTP constructs, there has been some call for using a different 971 term, to label the larger set of information defined here. So 972 far, no alternative term has developed any community support. 974 Direct envelope addressing information, as well as optional transfer 975 directives, are carried within the SMTP control channel. Other 976 envelope information, such as trace records, is carried within the 977 message object header fields. Upon delivery, some SMTP-level 978 envelope information is typically encoded within additional message 979 object header fields, such as Return-Path. [RFC2821],[RFC2822] 981 4.1.2. Header Fields 983 Header fields are attribute name/value pairs covering an extensible 984 range of email service, user content and user transaction meta- 985 information. The core set of header fields is defined in [RFC2822], 986 [RFC0822]. It is common to extend this set, for different 987 applications. Procedures for registering header fields are defined 988 in [RFC4021]. An extensive set of existing header field 989 registrations is provided in [RFC3864]. 991 One danger with placing additional information in header fields is 992 that Gateways often alter or delete them. 994 4.1.3. Body 996 The body of a message might simply be lines of ASCII text or it might 997 be hierarchically structured into a composition of multi-media body- 998 part attachments, using MIME. [RFC2045], [RFC2046], [RFC2047], 999 [RFC4288], [RFC2049] MIME structures each body-part into a recursive 1000 set of MIME header field meta-data and MIME Content sections. 1002 4.1.4. Identity References in a Message 1004 For a message in transit, the core uses of identifiers combine into: 1006 +-----------------------+-------------+---------------------+ 1007 | Layer | Field | Set By | 1008 +-----------------------+-------------+---------------------+ 1009 | Message Body | MIME Header | Originator | 1010 | Message header fields | From | Originator | 1011 | | Sender | Source | 1012 | | Reply-To | Originator | 1013 | | To, CC, BCC | Originator | 1014 | | Message-ID | Source | 1015 | | Received | Source, Relay, Dest | 1016 | | Return-Path | MDA, from MailFrom | 1017 | | Resent-* | Mediator | 1018 | SMTP | HELO | Latest Relay Client | 1019 | | MailFrom | Source | 1020 | | RcptTo | Originator | 1021 | IP | IP Address | Latest Relay Client | 1022 +-----------------------+-------------+---------------------+ 1024 Layered Identities 1026 The most common address-related fields are: 1028 RFC2822.From 1030 Set by: Originator 1032 Names and addresses for author(s) of the message content are 1033 listed in the From field. 1035 RFC2822.Reply-To 1037 Set by: Originator 1039 If a message Recipient sends a reply message that would otherwise 1040 use the RFC2822.From field address(es) that are contained in the 1041 original message, then they are instead to use the address(es) in 1042 the RFC2822.Reply-To field. In other words this field is a direct 1043 override of the From field, for responses from Recipients. 1045 RFC2822.Sender 1046 Set by: Source 1048 This specifies the address responsible for submitting the message 1049 into the transfer service. For efficiency this field can be 1050 omitted if it contains the same address as RFC2822.From. However 1051 this does not mean there is no Sender specified. Rather it means 1052 that that header field is virtual and that the address in the From 1053 field MUST be used. 1055 Specification of the error return addresses -- the "Bounce" 1056 address, contained in RFC2821.MailFrom -- is made by the 1057 RFC2822.Sender. Typically the Bounce address is the same as the 1058 Sender address. However some usage scenarios require it to be 1059 different. 1061 RFC2822.To, RFC2822.CC 1063 Set by: Originator 1065 These specify MUA Recipient addresses. However some or all of the 1066 addresses in these fields might not be present in the 1067 RFC2821.RcptTo commands, due to handling process that might 1068 transfer from the former to the latter. 1070 The distinction between To and CC is subjective. Generally a To 1071 addressee is considered primary and is expected to take action on 1072 the message. A CC addressee typically receives a copy only for 1073 their information. 1075 RFC2822.BCC 1077 Set by: Originator 1079 A message might be copied to an addressee whose participation is 1080 not to be disclosed to the RFC2822.To or RFC2822.CC Recipients 1081 and, usually, not to the other BCC Recipients. The BCC header 1082 field indicates a message copy to such a Recipient. 1084 Typically, the field lists no addresses or only lists the address 1085 of the Recipient receiving this copy. An MUA will typically make 1086 separate postings for TO and CC Recipients, versus BCC Recipients. 1087 The former will see no indication that any BCCs were sent, whereas 1088 the latter have a BCC field present. It might be empty, contain a 1089 comment, or contain one or more BCC addresses, depending upon the 1090 preferences of the Originator. 1092 RFC2821.HELO/.EHLO 1094 Set by: Source 1096 The MSA can specify its hosting domain identity for the SMTP HELO 1097 or EHLO command operation. 1099 RFC2821.MailFrom 1101 Set by: Source 1103 This is an end-to-end string that specifies an email address for 1104 receiving return control information, such as "bounces". The name 1105 of this field is misleading, because it is not required to specify 1106 either the author or the agent responsible for submitting the 1107 message. Rather, the agent responsible for submission specifies 1108 the RFC2821.MailFrom address. Ultimately the simple basis for 1109 deciding what address needs to be in the RFC2821.MailFrom is to 1110 determine what address needs to be informed about transmission- 1111 level problems (and, possibly, successes.) 1113 RFC2821.RcptTo 1115 Set by: Originator 1117 This specifies the MUA mailbox address of a recipient. The string 1118 might not be visible in the message content header. For example, 1119 the message destination address header fields, such as RFC2822.To, 1120 might specify a mailing list mailbox, while the RFC2821.RcptTo 1121 address specifies a member of that list. 1123 RFC2821.Received 1125 Set by: Source, Relay, Mediator, Dest 1127 This indicates trace information, including originating host, 1128 relays, Mediators, and MSA host domain names and/or IP Addresses. 1130 RFC2821.Return-Path 1132 Set by: Source 1134 The MDA records the RFC2821.MailFrom address into the 1135 RFC2822.Return-Path field. 1137 RFC2919.List-Id 1139 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-* 1151 Set by: Mediator Originator 1153 [RFC2369] defines a collection of message header fields for use by 1154 mailing lists. In effect they supply list-specific parameters for 1155 common mailing list user operations. The identifiers for these 1156 operations are for the list, itself, and the user-as-subscriber. 1157 [RFC2369] 1159 4.2. User-Level Services 1161 Interactions at the user level entail protocol exchanges, distinct 1162 from those that occur at lower layers of the Internet Mail 1163 architecture, which is above the Internet Transport layer. Because 1164 the motivation for email, and much of its use, is for interaction 1165 among humans, the nature and details of these protocol exchanges 1166 often are determined by the needs of human and group communication. 1167 In terms of efforts to specify behaviors, one effect of this is to 1168 require subjective guidelines, rather than strict rules, for some 1169 aspects of system behavior. Mailing Lists provide particularly 1170 salient examples of this. 1172 4.2.1. Mail User Agent (MUA) 1174 A Mail User Agent (MUA) works on behalf of end-users and end-user 1175 applications. It is their "representative" within the email service. 1177 The Origination-side MUA (oMUA) creates a message and performs 1178 initial "submission" into the transfer infrastructure, via a Mail 1179 Submission Agent (MSA). It can also perform any creation- and 1180 posting-time archival in its Message Store (oMS). An MUA's oMS will 1181 typically include a folder for messages under development (Drafts), a 1182 folder for messages waiting to be sent (Queued or Unsent) and a 1183 folder for messages that have been successfully posted for 1184 transmission (Sent). 1186 The Recipient-side MUA (rMUA) works on behalf of the end-user 1187 Recipient to process received mail. This includes generating user- 1188 level return control messages, displaying and disposing of the 1189 received message, and closing or expanding the user communication 1190 loop, by initiating replies and forwarding new messages. 1192 NOTE: Although not shown in Figure 5, an MUA can, itself, have a 1193 distributed implementation, such as a "thin" user interface module 1194 on a limited end-user device, with the bulk of the MUA 1195 functionality operated remotely on a more capable server. An 1196 example of such an architecture might use IMAP [RFC3501] for most 1197 of the interactions between an MUA client and an MUA server. A 1198 standardized approach for such scenarios is defined by [RFC4550]. 1200 A Mediator is special class of MUA. It performs message re-posting, 1201 as discussed in Section 2.1. 1203 Identity fields relevant to a typical end-user MUA include: 1205 RFC2822.From 1207 RFC2822.Reply-To 1209 RFC2822.Sender 1211 RFC2822.To, RFC2822.CC 1213 RFC2822.BCC 1215 4.2.2. Message Store (MS) 1217 An MUA can employ a long-term Message Store (MS). Figure 5 depicts 1218 an Origination-side Ms (oMS) and a Recipient-side MS (rMS). There is 1219 a rich set of choices for configuring a store, because any MS may 1220 comprise a distributed set of component stores. In Figure 5, the rMS 1221 demonstrates this by showing an rMS that is located on a remote 1222 server (srMS) and an rMS that is on the same machine as the MUA 1223 (urMS). The relationship between two message stores, themselves, can 1224 vary. 1226 As discussed in [RFC1733] the operational relationship among MSs can 1227 be -- 1228 Online: 1230 Only a remote MS is used, with messages being accessible only 1231 when the MUA is attached to the MS, and the MUA repeatedly 1232 fetches all or part of a message, from one session to the next. 1234 Offline: 1236 The MS is local to the user, and messages are completely moved 1237 from any remote store, rather than (also) being retained there. 1239 Disconnected: 1241 An rMS and a uMS are kept synchronized, for all or part of 1242 their contents, while there is a connection between them. 1243 While they are disconnected, mail can continue to arrive at the 1244 rMS and the user may continue to make changes to the uMS. Upon 1245 reconnection, the two stores are re-synchronized. 1247 4.3. MHS-Level Services 1249 4.3.1. Mail Submission Agent (MSA) 1251 A Mail Submission Agent (MSA) accepts the message submission from the 1252 oMUA and enforces the policies of the hosting ADMD and the 1253 requirements of Internet standards. An MSA represents an unusual 1254 functional dichotomy. A portion of its task is to represent MUA 1255 (uMSA) interests during message posting, to facilitate posting 1256 success, and another portion is to represent MHS (hMSA) interests. 1257 This is best modeled, as shown in Figure 5, with two sub-components, 1258 one for the oMUA (oMSA) and one for the MHS (hMSA) 1260 The hMSA's function is to take transit responsibility for a message 1261 that conforms to the relevant Internet standards and to local site 1262 policies. It rejects messages that are not in conformance. The 1263 oMSA's is to perform final message preparation for submission and to 1264 effect the transfer of responsibility to the MHS, via the hMSA. The 1265 amount of preparation will depend upon the local implementations. 1266 Examples of oMSA tasks could be to add header fields, such as Date: 1267 and Message-ID, to modify portions of the message from local 1268 notations to Internet standards, such as expanding an address to its 1269 formal RFC2822 representation. 1271 Historically, standards-based MUA/MSA interactions have used SMTP 1272 [RFC2821]. A recent alternative is SUBMISSION [RFC4409]. Although 1273 SUBMISSION derives from SMTP, it uses a separate TCP port and imposes 1274 distinct requirements, such as access authorization. 1276 Identities relevant to the MSA include: 1278 RFC2821.HELO/.EHLO 1280 RFC2821.MailFrom 1282 RFC2821.RcptTo 1284 RFC2821.Received 1286 4.3.2. Mail Transfer Agent (MTA) 1288 A Mail Transfer Agent (MTA) relays mail for one application-level 1289 "hop". It is like a packet-switch or IP router in that its job is to 1290 make routing assessments and to move the message closer to the 1291 Recipient(s). Relaying is performed by a sequence of MTAs, until the 1292 message reaches a destination MDA. Hence an MTA implements both 1293 client and server MTA functionality. It does not make changes to 1294 addresses in the envelope or reformulate the editorial content. 1295 Hence a change in data form, such as to the MIME Content-Transfer- 1296 Encoding, is within the purview of an MTA, whereas removal or 1297 replacement of body content is not. Also it can add trace 1298 information. Of course email objects are typically much larger than 1299 the payload of a packet or datagram, and the end-to-end latencies are 1300 typically much higher. 1302 Internet Mail primarily uses SMTP [RFC2821], [RFC0821] to effect 1303 point-to-point transfers between peer MTAs. Other transfer 1304 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1305 most network layer mechanisms, Internet Mail's SMTP supports a basic 1306 level of reliability, by virtue of providing for retransmission after 1307 a temporary transfer failure. Contrary to typical packet switches 1308 (and Instant Messaging services) Internet Mail MTAs typically store 1309 messages in a manner that allows recovery across service 1310 interruptions, such as host system shutdown. However the degree of 1311 such robustness and persistence by an MTA can be highly variable. 1313 The primary "routing" mechanism for Internet Mail is the DNS MX 1314 record [RFC1035], which specifies a host through which the queried 1315 domain can be reached. This presumes a public -- or at least a 1316 common -- backbone that permits any attached host to connect to any 1317 other. 1319 Identities relevant to the MTA include: 1321 RFC2821.HELO/.EHLO 1323 RFC2821.MailFrom 1325 RFC2821.RcptTo 1327 RFC2822.Received 1329 Set by: Relay Server 1331 4.3.3. Mail Delivery Agent (MDA) 1333 A Mail Delivery Agent (MDA) delivers email to the Recipient's 1334 mailbox. It can provide distinctive, address-based functionality, 1335 made possible by its detailed knowledge of the properties of the 1336 destination address. This knowledge might also be present elsewhere 1337 in the Recipient's ADMD, such as at an organizational border 1338 (Boundary) Relay. However it is required for the MDA, if only 1339 because the MDA must know where to deliver the message. 1341 As with an MSA, an MDA serves two roles, as depicted in Figure 5. 1342 Formal transfer of responsibility, called "delivery" is effected 1343 between the two components that embody these roles. The MHS portion 1344 (hMDA) primarily functions as a server SMTP engine. A common 1345 additional role is to re-direct the message to an alternative 1346 address, as specified by the recipient addressee's preferences. The 1347 job of the recipient portion of the MDA (rMDA) is to perform any 1348 delivery-actions are desired by the recipient. 1350 Using Internet protocols, delivery can be effected by a variety of 1351 standard protocols. When coupled with an internal local mechanism, 1352 SMTP [RFC2821] and LMTP [RFC2033] permit "push" delivery to the 1353 Recipient system, at the initiative of the upstream email service. 1354 POP [RFC1939] and IMAP [RFC3501] are used for "pull" delivery at the 1355 initiative of the Recipient system. POP and IMAP can also be used 1356 for repeated access to messages on a remote MS. 1358 Identities relevant to the MDA include: 1360 RFC2821.Return-Path 1361 Set by: Originator Source or Mediator Source 1363 The MDA records the RFC2821.MailFrom address into the 1364 RFC2822.Return-Path field. 1366 RFC2822.Received 1368 Set by: MDA server 1370 An MDA can record a Received header field to indicate trace 1371 information, including source host and receiving host domain 1372 names and/or IP Addresses. 1374 5. Mediators 1376 Basic email transfer from an Originator to the specified Recipients 1377 is accomplished by using an asynchronous, store-and-forward 1378 communication infrastructure, in a sequence of independent 1379 transmissions through some number of MTAs. A very different task is 1380 a User-level sequence of postings and deliveries, through Mediators. 1381 A Mediator forwards a message, through a re-posting process. The 1382 Mediator does share some functionality with basic MTA relaying, but 1383 it enjoys a degree of freedom with both addressing and content that 1384 is not available to MTAs. 1386 RFC2821.HELO/.EHLO 1388 Set by: Mediator Source 1390 RFC2821.MailFrom 1392 Set by: Originator Source or Mediator Source 1394 RFC2821.RcptTo 1396 Set by: Mediator Originator 1398 RFC2821.Received 1400 Set by: Mediator Dest 1402 The salient aspect of a Mediator, that distinguishes it from any 1403 other MUA creating an entirely new message, is that a Mediator 1404 preserves the integrity and tone of the original message, including 1405 the essential aspects of its origination information. The Mediator 1406 might also add commentary. 1408 Examples of MUA message creation that are NOT performed by Mediators 1409 include -- 1411 New message that forwards an existing message: 1413 This action rather curiously provides a basic template for a class 1414 of Mediators. However for its typical occurrence it is not itself 1415 an example of a Mediator. The new message is viewed as being from 1416 the Agent doing the forwarding, rather than being from the 1417 original Originator. 1419 A new message encapsulates the original message and is seen as 1420 strictly "from" the Mediator. The Mediator might add commentary 1421 and certainly has the opportunity to modify the original message 1422 content. The forwarded message is therefore independent of the 1423 original message exchange and creates a new message dialogue. 1424 However the final Recipient sees the contained message as from the 1425 original Originator. 1427 Reply: 1429 When a Recipient formulates a response back to the original 1430 message's author, the new message is not typically viewed as being 1431 a "forwarding" of the original. Its focus is the new content, 1432 although it might contain all or part of the material in the 1433 original message. Therefore the earlier material is merely 1434 contextual and secondary. 1436 Annotation: 1438 The integrity of the original message is usually preserved, but 1439 one or more comments about the message are added in a manner that 1440 distinguishes commentary from original text. The tone of the new 1441 message is that it is primarily commentary from a new Originator, 1442 similar to a Reply. 1444 The remainder of this section describes common examples of Mediators. 1446 5.1. Aliasing 1448 Aliasing is a simple re-addressing facility that is available in most 1449 MDA implementations. It is performed just before placing a message 1450 into the specified Recipient's mailbox. Instead the message is 1451 submitted back to the transfer service, for delivery to one or more 1452 alternate addresses. Although typically implemented as part of an 1453 MDA, this facility is strictly a Recipient user function. It 1454 resubmits the message, replacing the envelope address, on behalf of 1455 the mailbox address that was listed in the envelope. 1457 What is most distinctive about this forwarding mechanism is how 1458 closely it compares to normal MTA store-and-forward Relaying. Its 1459 only interesting difference is that it changes the RFC2821.RcptTo 1460 value. Having the change be this small makes it easy to view 1461 aliasing as a part of the lower-level mail relaying activity. 1462 However the small change has a large semantic impact: The designated 1463 recipient has chosen a new recipient. Hence that original recipient 1464 SHOULD become responsible for any handling issues. This change would 1465 be reflected by replacing the message's RFC2821.MailFrom address to 1466 be one within the scope of the ADMD doing the aliasing. 1468 An MDA that is re-posting a message to an alias typically changes 1469 only envelope information: 1471 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1473 Set by: Originator 1475 These retain their original addresses. 1477 RFC2821.RcptTo 1479 Set by: Mediator Originator 1481 This field contains an alias address. 1483 RFC2821.MailFrom 1485 Set by: Originator Source or Mediator Source 1487 The agent responsible for submission to an alias address will 1488 often retain the original address to receive handling Bounces. 1489 The benefit of retaining the original MailFrom value is to 1490 ensure that the origination-side agent knows that there has 1491 been a delivery problem. On the other hand, the responsibility 1492 for the problem usually lies with the Recipient, since the 1493 Alias mechanism is strictly under the Recipient's control. 1495 RFC2821.Received 1496 Set by: Mediator Dest 1498 The agent can record Received information, to indicate the 1499 delivery to the original address and submission to the alias 1500 address. The trace of Received header fields can therefore 1501 include everything from original posting through final delivery 1502 to a final delivery. 1504 5.2. Re-Sending 1506 Also called Re-Directing, Re-Sending differs from Forwarding by 1507 virtue of having the Mediator "splice" a message's addressing 1508 information, to connect the Originator of the original message and 1509 the Recipient of the new message. This permits them to have direct 1510 exchange, using their normal MUA Reply functions. Hence the new 1511 Recipient sees the message as being From the original Originator, 1512 even if the Mediator adds commentary. 1514 Identities specified in a resent message include 1516 RFC2822.From 1518 Set by: original Originator 1520 Names and email addresses for the original author(s) of the 1521 message content are retained. The free-form (display-name) 1522 portion of the address might be modified to provide informal 1523 reference to the agent responsible for the redirection. 1525 RFC2822.Reply-To 1527 Set by: original Originator 1529 If this field is present in the original message, it is 1530 retained in the Resent message. 1532 RFC2822.Sender 1534 Set by: Originator Source or Mediator Source 1536 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1538 Set by: original Originator 1539 These specify the original message Recipients. 1541 RFC2822.Resent-From 1543 Set by: Mediator Originator 1545 The address of the original Recipient who is redirecting the 1546 message. Otherwise the same rules apply for the Resent-From 1547 field as for an original RFC2822.From field 1549 RFC2822.Resent-Sender 1551 Set by: Mediator Source 1553 The address of the agent responsible for re-submitting the 1554 message. As with RFC2822.Sender, this field is often omitted 1555 when it would merely contain the same address as 1556 RFC2822.Resent-From. 1558 RFC2822.Resent-To, RFC2822.Resent-cc, RFC2822.Resent-bcc: 1560 Set by: Mediator Originator 1562 The addresses of the new Recipients who will now be able to 1563 reply to the original author. 1565 RFC2821.MailFrom 1567 Set by: Mediator Source 1569 The agent responsible for re-submission (RFC2822.Resent-Sender) 1570 is also responsible for specifying the new MailFrom address. 1572 RFC2821.RcptTo 1574 Set by: Mediator Originator 1576 This will contain the address of a new Recipient 1578 RFC2822.Received 1580 Set by: Mediator Dest 1582 When resending a message the submission agent can record a 1583 Received header field, to indicate the transition from original 1584 posting to resubmission. 1586 5.3. Mailing Lists 1588 Mailing lists have explicit email addresses and they re-post messages 1589 to a list of subscribed members. The Mailing List Actor performs a 1590 task that can be viewed as an elaboration of the Re-Director role. 1591 In addition to sending the new message to a potentially large number 1592 of new Recipients, the Mediator can modify content, such as deleting 1593 attachments, formatting conversion, and adding list-specific 1594 comments. In addition, archiving list messages is common. Still the 1595 message retains characteristics of being "from" the original 1596 Originator. 1598 Identities relevant to a mailing list processor, when submitting a 1599 message, include: 1601 RFC2919.List-Id 1603 Set by: Mediator Originator 1605 RFC2369.List-* 1607 Set by: Mediator Originator 1609 RFC2822.From 1611 Set by: original Originator 1613 Names and email addresses for the original author(s) of the 1614 message content are specified -- or, rather, retained. 1616 RFC2822.Reply-To 1618 Set by: original Originator or Mediator Originator 1620 RFC2822.Sender 1622 Set by: Originator Source or Mediator Source 1624 This will usually specify the address of the agent responsible 1625 for mailing list operations. However some mailing lists 1626 operate in a manner very similar to a simple MTA Relay, so that 1627 they preserve as much of the original handling information as 1628 possible, including the original RFC2822.Sender field. 1630 RFC2822.TO, RFC2822.CC 1632 Set by: original Originator 1634 These usually contains the original list of Recipient 1635 addresses. 1637 RFC2821.MailFrom 1639 Set by: Originator Source or Mediator Source 1641 This can contain the original address to be notified of 1642 transmission issues, or the mailing list agent can set it to 1643 contain a new Notification address. Typically the value is set 1644 to a new address, so that mailing list members and posters are 1645 not burdened with transmission-related Bounces. 1647 RFC2821.RcptTo 1649 Set by: Mediator Originator 1651 This contains the address of a mailing list member. 1653 RFC2821.Received 1655 Set by: Mediator Dest 1657 A Mailing List Agent can record a Received header field, to 1658 indicate the transition from original posting to mailing list 1659 forwarding. The Agent can choose to have the message retain 1660 the original set of Received header fields or can choose to 1661 remove them. In the latter case it can ensure that the 1662 original Received header fields are otherwise available, to 1663 ensure later accountability and diagnostic access to them. 1665 5.4. Gateways 1667 A Gateway performs the basic routing and transfer work of message 1668 relaying, but it also may make any message or address modifications 1669 that are needed to send the message into a messaging environment that 1670 operates according to different standards or potentially incompatible 1671 policies. When a Gateway connects two differing messaging services, 1672 its role is easy to identify and understand. When it connects 1673 environments that have technical similarity, but can have significant 1674 administrative differences, it is easy to think that a Gateway is 1675 merely an MTA. 1677 The critical distinction between an MTA and a Gateway is that the 1678 latter transforms addresses and/or message content, in order to map 1679 between the standards of two, different messaging services. In 1680 virtually all cases, this mapping process results in some degree of 1681 semantic loss. The challenge of Gateway design is to minimize this 1682 loss. 1684 A Gateway can set any identity field available to a regular MUA. 1685 Identities typically relevant to Gateways include: 1687 RFC2822.From 1689 Set by: original Originator 1691 Names and email addresses for the original author(s) of the 1692 message content are retained. As for all original addressing 1693 information in the message, the Gateway can translate addresses 1694 in whatever way will allow them continue to be useful in the 1695 target environment. 1697 RFC2822.Reply-To 1699 Set by: original Originator 1701 The Gateway SHOULD retain this information, if it is originally 1702 present. The ability to perform a successful reply by a 1703 Gatewayed Recipient is a typical test of Gateway functionality. 1705 RFC2822.Sender 1707 Set by: Originator Source or Mediator Source 1709 This can retain the original value or can be set to a new 1710 address 1712 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1714 Set by: original Recipient 1716 These usually retain their original addresses. 1718 RFC2821.MailFrom 1720 Set by: Originator Source or Mediator Source 1721 The agent responsible for gatewaying the message can choose to 1722 specify a new address to receive handling notices. 1724 RFC2822.Received 1726 Set by: Mediator Dest 1728 The Gateway can record a Received header field, to indicate the 1729 transition from original posting to the new messaging 1730 environment. 1732 5.5. Boundary Filter 1734 Organizations often enforce security boundaries by subjecting 1735 messages to analysis, for conformance with the organization's safety 1736 policies. An example is detection of content classed as spam or a 1737 virus. A Filter might alter the content, to render it safe, such as 1738 by removing content deemed unacceptable. Typically these actions 1739 will result in the addition of content that records the actions. 1741 6. Security Considerations 1743 This document does not specify any new Internet Mail functionality. 1744 Consequently it is not intended to introduce any security 1745 considerations. 1747 However its discussion of the roles and responsibilities for 1748 different mail service modules, and the information they create, 1749 highlights the considerable degree to which security issues are 1750 present when implementing any component of the Internet Mail service. 1751 In addition, email transfer protocols can operate over authenticated 1752 and/or encrypted links, and message content or authorship can be 1753 authenticated or encrypted. 1755 7. IANA Considerations 1757 This document has no actions for IANA. 1759 8. References 1761 8.1. Normative 1763 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 1764 RFC 821, August 1982. 1766 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1767 text messages", STD 11, RFC 822, August 1982. 1769 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1770 STD 13, RFC 1034, November 1987. 1772 [RFC1035] Mockapetris, P., "Domain names - implementation and 1773 specification", STD 13, RFC 1035, November 1987. 1775 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1776 STD 53, RFC 1939, May 1996. 1778 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1779 October 1996. 1781 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1782 Extensions (MIME) Part One: Format of Internet Message 1783 Bodies", RFC 2045, November 1996. 1785 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1786 Extensions (MIME) Part Two: Media Types", RFC 2046, 1787 November 1996. 1789 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1790 Part Three: Message Header Extensions for Non-ASCII Text", 1791 RFC 2047, November 1996. 1793 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1794 Extensions (MIME) Part Five: Conformance Criteria and 1795 Examples", RFC 2049, November 1996. 1797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1798 Requirement Levels", BCP 14, RFC 2119, March 1997. 1800 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1801 Specification", RFC 2181, July 1997. 1803 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1804 for Core Mail List Commands and their Transport through 1805 Message Header Fields", RFC 2369, July 1998. 1807 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1809 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1810 Addresses", RFC 2645, August 1999. 1812 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1813 April 2001. 1815 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1816 April 2001. 1818 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1819 and Namespace for the Identification of Mailing Lists", 1820 RFC 2919, March 2001. 1822 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 1823 RFC 3028, January 2001. 1825 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet 1826 Mail", RFC 2304, October 2001. 1828 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 1829 Negotiation for Messaging Services based on Email", 1830 RFC 3297, July 2002. 1832 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1833 Context for Internet Mail", RFC 3458, January 2003. 1835 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1836 Extension for Delivery Status Notifications (DSNs)", 1837 RFC 3461, January 2003. 1839 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1840 4rev1", RFC 3501, March 2003. 1842 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1843 Notification", RFC 3798, May 2004. 1845 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1846 Procedures for Message Header Fields", RFC 3864, 1847 September 2004. 1849 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 1850 Header Fields", RFC 4021, March 2005. 1852 [RFC4288] Freed, N., Klensin, J., and J. Postel, "Media Type 1853 Specifications and Registration Procedures", BCP 13, 1854 RFC 4288, December 2005. 1856 [RFC4289] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1857 Internet Mail Extensions (MIME) Part Four: Registration 1858 Procedures", BCP 13, RFC 4289, December 2005. 1860 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1861 RFC 4409, April 2006. 1863 [RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support 1864 Diverse Service Environments (Lemonade) Profile", 1865 June 2006. 1867 8.2. Descriptive 1869 [ID-spamops] 1870 Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 1871 E. Allman, "Email Submission Between Independent 1872 Networks", draft-spamops-00 (work in progress), 1873 March 2004. 1875 [RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4", 1876 December 1994. 1878 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 1879 RFC 1767, March 1995. 1881 [RFC3801] Vaudreuil, G. and G. Parsons, "", RFC 3801, June 2004. 1883 [RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for 1884 Internet Mail: FFPIM", December 2005. 1886 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 1887 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1888 ACM SIGCOMM, 2002. 1890 Appendix A. Acknowledgements 1892 This work derives from a section in draft-hutzler-spamops. 1893 [ID-spamops] Discussion of the Source actor role was greatly 1894 clarified during discussions in the IETF's Marid working group. 1896 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1897 insight on the framework and details of the original drafts. 1899 Later reviews and suggestions were provided by Nathaniel Borenstein, 1900 Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, 1901 Eric Hall, Brad Knowles, John Leslie, Bruce Lilly, Mark E. Mallett, 1902 David MacQuigg, Chris Newman, Daryl Odnert, Rahmat M. Samik-Ibrahim, 1903 Marshall Rose, Hector Santos, Jochen Topf, Willemien Hoogendoorn, 1904 Valdis Kletnieks. 1906 Diligent proof-reading was performed by Bruce Lilly. 1908 Author's Address 1910 Dave Crocker 1911 Brandenburg InternetWorking 1912 675 Spruce Drive 1913 Sunnyvale, CA 94086 1914 USA 1916 Phone: +1.408.246.8253 1917 Email: dcrocker@bbiw.net 1919 Full Copyright Statement 1921 Copyright (C) The IETF Trust (2007). 1923 This document is subject to the rights, licenses and restrictions 1924 contained in BCP 78, and except as set forth therein, the authors 1925 retain all their rights. 1927 This document and the information contained herein are provided on an 1928 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1929 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1930 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1931 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1932 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1933 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1935 Intellectual Property 1937 The IETF takes no position regarding the validity or scope of any 1938 Intellectual Property Rights or other rights that might be claimed to 1939 pertain to the implementation or use of the technology described in 1940 this document or the extent to which any license under such rights 1941 might or might not be available; nor does it represent that it has 1942 made any independent effort to identify any such rights. Information 1943 on the procedures with respect to rights in RFC documents can be 1944 found in BCP 78 and BCP 79. 1946 Copies of IPR disclosures made to the IETF Secretariat and any 1947 assurances of licenses to be made available, or the result of an 1948 attempt made to obtain a general license or permission for the use of 1949 such proprietary rights by implementers or users of this 1950 specification can be obtained from the IETF on-line IPR repository at 1951 http://www.ietf.org/ipr. 1953 The IETF invites any interested party to bring to its attention any 1954 copyrights, patents or patent applications, or other proprietary 1955 rights that may cover technology that may be required to implement 1956 this standard. Please address the information to the IETF at 1957 ietf-ipr@ietf.org. 1959 Acknowledgment 1961 Funding for the RFC Editor function is provided by the IETF 1962 Administrative Support Activity (IASA).