idnits 2.17.00 (12 Aug 2021) /tmp/idnits50697/draft-crocker-email-arch-06.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 1900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1924. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (local-part) of an addr-spec. This permits sub-addressing, such as for distinguishing different discussion groups 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 (March 4, 2007) is 5556 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: 'RFC1767' is mentioned on line 1850, but not defined == Missing Reference: 'ID-ffpim' is mentioned on line 1840, but not defined == Missing Reference: 'Tussle' is mentioned on line 1853, but not defined == Missing Reference: 'ID-spamops' is mentioned on line 1860, 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 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2304 (Obsoleted by RFC 3192) ** Obsolete normative reference: RFC 2421 (Obsoleted by RFC 3801) ** Obsolete normative reference: RFC 2423 (Obsoleted by RFC 3801) ** Downref: Normative reference to an Informational RFC: RFC 2442 ** Obsolete normative reference: RFC 2476 (Obsoleted by RFC 4409) ** Obsolete normative reference: RFC 2465 (ref. 'RFC2645') (Obsoleted by RFC 4293, RFC 8096) ** 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 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 4550 (Obsoleted by RFC 5550) Summary: 18 errors (**), 0 flaws (~~), 7 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 March 4, 2007 5 Expires: September 5, 2007 7 Internet Mail Architecture 8 draft-crocker-email-arch-06 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 September 5, 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 users service and many others for performing 50 message transfer. Public discussion of the architecture has not kept 51 pace with the real-world technical and operational refinements. This 52 document offers an enhanced Internet Mail architecture that targets 53 description of the existing service. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Service Overview . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Document Conventions . . . . . . . . . . . . . . . . . . . 5 60 1.3. Document Administration . . . . . . . . . . . . . . . . . 5 61 2. Email Actor Roles . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2. Mail Handling Service (MHS) Actors . . . . . . . . . . . . 8 64 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 11 65 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 3.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 15 68 3.3. Message Identifier . . . . . . . . . . . . . . . . . . . . 15 69 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 17 70 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 20 71 4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 22 72 4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 25 73 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 29 74 5.1. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 31 75 5.2. Re-Sending . . . . . . . . . . . . . . . . . . . . . . . . 32 76 5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 34 77 5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 36 78 5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 38 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 81 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 38 82 7.2. Descriptive . . . . . . . . . . . . . . . . . . . . . . . 40 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 85 Intellectual Property and Copyright Statements . . . . . . . . . . 42 87 1. Introduction 89 Over its thirty-five year history Internet Mail has undergone 90 significant changes in scale and complexity, as it has become a 91 global infrastructure service. However the changes have been 92 evolutionary, rather than revolutionary, reflecting a strong desire 93 to preserve its installed base of users and utility. 95 The first standardized architecture for networked email specified a 96 simple split between the user world, in the form of Mail User Agents 97 (MUA), and the transmission world, in the form of the Mail Handling 98 Service (MHS) composed of Mail Transfer Agents (MTA). The MHS is 99 responsible for accepting a message from one User and delivering it 100 to one or more others, creating a virtual MUA-to-MUA exchange 101 environment. 103 +--------+ 104 +---------------->| User | 105 | +--------+ 106 | ^ 107 +--------+ | +--------+ . 108 | User +--+--------->| User | . 109 +--------+ | +--------+ . 110 . | ^ . 111 . | +--------+ . . 112 . +-->| User | . . 113 . +--------+ . . 114 . ^ . . 115 . . . . 116 V . . . 117 +---+----------------+------+------+---+ 118 | . . . . | 119 | +...............>+ . . | 120 | . . . | 121 | +......................>+ . | 122 | . . | 123 | +.............................>+ | 124 | | 125 | Mail Handling Service (MHS) | 126 +--------------------------------------+ 128 Figure 1: Basic Internet Mail Service Model 130 Today, Internet Mail is marked by many independent operators, many 131 different components for providing users service and many other 132 components for performing message transfer. So it is not surprising 133 that the operational service has sub-divided each of these "layers" 134 into more specialized modules. Core aspects of the service, such as 135 mailbox address and message style, have remained remarkably constant. 136 However public discussion of the architecture has not kept pace with 137 the real-world refinements. This document offers an enhanced 138 Internet Mail architecture to reflect the current service. The 139 original distinction between user-level concerns and transfer-level 140 concerns is retained, with an elaboration to each "level" of the 141 architecture that is discussed separately. The term "Internet Mail" 142 is used to refer to the entire collection of user and transfer 143 components. 145 For Internet Mail the term "end-to-end" usually refers to a single 146 posting and the set of deliveries directly resulting from its single 147 transiting of the MHS. A common exception is with group dialogue 148 that is mediated via a mailing list, so that two postings occur, 149 before intended recipients receive an originator's message. In fact, 150 some uses of email consider the entire email service -- including 151 Originator and Recipient -- as a subordinate component. For these 152 services "end-to-end" refers to points outside of the email service. 153 Examples are voicemail over email [RFC2423], EDI over email [RFC1767] 154 and facsimile over email.[ID-ffpim] 156 The current draft: 158 * Documents refinements to the email model 160 * Clarifies functional roles for the architectural components 162 * Clarifies identity-related issues, across the email service 164 1.1. Service Overview 166 End-to-end Internet Mail exchange is accomplished by using a 167 standardized infrastructure comprising: 169 * An email object 171 * Global addressing 173 * An asynchronous sequence of point-to-point transfer mechanisms 175 * No prior arrangement between Originator and Recipient 177 * No prior arrangement between point-to-point transfer services, 178 over the open Internet 180 * No requirement for Originator and Recipient to be online at the 181 same time. 183 The end-to-end portion of the service is the email object, called a 184 message. Broadly the message, itself, is divided between handling 185 control information and user message content. 187 A precept to the design of mail over the open Internet is permitting 188 user-to-user and MTA-to-MTA interoperability to take place with no 189 prior, direct administrative arrangement between independent 190 Administrative Management Domains (AdMD). That is, all participants 191 rely on having the core services be universally supported, either 192 directly or through Gateways that translate between Internet Mail 193 standards and other email environments. Given the importance of 194 spontaneity and serendipity in the world of human communications, 195 this lack of prearrangement between the participants is a core 196 benefit of Internet Mail and remains a core requirement for it. 198 Within localized environments (Edge networks) prior administrative 199 arrangement can include access control, routing constraints and 200 lookup service configuration. In recent years one change to local 201 environments is an increased requirement for authentication or, at 202 least, accountability. In these cases a server performs explicit 203 validation of the client's identity. 205 1.2. Document Conventions 207 In this document, references to structured fields of a message use a 208 two-part dotted notation. The first part cites the document that 209 contains the specification for the field and the second is the name 210 of the field. Hence is the From field in an email 211 content header and is the address in the SMTP 212 "Mail From" command. 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as specified in RFC 2119 [RFC2119]. 218 1.3. Document Administration 220 Discussion venue: Please direct discussion about this document to 221 the IETF-SMTP mailing list . 223 Changes: 225 Modified Protocols and Services figure, for MS, MSA and MDA. 226 Revised discussion to reflect these changes, particularly the 227 split role an MSA or MDA serves. 229 Added recent Lemonade reference, for thin clients. 231 Various clarifications and wordsmithing. 233 2. Email Actor Roles 235 Internet Mail is a highly distributed service, with a variety of 236 actors serving different roles. These divide into 3 basic types: 238 * User 240 * Mail Handling Service (MHS) 242 * ADministrative Management Domain (ADMD) 244 Although related to a technical architecture, the focus on Actors 245 concerns participant responsibilities, rather than on functional 246 modules. Hence the labels used are different than for classic email 247 architecture diagrams. Actors often will be associated with 248 different organizations. This operational independence provides the 249 motivation for distinguishing among different ADMDs. 251 2.1. User Actors 253 Users are the sources and sinks of messages. They can be humans or 254 processes. They can have an exchange that iterates and they can 255 expand or contract the set of Users participating in a set of 256 exchanges. In Internet Mail there are three types of user-level 257 Actors: 259 * Originators 261 * Recipients 263 * Mediators 265 From the User-level perspective all mail transfer activities are 266 performed by a monolithic Mail Handling Service (MHS), even though 267 the actual service can be provided by many independent organizations. 269 Users are customers of this unified service. 271 The following depicts the flow of messages among Actors. 273 +------------+ 274 | |<---------------------------+ 275 | Originator |<----------------+ | 276 | |<----+ | | 277 +-+---+----+-+ | | | 278 | | | | | | 279 | | V | | | 280 | | +---------+-+ | | 281 | | | Recipient | | | 282 | | +-----------+ | | 283 | | | | 284 | | +--------+ | | 285 | | | | | | 286 | V V | | | 287 | +-----------+ +-+-------+-+ | 288 | | Mediator +--->| Recipient | | 289 | +-----------+ +-----------+ | 290 | | 291 | +-----------------------------+ | 292 | | +----------+ | | 293 | | | | | | 294 V V V | | | 295 +-----------+ +-----------+ +---+-+-+---+ 296 | Mediator +--->| Mediator +--->| Recipient | 297 +-----------+ +-----------+ +-----------+ 299 Figure 2: Relationships Among User Actors 301 2.1.1. Originator 303 Also called "Author", this is the user-level participant responsible 304 for creating original content and requesting its transmission. The 305 MHS operates to send and deliver mail among Originators and 306 Recipients. As described below, the MHS has a "Source" role that 307 correlates with the Author role. 309 2.1.2. Recipient 311 The Recipient is a consumer of delivered content. As described 312 below, the MHS has a "Dest[ination]" role that correlates with the 313 Recipient role. 315 A Recipient can close the user-level communication loop by creating 316 and submitting a new message that replies to an Originator. An 317 example of an automated form of reply is the Message Disposition 318 Notification, which informs the Originator about how the Recipient 319 handled the message. See Section 4.1. 321 2.1.3. Mediator 323 A Mediator receives, aggregates, reformulates and redistributes 324 messages as part of a potentially-protracted, higher-level exchange 325 among Users. Example uses of Mediators include group dialogue and 326 organizational message flow, as occurs with a purchase approval 327 process. Note that it is easy to confuse this user-level activity 328 with the underlying MHS transfer exchanges. However they serve very 329 different purposes and operate in very different ways. Mediators are 330 considered extensively in Section 5. 332 When mail is delivered to the mailbox address specified in the 333 RFC2821.MailFrom command, a receiving Mediator is viewed by the Mail 334 Handling Service as a Recipient. When submitting messages, the 335 Mediator is an Originator. What is distinctive is that a Mediator 336 preserves the Originator information of the message it reformulates, 337 but may make meaningful changes to the content. Hence the MHS sees a 338 new message, but Users receive a message that is interpreted as 339 primarily being from -- or, at least, initiated by -- the author of 340 the original message. The role of a Mediator permits distinct, 341 active creativity, rather than being limited to the more constrained 342 job of merely connecting together other participants. Hence it is 343 really the Mediator that is responsible for the new message. 345 A Mediator's task can be complex and contingent, such as by modifying 346 and adding content or regulating which users are allowed to 347 participate and when. The popular example of this role is a group 348 mailing list. A sequence of Mediators may even perform a series of 349 formal steps, such as reviewing, modifying and approving a purchase 350 request. 352 Because a Mediator originates messages, it might also receive 353 replies. So a Mediator really is a full-fledged User. 355 Gateway: A Gateway is a particularly interesting form of Mediator. 356 It is a hybrid of User and Relay that interconnects heterogeneous 357 mail services. Its goal is to emulate a Relay, so Gateway is 358 described in more detail, in Section 2.2.4. 360 2.2. Mail Handling Service (MHS) Actors 362 The Mail Handling Service (MHS) has the task of performing a single, 363 email-level, end-to-end transfer on behalf of the Originator and 364 reaching the Recipient address(es) specified in the envelope. 366 Mediated or protracted, iterative exchanges, such as those used for 367 collaboration over time, are part of the User-level service, and are 368 not part of this Transfer-level Handling Service. 370 The following depicts the relationships among transfer participants 371 in Internet Mail. It shows the Source as distinct from the 372 Originator, and Dest[ination] as distinct from Recipient, although it 373 is common for each pair to be the same actor. The figure also shows 374 multiple Relays in the sequence. It is legal to have no separate 375 Relay, where the Source and Dest interact directly. For intra- 376 organization mail services, it is common to have only one Relay. 378 +------------+ +-----------+ 379 | Originator | | Recipient | 380 +-----+------+ +-----------+ 381 | ^ 382 | Mail Handling Service (MHS) | 383 /+=================================================+\ 384 || | | || 385 || | | || 386 V | 387 +---------+ +--------+ +----+----+ 388 | | | |<------------+ | 389 | Source +...>| Bounce | | Dest | 390 | | | |<---+ | | 391 +----+----+ +--------+ | +---------+ 392 | | ^ 393 V | | 394 +---------+ +----+----+ +----+----+ 395 | Relay +-->.......-->| Relay +-->| Relay | 396 +---------+ +----+----+ +---------+ 397 | 398 V 399 +---------+ 400 | Gateway +-->... 401 +---------+ 403 Figure 3: Relationships Among MHS Actors 405 2.2.1. Source 407 The Source role is responsible for ensuring that a message is valid 408 for posting and then submitting it to a Relay. Validity includes 409 conformance with Internet Mail standards, as well as with local 410 operational policies. The Source can simply review the message for 411 conformance and reject it if there are errors, or it can create some 412 or all of the necessary information. 414 The Source operates with dual "allegiance". It serves the Originator 415 and often it is the same entity. However its role in assuring 416 validity means that it MUST also represent the local operator of the 417 MHS, that is, the local ADministrative Management Domain (ADMD). 419 The Source also has the responsibility for any post-submission, 420 Originator-related administrative tasks associated with message 421 transmission and delivery. Notably this pertains to error and 422 delivery notices. Hence Source is best held accountable for the 423 message content, even when they did not create any or most of it. 425 2.2.2. Bounce Handler 427 The Bounce Handler processes service notifications that are generated 428 by the MHS, as a result of its efforts to transfer or deliver the 429 message. Notices can be about failures or completions and are sent 430 to an address that is specified by the Source. This Bounce handling 431 address (also known as a Return address) might have no visible 432 characteristics in common with the address of the Originator or 433 Source. 435 NOTE: 437 The choice of the label "Bounce" is unfortunate, due to its 438 negative implication. Currently, this is the most popular term 439 for the field. 441 2.2.3. Relay 443 A mail Relay performs email transfer-service routing and store-and- 444 forward. It adds envelope-level handling information and then 445 (re-)transmits the message on towards its Recipient(s). A Relay can 446 add information to the envelope, such as with trace information. 447 However it does not modify existing envelope information or the 448 message content semantics. It can modify message content syntax, 449 such as a change from text to binary transfer-encoding form, only as 450 required to meet the capabilities of the next hop in the MHS. 452 A set of Relays composes a Mail Handling Service (MHS) network. This 453 is above any underlying packet-switching network that they might be 454 using and below any gateways or other user-level Mediators. 456 In other words, interesting email scenarios can involve three 457 distinct architectural layers of store-and-forward service: 459 * User Mediators 461 * MHS Relays 463 * Packet Switches 465 with the bottom-most usually being the Internet's IP service. The 466 most basic email scenarios involve Relays and Switches. 468 Aborting a message transfer results in having the Relay become an 469 Originator and send an error message to the Bounce address. (The 470 potential for looping is avoided by having this message, itself, 471 contain no Bounce address.) 473 2.2.4. Gateway 475 A Gateway is a hybrid form of User and Relay that interconnects 476 heterogeneous mail services. Its purpose is simply to emulate a 477 Relay and the closer it comes to this, the better. However it 478 operates at the User level, because it MUST be able to modify message 479 content. 481 Differences between mail services can be as small as minor syntax 482 variations, but usually encompass significant, semantic distinctions. 483 One difference could have the concept of an email address be a 484 hierarchical, machine-specific address versus have it be a flat, 485 global name space. Another difference could be between text-only 486 content, versus multi-media. Hence the Relay function in a Gateway 487 offers significant design challenges, to make the result be as 488 seamless as possible. The more significant challenge is in ensuring 489 the user-to-user functionality that matches syntax and semantics of 490 independent email standards suites. 492 The basic test of a Gateway's adequacy is, of course, whether an 493 Originator on one side of a Gateway can send a message to a Recipient 494 on the other side, without requiring changes to any of the components 495 in the Originator's or Recipient's mail services, other than adding 496 the Gateway. To each of these otherwise independent services, the 497 Gateway will appear to be a "native" participant. However the 498 ultimate test of a Gateway's adequacy is whether the Originator and 499 Recipient can sustain a dialogue. In particular can a Recipient's 500 MUA automatically formulate a valid Reply that will reach the initial 501 Originator? 503 2.3. Administrative Actors 505 Operation of Internet Mail services is apportioned to different 506 providers (or operators). Each can be an independent ADministrative 507 Management Domain (ADMD). Examples include an end-user operating 508 their desktop client, a department operating a local Relay, an IT 509 department operating an enterprise Relay and an ISP operating a 510 public shared email service. These can be configured into many 511 combinations of administrative and operational relationships, with 512 each ADMD potentially having a complex arrangement of functional 513 components. Figure 4 depicts the relationships among ADMDs. Perhaps 514 the most salient aspect of an ADMD is the differential trust that 515 determines its policies for activities within the ADMD, versus those 516 involving interactions with other ADMDs. The architectural impact of 517 needing to have boundaries between ADMD's is discussed in [Tussle]. 519 Basic types of ADMDs include: 521 Edge: Independent transfer services, in networks at the edge of the 522 open Internet Mail service. 524 User: End-user services. This might be subsumed under the Edge 525 service, such as is common for web-based email access. 527 Transit: These are Mail Service Providers (MSP) offering value- 528 added capabilities for Edge ADMDs, such as aggregation and 529 filtering. 531 Note that Transit services are quite different from packet-level 532 transit operation. Whereas end-to-end packet transfers usually go 533 through intermediate routers, email exchange across the open Internet 534 is often directly between the Boundary MTAs of Edge ADMDs, at the 535 email level. 537 +-------+ +------+ +-------+ 538 | ADMD1 | | ADMD3 | | ADMD4 | 539 | ----- | | ----- | | ----- | 540 | | +---------------------->| | | | 541 | User | | |-Edge--+--->|-User | 542 | | | | +--->| | | | 543 | V | | | +-------+ +-------+ 544 | Edge--+---+ | 545 | | | +---------+ | 546 +-------+ | | ADMD2 | | 547 | | ----- | | 548 | | | | 549 +--->|-Transit-+---+ 550 | | 551 +---------+ 553 Figure 4: ADministrative Management Domains (ADMD) Example 555 Edge networks can use proprietary email standards internally. 556 However the distinction between Transit network and Edge network 557 transfer services is primarily significant because it highlights the 558 need for concern over interaction and protection between independent 559 administrations. In particular this distinction calls for additional 560 care in assessing transitions of responsibility, as well as the 561 accountability and authorization relationships among participants in 562 email transfer. 564 The interactions between functional components within an ADMD are 565 subject to the policies of that domain. Policies can cover such 566 things as reliability, access control, accountability and even 567 content evaluation and modification. They can be implemented in 568 different functional components, according to the needs of the ADMD. 569 For example see [ID-spamops]. 571 User, Edge and Transit services can be offered by providers that 572 operate component services or sets of services. Further it is 573 possible for one ADMD to host services for other ADMDs. Common ADMD 574 examples are: 576 Enterprise Service Providers: 578 Operating an organization's internal data and/or mail services. 580 Internet Service Providers: 582 Operating underlying data communication services that, in turn, 583 are used by one or more Relays and Users. It is not necessarily 584 their job to perform email functions, but they can, instead, 585 provide an environment in which those functions can be performed. 587 Mail Service Providers: 589 Operating email services, such as for end-users, or mailing lists. 591 Operational pragmatics often dictate that providers be involved in 592 detailed administration and enforcement issues, to help ensure the 593 health of the overall Internet Mail Service. This can include 594 operators of lower-level packet services. 596 3. Identities 598 Internet Mail uses three forms of identity. The most common is the 599 end-point mailbox address . [RFC2822] Also see the 600 related usage for
and in [RFC2821]. The other 601 two forms of email identity are the domain name Section 3.2 602 and message identifier [RFC2822]. 604 3.1. Mailbox 606 "A mailbox sends and receives mail. It is a conceptual entity 607 which does not necessarily pertain to file storage." [RFC2822] 609 A mailbox is specified as an Internet Mail address . It 610 has two distinct parts, divided by an at-sign ("@"). The right-hand 611 side is a globally interpreted domain name that is part of an Common 612 Operating Group. Domain Names are discussed in Section 3.2. Formal 613 Internet Mail addressing syntax can support source routes, to 614 indicate the path through which a message should be sent. Although 615 legal, the use of source routes is not part of the modern Internet 616 Mail service and it is ignored in the rest of this document. 618 The portion to the left of the at-sign contains a string that is 619 globally opaque and is called the . It is to be 620 interpreted only by the entity specified in the address's right-hand 621 side. All other entities MUST treat the local-part as a 622 uninterpreted literal string and MUST preserve all of its original 623 details. As such its public distribution is equivalent to sending a 624 "cookie" that is only interpreted upon being returned to its 625 originator. 627 3.1.1. Global Standards for Local-Part 629 It is common for sites to have local structuring conventions for the 630 left-hand side (local-part) of an addr-spec. This permits sub- 631 addressing, such as for distinguishing different discussion groups by 632 the same participant. However it is worth stressing that these 633 conventions are strictly private to the user's organization and MUST 634 not be interpreted by any domain except the one listed in the right- 635 hand side of the addr-spec, and those specialized services conforming 636 to standardized conventions, as noted in the next paragraph. 638 A small class of addresses has an elaboration on basic email 639 addressing, with a standardized, global schema for the local-part. 640 These are conventions between originating end-systems and Recipient 641 Gateways, and they are invisible to the public email transfer 642 infrastructure. When an Originator is explicitly sending via a 643 Gateway out of the Internet, there are coding conventions for the 644 local-part, so that the Originator can formulate instructions for the 645 Gateway. Standardized examples of this are the telephone numbering 646 formats for VPIM [RFC2421], such as "+16137637582@vpim.example.com", 647 and iFax [RFC2304], such as 648 "FAX=+12027653000/T33S=1387@ifax.example.com". 650 3.1.2. Scope of Email Address Use 652 Email addresses are being used far beyond their original email 653 transfer and delivery role. In practical terms, email strings have 654 become a common form of user identity on the Internet. What is 655 essential, then, is to be clear about the nature and role of an 656 identity string in a particular context and to be clear about the 657 entity responsible for setting that string. 659 3.2. Domain Names 661 A domain name is a global reference to an Internet resource, such as 662 a host, a service or a network. A name usually maps to one or more 663 IP Addresses. Conceptually the name might encompass an entire 664 organization, or a collection of machines integrated into a 665 homogeneous service, or only a single machine. A domain name can be 666 administered to refer to individual users, but this is not common 667 practice. The name is structured as a hierarchical sequence of sub- 668 names, separated by dots ("."). Domain names are defined and 669 operated through the Domain Name Service (DNS) [RFC1034], [RFC1035], 670 [RFC2181]. 672 When not part of a mailbox address, a domain name is used in Internet 673 Mail to refer to the ADMD or the host that took action upon the 674 message, such as providing the administrative scope for a message 675 identifier, or performing transfer processing. 677 3.3. Message Identifier 679 There are two standardized tags, for identifying messages. 681 Message-ID: 683 The Message-ID is a user-level tag, primarily used for threading 684 and elimination of duplicates and is specified in [RFC2822]. It 685 is associated with the RFC2822.From, although any actor within the 686 originating ADMD might assign it. The recipient's ADMD is the 687 intended consumer of the Message-ID, although any actor along the 688 transmission path might use it. Internet Mail standards provide 689 for a single Message-ID; however more than one is sometimes 690 assigned. 692 Like a mailbox address, a Message-ID has two distinct parts, 693 divided by an at-sign ("@"). The right-hand side is globally 694 interpreted and specifies the ADMD or host assigning the 695 identifier. The left-hand side contains a string that is globally 696 opaque and serves to uniquely identify the message within the 697 domain referenced on the right-hand side. The duration of 698 uniqueness for the message identifier is undefined. 700 When a message is revised in any way, the question of whether to 701 assign a new Message-ID requires a subjective assessment, deciding 702 whether the editorial content has been changed enough to 703 constitute a new message. [RFC2822] says "a message identifier 704 pertains to exactly one instantiation of a particular message; 705 subsequent revisions to the message each receive new message 706 identifiers." However real-world experience dictates some 707 flexibility. An impossible test is whether the recipient will 708 consider the new message to be equivalent to the old. For most 709 components of Internet Mail, there is no way to predict a specific 710 recipient's preferences on this matter. Both creating and failing 711 to create a new Message-ID have their downsides. 713 The best that can be offered, here, are some guidelines and 714 examples: 716 * If a message is changed only in terms of form, such as 717 character-encoding, it clearly is still the same message. 719 * If a message has minor additions to the content, such as a 720 mailing list tag at the beginning of the RFC2822.Subject header 721 field, or some mailing list administrative information added to 722 the end of the primary body-part's text, then it probably is 723 still the same message. 725 * If a message has viruses deleted from it, it probably is still 726 the same message. 728 * If a message has offensive words deleted from it, then some 729 recipients will consider it the same message, but some will 730 not. 732 * If a message is translated into a different language, then some 733 recipients will consider it the same message, but some will 734 not. 736 The absence of objective, precise criteria for Message-ID re- 737 generation, along with the absence of strong protection associated 738 with the string, means that the presence of an ID can permit an 739 assessment that is marginally better than a heuristic, but the ID 740 certainly has no value for strict formal reference or comparison. 741 Hence it is not appropriate to use the Message-ID for any process 742 that might be called "security". 744 ENVID: 746 The ENVID (envelope identifier) is an envelope-level tag, 747 primarily for use within Delivery Status Notifications, so that 748 the Bounce Address (RFC2821.MailFrom) recipient can correlate the 749 DSN with a particular message. The ENVID is therefore used from 750 one message posting, until the directly-resulting message 751 deliveries. It does not survive re-postings [RFC3461]. 753 The format of an ENVID is free-form. Although its creator might 754 choose to impose structure on the string, none is imposed by 755 Internet standards. By implication, the scope of the string is 756 defined by the domain name of the Bounce Address. 758 4. Services and Standards 760 The Internet's Mail architecture distinguishes among six different 761 types of functional components, arranged to support a store-and- 762 forward service architecture: 764 * Message 766 * Mail User Agent (MUA) 768 * Message Submission Agent (MSA) 770 * Message Transfer Agent (MTA) 772 * Message Delivery Agent (MDA) 774 * Message Store (MS) 776 This section describes each functional component for Internet Mail, 777 and the standards-based protocols that are associated with their 778 operation. 780 Software implementations of these architectural components often 781 compress them, such as having the same software do MSA, MTA and MDA 782 functions. However the requirements for each of these components of 783 the service are becoming more extensive. So their separation is 784 increasingly common. 786 NOTE: 788 A discussion about any interesting system architecture is often 789 complicated by confusion between architecture versus 790 implementation. An architecture defines the conceptual functions 791 of a service, divided into discrete conceptual modules. An 792 implementation of that architecture can combine or separate 793 architectural components, as needed for a particular operational 794 environment. It is important not to confuse the engineering 795 decisions that are made to implement a product, with the 796 architectural abstractions used to define conceptual functions. 798 The following figure shows function modules and the standardized 799 protocols used between them. Additional protocols and configurations 800 are possible. Boxes defined by asterisks (*) represent functions 801 that often are distributed among two or more systems. 803 +------+ +---------+ 804 ............+ oMUA |...................................| Disp | 805 . +--+-+-+ +---------+ 806 . ******* imap}| | ^ 807 . * oMS *<-----+ | {smtp,submission | 808 . *******local} | | 809 . | ***************** | 810 . +------V-----*------------+ *MHS | 811 . | +------+ * +------+ | * +---------+ | 812 . | | oMSA +---O-->| hMSA | |..*......| Bounces | | 813 . | +------+ * +--+---+ | * +---------+ | 814 . +------------*------+-----+ * ^ | 815 . MSA * V {smtp * | | 816 /+==========+\ * +------+ * /+===+===+\ | 817 || MESSAGE || * | MTA | * || dsn || | 818 ||----------|| * +--+---+ * \+=======+/ | 819 || Envelope || * . {smtp * ^ ^ | 820 || SMTP || * V * | | | 821 || RFC2822 || * +------+ * | | /+==+==+\ 822 || Content || * | MTA +----*---------+ | || mdn || 823 || RFC2822 || * +--+---+ * | \+=====+/ 824 || MIME || * smtp}| {local * | | 825 \+==========+/ MDA * | {lmtp * | | 826 . +------------+------V-----+ * | | 827 . | +------+ * +------+ | * | | 828 . | | | * | | +--*-------------+ | 829 . | | rMDA |<--O---+ hMDA | | * | 830 . | | | * | | |<-*-----------+ | 831 . | +-+----+ * +------+ | * | | 832 . +---+--+-----*------------+ * | | 833 . | | ***************** | | 834 . pop} +--+ +-+ | | 835 . imap} | | {local | | 836 . ****************V******* | | 837 . * | +------+ *rMS /+===+===+\ | 838 . * | | srMS | * || sieve || | 839 . * V +----+-+ * \+=======+/ | 840 . * +------+ pop}| | * ^ | 841 . * | urMS |<-----+ | * | | 842 . * +--+---+ imap} | * | | 843 . ************************ | | 844 . | | | | 845 . local} | | {pop, | | 846 . | +------+ | {imap | | 847 . +->| |<-+ | | 848 ...........>| rMUA +-------------------------------+ | 849 | +----------------------------------------+ 850 +------+ 851 Figure 5: Protocols and Services 853 4.1. Message Data 855 The purpose of the Mail Handling Service (MHS) is to exchange a 856 message object among participants [RFC2822] [RFC0822]. Hence all of 857 its underlying mechanisms are merely in the service of getting that 858 message from its Originator to its Recipients. A message can be 859 explicitly labeled as to its nature [RFC3458]. 861 A message comprises a transit handling envelope and the end-user 862 message content. The envelope contains handling information used by 863 the MHS, or generated by it. The content is divided into a 864 structured header and the body. The body may be unstructured simple 865 lines of text, or it may be a tree of multi-media subordinate 866 objects, called body-parts, or attachments. 868 Internet Mail has some special control data: 870 Delivery Status Notification (DSN): 872 A Delivery Status Notification (DSN) is a message that can be 873 generated by the MHS (MSA, MTA or MDA) and sent to the 874 RFC2821.MailFrom address. The mailbox for this is shown as 875 Bounces in Figure 5. It provides information about message 876 transit, such as transmission errors or successful delivery. 877 [RFC3461] 879 Message Disposition Notification (MDN): 881 A Message Disposition Notification (MDN) is a message that can be 882 generated by an rMUA and is sent to the 883 Disposition-Notification-To address(es). The mailbox for this is 884 shown as Disp in Figure 5. It provides information about user- 885 level, Recipient-side message processing, such as indicating that 886 the message has been displayed [RFC3798] or the form of content 887 that can be supported. [RFC3297] 889 Message Filtering (SIEVE): 891 SIEVE is a scripting language that permits specifying conditions 892 for differential handling of mail, typically at the time of 893 delivery [RFC3028]. It can be conveyed in a variety of ways, as a 894 MIME part. Figure 5 shows a Sieve specification going from the 895 rMUA to the MDA. However filtering can be done at many different 896 points along the transit path and any one or more of them might be 897 subject to Sieve directives, especially within a single ADMD. 898 Hence the Figure shows only one relationship, for (relative) 899 simplicity. 901 4.1.1. Envelope 903 Information that is directly used by, or produced by, the MHS is 904 called the "envelope". It controls and records handling activities 905 by the transfer service. Internet Mail has a fragmented framework 906 for handling this "handling" information. The envelope exists partly 907 in the transfer protocol SMTP [RFC2821] and partly in the message 908 object [RFC2822]. The SMTP specification uses the term to refer only 909 to the transfer-protocol information. 911 NOTE: 913 Due to the frequent use of the term "envelope" to refer only to 914 SMTP constructs, there has been some call for using a different 915 term, to label the larger set of information defined here. So 916 far, no alternative term has developed any community support. 918 Direct envelope addressing information, as well as optional transfer 919 directives, are carried within the SMTP control channel. Other 920 envelope information, such as trace records, is carried within the 921 message object header fields. Upon delivery, some SMTP-level 922 envelope information is typically encoded within additional message 923 object header fields, such as Return-Path. 925 4.1.2. Header Fields 927 Header fields are attribute name/value pairs covering an extensible 928 range of email service, user content and user transaction meta- 929 information. The core set of header fields is defined in [RFC2822], 930 [RFC0822]. It is common to extend this set, for different 931 applications. Procedures for registering header fields are defined 932 in [RFC4021]. An extensive set of existing header field 933 registrations is provided in [RFC3864]. 935 One danger with placing additional information in header fields is 936 that Gateways often alter or delete them. 938 4.1.3. Body 940 The body of a message might simply be lines of ASCII text or it might 941 be hierarchically structured into a composition of multi-media body- 942 part attachments, using MIME [RFC2045], [RFC2046], [RFC2047], 943 [RFC2048], and [RFC2049]. MIME structures each body-part into a 944 recursive set of MIME header field meta-data and MIME Content 945 sections. 947 4.1.4. Identity References in a Message 949 For a message in transit, the core uses of identity references 950 combine into: 952 +-----------------------+-------------+---------------------+ 953 | Layer | Field | Set By | 954 +-----------------------+-------------+---------------------+ 955 | Message Body | MIME Header | Originator | 956 | Message header fields | From | Originator | 957 | | Sender | Source | 958 | | Reply-To | Originator | 959 | | To, CC, BCC | Originator | 960 | | Message-ID | Source | 961 | | Received | Source, Relay, Dest | 962 | | Return-Path | MDA, from MailFrom | 963 | | Resent-* | Mediator | 964 | SMTP | HELO | Latest Relay Client | 965 | | MailFrom | Source | 966 | | RcptTo | Originator | 967 | IP | IP Address | Latest Relay Client | 968 +-----------------------+-------------+---------------------+ 970 Layered Identities 972 4.2. User-Level Services 974 Interactions at the user level entail protocol exchanges, distinct 975 from those that occur at lower layers of the Internet Mail 976 architecture, which is above the Internet Transport layer. Because 977 the motivation for email, and much of its use, is for interaction 978 among humans, the nature and details of these protocol exchanges 979 often are determined by the needs of human and group communication. 980 In terms of efforts to specify behaviors, one effect of this is to 981 require subjective guidelines, rather than strict rules, for some 982 aspects of system behavior. Mailing Lists provide particularly 983 salient examples of this. 985 4.2.1. Mail User Agent (MUA) 987 A Mail User Agent (MUA) works on behalf of end-users and end-user 988 applications. It is their "representative" within the email service. 990 The Origination-side MUA (oMUA) creates a message and performs 991 initial "submission" into the transfer infrastructure, via a Mail 992 Submission Agent (MSA). It can also perform any creation- and 993 posting-time archival in its Message Store (oMS). An MUA's oMS will 994 typically include a folder for messages under development (Drafts), a 995 folder for messages waiting to be sent (Queued or Unsent) and a 996 folder for messages that have been successfully posted for 997 transmission (Sent). 999 The Recipient-side MUA (rMUA) works on behalf of the end-user 1000 Recipient to process received mail. This includes generating user- 1001 level return control messages, displaying and disposing of the 1002 received message, and closing or expanding the user communication 1003 loop, by initiating replies and forwarding new messages. 1005 NOTE: Although not shown in Figure 5, an MUA can, itself, have a 1006 distributed implementation, such as a "thin" user interface module 1007 on a limited end-user device, with the bulk of the MUA 1008 functionality operated remotely on a more capable server. An 1009 example of such an architecture might use IMAP [RFC3501] for most 1010 of the interactions between an MUA client and an MUA server. A 1011 standardized approach for such scenarios is defined by [RFC4550]. 1013 A Mediator is special class of MUA. It performs message re-posting, 1014 as discussed in Section 2.1. 1016 Identity fields relevant to the MUA include: 1018 RFC2822.From 1020 Set by: Originator 1022 Names and addresses for author(s) of the message content are 1023 listed in the From field 1025 RFC2822.Reply-To 1027 Set by: Originator 1029 If a message Recipient sends a reply message that would otherwise 1030 use the RFC2822.From field address(es) contained in the original 1031 message, then they are instead to use the address(es) in the 1032 RFC2822.Reply-To field. In other words this field is a direct 1033 override of the From field, for responses from Recipients. 1035 RFC2822.Sender 1037 Set by: Source 1039 This specifies the address responsible for submitting the message 1040 into the transfer service. For efficiency this field can be 1041 omitted if it contains the same address as RFC2822.From. However 1042 this does not mean there is no Sender specified. Rather it means 1043 that that header field is virtual and that the address in the From 1044 field MUST be used. Specification of the error return addresses 1045 -- the "Bounce" address, contained in RFC2821.MailFrom -- is made 1046 by the RFC2822.Sender. Typically the Bounce address is the same 1047 as the Sender address. However some usage scenarios require it to 1048 be different. 1050 RFC2822.To, RFC2822.CC 1052 Set by: Originator 1054 These specify MUA Recipient addresses. The addresses in the 1055 fields might not be present in the RFC2821.RcptTo command. The 1056 distinction between To and CC is subjective. Generally a To 1057 addressee is considered primary and is expected to take action on 1058 the message. A CC addressee typically receives a copy only for 1059 their information. 1061 RFC2822.BCC 1063 Set by: Originator 1065 A message might be copied to an addressee whose participation is 1066 not to be disclosed to the RFC2822.To or RFC2822.CC Recipients 1067 and, usually, not to the other BCC Recipients. The BCC header 1068 field indicates a message copy to such a Recipient. Typically, 1069 the field lists no addresses or only lists the address of the 1070 Recipient receiving this copy. An MUA will typically make 1071 separate postings for TO and CC Recipients, versus BCC Recipients. 1072 The former will see no indication that any BCCs were sent, whereas 1073 the latter have a BCC field present. It might be empty, contain a 1074 comment, or contain one or more BCC addresses, depending upon the 1075 preferences of the Originator. 1077 4.2.2. Message Store (MS) 1079 An MUA can employ a long-term Message Store (MS). Figure 5 depicts 1080 an Origination-side Ms (oMS) and a Recipient-side MS (rMS). There is 1081 a rich set of choices for configuring a store, because any MS may 1082 comprise a distributed set of component stores. In Figure 5, the rMS 1083 demonstrates this by showing an rMS that is located on a remote 1084 server (srMS) and an rMS that is on the same machine as the MUA 1085 (urMS). The relationship between two message stores, themselves, can 1086 vary. 1088 The operational relationship among MSs can be: 1090 Online: 1092 Only a remote MS is used, with messages being accessible only when 1093 the MUA is attached to the MS, and the MUA repeatedly fetches all 1094 or part of a message, from one session to the next. 1096 Offline: 1098 The MS is local to the user, and messages are completely moved 1099 from any remote store, rather than (also) being retained there. 1101 Disconnected: 1103 An rMS and a uMS are kept synchronized, for all or part of their 1104 contents, while there is a connection between them. While they 1105 are disconnected, mail can continue to arrive at the rMS and the 1106 user may continue to make changes to the uMS. Upon reconnections, 1107 the two stores are re-synchronized. 1109 4.3. MHS-Level Services 1111 4.3.1. Mail Submission Agent (MSA) 1113 A Mail Submission Agent (MSA) accepts the message submission from the 1114 oMUA and enforces the policies of the hosting ADMD and the 1115 requirements of Internet standards. An MSA represents an unusual 1116 functional dichotomy. A portion of its task is to represent MUA 1117 (uMSA) interests during message posting, to facilitate posting 1118 success, and another portion is to represent MHS (hMSA) interests. 1119 This is best modeled, as shown in Figure 5, with two sub-components, 1120 one for the oMUA (oMSA) and one for the MHS (hMSA) 1122 The hMSA's function is to take transit responsibility for a message 1123 that conforms to the relevant Internet standards and to local site 1124 policies. It rejects messages that are not in conformance. The 1125 oMSA's is to perform final message preparation for submission and to 1126 effect the transfer of responsibility to the MHS, via the hMSA. The 1127 amount of preparation will depend upon the local implementations. 1128 Examples of oMSA tasks could be to add header fields, such as Date: 1129 and Message-ID, to modify portions of the message from local 1130 notations to Internet standards, such as expanding an address to its 1131 formal RFC2822 representation. 1133 Historically, standards-based MUA/MSA interactions have used SMTP 1134 [RFC2821]. A recent alternative is SUBMISSION [RFC2476]. Although 1135 SUBMISSION derives from SMTP, it uses a separate TCP port and imposes 1136 distinct requirements, such as access authorization. 1138 Identities relevant to the MSA include: 1140 RFC2821.HELO/.EHLO 1142 Set by: Source 1144 The MSA can specify its hosting domain identity for the SMTP HELO 1145 or EHLO command operation. 1147 RFC2821.MailFrom 1149 Set by: Mediator or Originator Source 1151 This is an end-to-end string that specifies an email address for 1152 receiving return control information, such as "bounces". The name 1153 of this field is misleading, because it is not required to specify 1154 either the author or the agent responsible for submitting the 1155 message. Rather, the agent responsible for submission specifies 1156 the RFC2821.MailFrom address. Ultimately the simple basis for 1157 deciding what address needs to be in the RFC2821.MailFrom is to 1158 determine what address needs to be informed about transmission- 1159 level problems (and, possibly, successes.) 1161 RFC2821.RcptTo 1163 Set by: Originator 1165 This specifies the MUA mailbox address of a recipient. The string 1166 might not be visible in the message content header. For example, 1167 the message destination address header fields, such as RFC2822.To, 1168 might specify a mailing list address, while the RFC2821.RcptTo 1169 address specifies a member of that list. 1171 RFC2821.Received 1173 Set by: Originator Source 1175 An MSA can record a Received header field, to indicate initial 1176 submission trace information, including originating host and MSA 1177 host domain names and/or IP Addresses. 1179 4.3.2. Mail Transfer Agent (MTA) 1181 A Mail Transfer Agent (MTA) relays mail for one application-level 1182 "hop". It is like a packet-switch or IP router in that its job is to 1183 make routing assessments and to move the message closer to the 1184 Recipient(s). Relaying is performed by a sequence of MTAs, until the 1185 message reaches its destination MDA(s). Hence an MTA implements both 1186 client and server MTA functionality. It does not make changes to 1187 addresses in the envelope or reformulate the editorial content. 1188 Hence a change in data form, such as to the MIME Content-Transfer- 1189 Encoding, is within the purview of an MTA, whereas removal or 1190 replacement of body content is not. Also it can add trace 1191 information. Of course email objects are typically much larger than 1192 the payload of a packet or datagram, and the end-to-end latencies are 1193 typically much higher. 1195 Internet Mail primarily uses SMTP [RFC2821], [RFC0821] to effect 1196 point-to-point transfers between peer MTAs. Other transfer 1197 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1198 most network layer mechanisms, Internet Mail's SMTP supports a basic 1199 level of reliability, by virtue of providing for retransmission after 1200 a temporary transfer failure. Contrary to typical packet switches 1201 (and Instant Messaging services) Internet Mail MTAs typically store 1202 messages in a manner that allows recovery across service 1203 interruptions, such as host system shutdown. However the degree of 1204 such robustness and persistence by an MTA can be highly variable. 1206 The primary "routing" mechanism for Internet Mail is the DNS MX 1207 record [RFC1035], which specifies a host through which the queried 1208 domain can be reached. This presumes a public -- or at least a 1209 common -- backbone that permits any attached host to connect to any 1210 other. 1212 Identities relevant to the MTA include: 1214 RFC2821.HELO/.EHLO 1216 Set by: Relay 1218 The MTA can specify its hosting domain identity for the SMTP HELO 1219 or EHLO command. This is the only standardized way of identifying 1220 the agent responsible for operation of the Relay, during the 1221 transfer operation. 1223 RFC2821.MailFrom 1225 Set by: Originator or Mediator Source 1227 This is an MHS end-to-end string that specifies an email address 1228 for receiving return control Bounce, such as delivery 1229 confirmations and error notices. The protocol name of this field 1230 is misleading, because it is not required to specify either the 1231 author or the agent responsible for submitting the message. 1232 Rather the agent responsible for submission specifies the MailFrom 1233 address. Ultimately the simple basis for deciding what address 1234 needs to be in the RFC2821.MailFrom is to determine what address 1235 needs to be informed about transmission-level problems (and, 1236 possibly, successes.) 1238 RFC2821.RcptTo 1240 Set by: Originator 1242 This specifies the MUA mailbox address of a Recipient. The string 1243 might not be visible in the message content header. For example 1244 the message destination address header fields, such as RFC2822.To, 1245 might specify a mailing list address, while the RFC2821.RcptTo 1246 address specifies a member of that list. 1248 RFC2822.Received 1250 Set by: Relay 1252 An MTA can record a Received header field, to indicate trace 1253 information, including source host and receiving host domain names 1254 and/or IP Addresses. 1256 4.3.3. Mail Delivery Agent (MDA) 1258 A Mail Delivery Agent (MDA) delivers email to the Recipient's 1259 mailbox. It can provide distinctive, address-based functionality, 1260 made possible by its detailed knowledge of the properties of the 1261 destination address. This knowledge might also be present elsewhere 1262 in the Recipient's ADMD, such as at an organizational border 1263 (Boundary) Relay. However it is required for the MDA, if only 1264 because the MDA must know where to deliver the message. 1266 As with an MSA, an MDA serves two roles, as depicted in Figure 5. 1267 Formal transfer of responsibility, called "delivery" is effected 1268 between the two components that embody these roles. The MHS portion 1269 (hMDA) primarily functions as a server SMTP engine. A common 1270 additional role is to re-direct the message to an alternative 1271 address, as specified by the recipient addressee's preferences. The 1272 job of the recipient portion of the MDA (rMDA) is to perform any 1273 delivery-actions are desired by the recipient. 1275 Using Internet protocols, delivery can be effected by a variety of 1276 standard protocols. When coupled with an internal local mechanism, 1277 SMTP [RFC2821] and LMTP [RFC2033] permit "push" delivery to the 1278 Recipient system, at the initiative of the upstream email service. 1279 POP [RFC1939] and IMAP [RFC3501] are used for "pull" delivery at the 1280 initiative of the Recipient system. POP and IMAP can also be used 1281 for repeated access to messages on a remote MS. 1283 Identities relevant to the MDA include: 1285 RFC2821.Return-Path 1287 Set by: Source 1289 The MDA records the RFC2821.MailFrom address into the 1290 RFC2822.Return-Path field. 1292 RFC2822.Received 1294 Set by: Destination 1296 An MDA can record a Received header field, to indicate trace 1297 information, including source host and receiving host domain names 1298 and/or IP Addresses. 1300 5. Mediators 1302 Basic email transfer from an Originator to the specified Recipients 1303 is accomplished by using an asynchronous, store-and-forward 1304 communication infrastructure, in a sequence of independent 1305 transmissions through some number of MTAs. A very different task is 1306 a User-level sequence of postings and deliveries, through Mediators. 1307 A Mediator forwards a message, through a re-posting process. The 1308 Mediator does share some functionality with basic MTA relaying, but 1309 it enjoys a degree of freedom with both addressing and content that 1310 is not available to MTAs. 1312 RFC2821.HELO/.EHLO 1314 Set by: Mediator Source 1316 The MSA can specify its hosting domain identity for the SMTP HELO 1317 or EHLO command operation. 1319 RFC2821.MailFrom 1321 Set by: Originator or Mediator Source 1323 This is an end-to-end string that specifies an email address for 1324 receiving return control Bounces. The name of this field is 1325 misleading, because it is not required to specify either the 1326 author or the agent responsible for submitting the message. 1327 Rather the agent responsible for submission specifies the 1328 RFC2821.MailFrom address. Ultimately the simple basis for 1329 deciding what address needs to be in the RFC2821.MailFrom is to 1330 determine what address needs to be informed about transmission- 1331 level problems (and, possibly, successes.) 1333 RFC2821.RcptTo 1335 Set by: Mediator 1337 This specifies the MUA mailbox address of a Recipient. The string 1338 might not be visible in the message content header. For example, 1339 the message destination address header fields, such as RFC2822.To, 1340 might specify a mailing list address, while the RFC2821.RcptTo 1341 address specifies a member of that list. 1343 RFC2821.Received 1345 Set by: Mediator 1347 An MSA can record a Received header field, to indicate initial 1348 submission trace information, including originating host and MSA 1349 host domain names and/or IP Addresses. 1351 The salient aspect of a Mediator, that distinguishes it from any 1352 other MUA creating an entirely new message, is that a Mediator 1353 preserves the integrity and tone of the original message, including 1354 the essential aspects of the original origination information. The 1355 Mediator might also add commentary. 1357 Examples of MUA message creation that are NOT performed by Mediators 1358 include -- 1360 New message that forwards an existing message: 1362 This action rather curiously provides a basic template for a class 1363 of Mediators. However for its typical occurrence it is not itself 1364 an example of a Mediator. The new message is viewed as being from 1365 the Agent doing the forwarding, rather than being from the 1366 original Originator. 1368 A new message encapsulates the original message and is seen as 1369 strictly "from" the Mediator. The Mediator might add commentary 1370 and certainly has the opportunity to modify the original message 1371 content. The forwarded message is therefore independent of the 1372 original message exchange and creates a new message dialogue. 1373 However the final Recipient sees the contained message as from the 1374 original Originator. 1376 Reply: 1378 When a Recipient formulates a response back to the original 1379 message's author, the new message is not typically viewed as being 1380 a "forwarding" of the original. Its focus is the new content, 1381 although it might contain all or part of the material in the 1382 original message. Therefore the earlier material is merely 1383 contextual and secondary. 1385 Annotator: 1387 The integrity of the original message is usually preserved, but 1388 one or more comments about the message are added in a manner that 1389 distinguishes commentary from original text. The tone of the new 1390 message is that it is primarily commentary from a new Originator, 1391 similar to a Reply. 1393 The remainder of this section describes common examples of Mediators. 1395 5.1. Aliasing 1397 Aliasing is a simple re-addressing facility, available in most MDA 1398 implementations. It is performed just before delivering a message to 1399 the specified Recipient's mailbox. Instead the message is submitted 1400 back to the transfer service, for delivery to one or more alternate 1401 addresses. Although implemented as part of the message delivery 1402 service, this facility is strictly a Recipient user function. It 1403 resubmits the message, replacing the envelope address, on behalf of 1404 the mailbox address that was listed in the envelope. 1406 What is most distinctive about this forwarding mechanism is how 1407 closely it compares to normal MTA store-and-forward Relaying. Its 1408 only interesting difference is that it changes the RFC2821.RcptTo 1409 value. Having the change be this small makes it easy to view 1410 aliasing as a part of the lower-level mail relaying activity. 1411 However the small change has a large semantic impact: The designated 1412 recipient has chosen a new recipient. 1414 Hence that original recipient SHOULD become responsible for any 1415 handling issues. This change would be reflected by replacing the 1416 message's RFC2821.MailFrom address to be one within the scope of the 1417 ADMD doing the aliasing. 1419 An MDA that is re-posting a message to an alias typically changes 1420 only envelope information: 1422 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1424 Set by: Originator 1426 These retain their original addresses. 1428 RFC2821.RcptTo 1430 Set by: Mediator 1432 This field contains an alias address. 1434 RFC2821.MailFrom 1436 Set by: Originator or Mediator Originator or Mediator Source 1438 The agent responsible for submission to an alias address will 1439 often retain the original address to receive handling Bounces. 1440 The benefit of retaining the original MailFrom value is to ensure 1441 that the origination-side agent knows that there has been a 1442 delivery problem. On the other hand, the responsibility for the 1443 problem usually lies with the Recipient, since the Alias mechanism 1444 is strictly under the Recipient's control. 1446 RFC2821.Received 1448 Set by: Mediator 1450 The agent can record Received information, to indicate the 1451 delivery to the original address and submission to the alias 1452 address. The trace of Received header fields can therefore 1453 include everything from original posting through final delivery to 1454 the alias. 1456 5.2. Re-Sending 1458 Also called Re-Directing, Re-Sending differs from Forwarding by 1459 virtue of having the Mediator "splice" a message's addressing 1460 information, to connect the Originator of the original message and 1461 the Recipient of the new message. This permits them to have direct 1462 exchange, using their normal MUA Reply functions. Hence the new 1463 Recipient sees the message as being From the original Originator, 1464 even if the Mediator adds commentary. 1466 Identities specified in a resent message include 1467 RFC2822.From 1469 Set by: original Originator 1471 Names and email addresses for the original author(s) of the 1472 message content are retained. The free-form (display-name) 1473 portion of the address might be modified to provide informal 1474 reference to the agent responsible for the redirection. 1476 RFC2822.Reply-To 1478 Set by: original Originator 1480 If this field is present in the original message, it is retained 1481 in the Resent message. 1483 RFC2822.Sender 1485 Set by: Originator or Mediator Originator or Mediator Source 1487 This field is expected to contain the original Sender value. 1489 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1491 Set by: original Originator 1493 These specify the original message Recipients. 1495 RFC2822.Resent-From 1497 Set by: Mediator 1499 The address of the original Recipient who is redirecting the 1500 message. Otherwise the same rules apply for the Resent-From field 1501 as for an original RFC2822.From field 1503 RFC2822.Resent-Sender 1505 Set by: Mediator 1507 The address of the agent responsible for re-submitting the 1508 message. For efficiency this field is often omitted if it 1509 contains the same address as RFC2822.Resent-From. However this 1510 does not mean there is no Resend-Sender specified. Rather it 1511 means that that header field is virtual and that the address in 1512 the Resent-From field MUST be used. Specification of the error 1513 return addresses (the Notification address, contained in 1514 RFC2821.MailFrom) is made by the Resent-Sender. Typically the 1515 Bounce address is the same as the Resent-Sender address. However 1516 some usage scenarios require it to be different. 1518 RFC2822.Resent-To, RFC2822.Resent-cc, RFC2822.Resent-bcc: 1520 Set by: Mediator 1522 The addresses of the new Recipients who will now be able to reply 1523 to the original author. 1525 RFC2821.MailFrom 1527 Set by: Mediator 1529 The agent responsible for re-submission (RFC2822.Resent-Sender) is 1530 also responsible for specifying the new MailFrom address. 1532 RFC2821.RcptTo 1534 Set by: Mediator 1536 This will contain the address of a new Recipient 1538 RFC2822.Received 1540 Set by: Mediator 1542 When resending a message the submission agent can record a 1543 Received header field, to indicate the transition from original 1544 posting to resubmission. 1546 5.3. Mailing Lists 1548 Mailing lists have explicit email addresses and they forward messages 1549 to a list of subscribed members. The Mailing List Actor performs a 1550 task that can be viewed as an elaboration of the Re-Director role. 1551 In addition to sending the new message to a potentially large number 1552 of new Recipients, the Mediator can modify content, such as deleting 1553 attachments, formatting conversion, and adding list-specific 1554 comments. In addition, archiving list messages is common. Still the 1555 message retains characteristics of being "from" the original 1556 Originator. 1558 Identities relevant to a mailing list processor, when submitting a 1559 message, include: 1561 RFC2919.List-Id 1563 Set by: Mediator 1565 This provides a global mailing list naming framework that is 1566 independent of particular hosts. [RFC2919] 1568 RFC2369.List-* 1570 Set by: Mediator 1572 [RFC2369] defines a collection of message header fields for use by 1573 mailing lists. In effect they supply list-specific parameters for 1574 common mailing list user operations. The identifiers for these 1575 operations are for the list, itself, and the user-as-subscriber. 1576 [RFC2369] 1578 RFC2822.From 1580 Set by: original Originator 1582 Names and email addresses for the original author(s) of the 1583 message content are specified. 1585 RFC2822.Reply-To 1587 Set by: original Originator or Mediator 1589 Mailing lists have introduced an ambiguity for the Reply-To field. 1590 Some List operations choose to force all replies to go to all list 1591 members. They achieve this by placing the list address into the 1592 RFC2822.Reply-To field. Hence direct, "private" replies only to 1593 the original author cannot be achieved by using the MUA's typical 1594 "reply to author" function. If the author created a Reply-To 1595 field, its information is lost. 1597 RFC2822.Sender 1599 Set by: Originator or Mediator Originator or Mediator Source 1601 This will usually specify the address of the agent responsible for 1602 mailing list operations. However some mailing lists operate in a 1603 manner very similar to a simple MTA Relay, so that they preserve 1604 as much of the original handling information as possible, 1605 including the original RFC2822.Sender field. 1607 RFC2822.TO, RFC2822.CC 1609 Set by: original Originator 1611 These will usually contain the original list of Recipient 1612 addresses. 1614 RFC2821.MailFrom 1616 Set by: Originator or Mediator Source 1618 This can contain the original address to be notified of 1619 transmission issues, or the mailing list agent can set it to 1620 contain a new Notification address. Typically the value is set to 1621 a new address, so that mailing list members and posters are not 1622 burdened with transmission-related Bounces. 1624 RFC2821.RcptTo 1626 Set by: Mediator 1628 This contains the address of a mailing list member. 1630 RFC2821.Received 1632 Set by: Mediator 1634 A Mailing List Agent can record a Received header field, to 1635 indicate the transition from original posting to mailing list 1636 forwarding. The Agent can choose to have the message retain the 1637 original set of Received header fields or can choose to remove 1638 them. In the latter case it can ensure that the original Received 1639 header fields are otherwise available, to ensure later 1640 accountability and diagnostic access to them. 1642 5.4. Gateways 1644 Gateways perform the basic routing and transfer work of message 1645 relaying, but they also make any message or address modifications 1646 that are needed to send the message into a messaging environment that 1647 operates according to different standards or potentially incompatible 1648 policies. When a Gateway connects two differing messaging services, 1649 its role is easy to identify and understand. When it connects 1650 environments that have technical similarity, but can have significant 1651 administrative differences, it is easy to think that a Gateway is 1652 merely an MTA. The critical distinction between an MTA and a Gateway 1653 is that the latter transforms addresses and/or message content, in 1654 order to map between the standards of two, different messaging 1655 services. In virtually all cases, this mapping process results in 1656 some degree of semantic loss. The challenge of Gateway design is to 1657 minimize this loss. 1659 A Gateway can set any identity field available to a regular MUA. 1660 Identities typically relevant to Gateways include: 1662 RFC2822.From 1664 Set by: original Originator 1666 Names and email addresses for the original author(s) of the 1667 message content are retained. As for all original addressing 1668 information in the message, the Gateway can translate addresses in 1669 whatever way will allow them continue to be useful in the target 1670 environment. 1672 RFC2822.Reply-To 1674 Set by: original Originator 1676 The Gateway SHOULD retain this information, if it is originally 1677 present. The ability to perform a successful reply by a Gatewayed 1678 Recipient is a typical test of Gateway functionality. 1680 RFC2822.Sender 1682 Set by: Originator or Mediator Source 1684 This can retain the original value or can be set to a new address 1686 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1688 Set by: original Recipient 1690 These usually retain their original addresses. 1692 RFC2821.MailFrom 1694 Set by: Originator or Mediator Source 1696 The agent responsible for gatewaying the message can choose to 1697 specify a new address to receive handling notices. 1699 RFC2822.Received 1700 Set by: Mediator 1702 The Gateway can record a Received header field, to indicate the 1703 transition from original posting to the new messaging environment. 1705 5.5. Boundary Filter 1707 Organizations often enforce security boundaries by subjecting 1708 messages to analysis, for conformance with the organization's safety 1709 policies. An example is detection of content classed as spam or a 1710 virus. A Filter might alter the content, to render it safe, such as 1711 by removing content deemed unacceptable. Typically these actions 1712 will result in the addition of content that records the actions. 1714 6. Security Considerations 1716 This document does not specify any new Internet Mail functionality. 1717 Consequently it is not intended to introduce any security 1718 considerations. 1720 However its discussion of the roles and responsibilities for 1721 different mail service modules, and the information they create, 1722 highlights the considerable security issues that are present when 1723 implementing any component of the Internet Mail service. In 1724 addition, email transfer protocols can operate over authenticated 1725 and/or encrypted links, and message content or authorship can be 1726 authenticated or encrypted. 1728 7. References 1730 7.1. Normative 1732 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 1733 RFC 821, August 1982. 1735 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1736 text messages", STD 11, RFC 822, August 1982. 1738 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1739 STD 13, RFC 1034, November 1987. 1741 [RFC1035] Mockapetris, P., "Domain names - implementation and 1742 specification", STD 13, RFC 1035, November 1987. 1744 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1745 STD 53, RFC 1939, May 1996. 1747 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1748 October 1996. 1750 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1751 Extensions (MIME) Part One: Format of Internet Message 1752 Bodies", RFC 2045, November 1996. 1754 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1755 Extensions (MIME) Part Two: Media Types", RFC 2046, 1756 November 1996. 1758 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1759 Part Three: Message Header Extensions for Non-ASCII Text", 1760 RFC 2047, November 1996. 1762 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1763 Internet Mail Extensions (MIME) Part Four: Registration 1764 Procedures", BCP 13, RFC 2048, November 1996. 1766 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1767 Extensions (MIME) Part Five: Conformance Criteria and 1768 Examples", RFC 2049, November 1996. 1770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1771 Requirement Levels", BCP 14, RFC 2119, March 1997. 1773 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1774 Specification", RFC 2181, July 1997. 1776 [RFC2304] Allocchio, C., "Minimal FAX address format in Internet 1777 Mail", RFC 2304, March 1998. 1779 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1780 for Core Mail List Commands and their Transport through 1781 Message Header Fields", RFC 2369, July 1998. 1783 [RFC2421] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 1784 Mail - version 2", RFC 2421, September 1998. 1786 [RFC2423] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME 1787 Sub-type Registration", RFC 2423, September 1998. 1789 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1791 [RFC2476] Gellens, R. and J. Klensin, "Message Submission", 1792 RFC 2476, December 1998. 1794 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1795 Addresses", RFC 2465, August 1999. 1797 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1798 April 2001. 1800 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1801 April 2001. 1803 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1804 and Namespace for the Identification of Mailing Lists", 1805 RFC 2919, March 2001. 1807 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 1808 RFC 3028, January 2001. 1810 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 1811 Negotiation for Messaging Services based on Email", 1812 RFC 3297, July 2002. 1814 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1815 Context for Internet Mail", RFC 3458, January 2003. 1817 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1818 Extension for Delivery Status Notifications (DSNs)", 1819 RFC 3461, January 2003. 1821 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1822 4rev1", RFC 3501, March 2003. 1824 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1825 Notification", RFC 3798, May 2004. 1827 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1828 Procedures for Message Header Fields", RFC 3864, 1829 September 2004. 1831 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 1832 Header Fields", RFC 4021, March 2005. 1834 [RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support 1835 Diverse Service Environments (Lemonade) Profile", 1836 June 2006. 1838 7.2. Descriptive 1840 [ID-ffpim] 1841 Crocker, D. and G. Klyne, "Full-mode Fax Profile for 1842 Internet Mail: FFPIM", March 2004. 1844 [ID-spamops] 1845 Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 1846 E. Allman, "Email Submission Between Independent 1847 Networks", draft-spamops-00 (work in progress), 1848 March 2004. 1850 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 1851 RFC 1767, March 1995. 1853 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 1854 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1855 ACM SIGCOMM, 2002. 1857 Appendix A. Acknowledgements 1859 This work derives from a section in draft-hutzler-spamops 1860 [ID-spamops]. Discussion of the Source actor role was greatly 1861 clarified during discussions in the IETF's Marid working group. 1863 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1864 insight on the framework and details of the original drafts. 1866 Later reviews and suggestions were provided by Nathaniel Borenstein, 1867 Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, 1868 Eric Hall, Brad Knowles, John Leslie, Bruce Lilly, Mark E. Mallett, 1869 David MacQuigg, Chris Newman, Daryl Odnert, Rahmat M. Samik-Ibrahim, 1870 Marshall Rose, Hector Santos, Jochen Topf, Willemien Hoogendoorn, 1871 Valdis Kletnieks. 1873 Diligent proof-reading was performed by Bruce Lilly, 1875 Author's Address 1877 Dave Crocker 1878 Brandenburg InternetWorking 1879 675 Spruce Drive 1880 Sunnyvale, CA 94086 1881 USA 1883 Phone: +1.408.246.8253 1884 Email: dcrocker@bbiw.net 1886 Full Copyright Statement 1888 Copyright (C) The IETF Trust (2007). 1890 This document is subject to the rights, licenses and restrictions 1891 contained in BCP 78, and except as set forth therein, the authors 1892 retain all their rights. 1894 This document and the information contained herein are provided on an 1895 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1896 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1897 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1898 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1899 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1900 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1902 Intellectual Property 1904 The IETF takes no position regarding the validity or scope of any 1905 Intellectual Property Rights or other rights that might be claimed to 1906 pertain to the implementation or use of the technology described in 1907 this document or the extent to which any license under such rights 1908 might or might not be available; nor does it represent that it has 1909 made any independent effort to identify any such rights. Information 1910 on the procedures with respect to rights in RFC documents can be 1911 found in BCP 78 and BCP 79. 1913 Copies of IPR disclosures made to the IETF Secretariat and any 1914 assurances of licenses to be made available, or the result of an 1915 attempt made to obtain a general license or permission for the use of 1916 such proprietary rights by implementers or users of this 1917 specification can be obtained from the IETF on-line IPR repository at 1918 http://www.ietf.org/ipr. 1920 The IETF invites any interested party to bring to its attention any 1921 copyrights, patents or patent applications, or other proprietary 1922 rights that may cover technology that may be required to implement 1923 this standard. Please address the information to the IETF at 1924 ietf-ipr@ietf.org. 1926 Acknowledgment 1928 Funding for the RFC Editor function is provided by the IETF 1929 Administrative Support Activity (IASA).