idnits 2.17.00 (12 Aug 2021) /tmp/idnits62693/draft-crocker-email-arch-05.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 on line 1882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1906. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 22, 2006) is 5689 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 1833, but not defined == Missing Reference: 'ID-ffpim' is mentioned on line 1823, but not defined == Missing Reference: 'Tussle' is mentioned on line 1836, but not defined == Missing Reference: 'ID-spamops' is mentioned on line 1843, 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) Summary: 19 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 October 22, 2006 5 Expires: April 25, 2007 7 Internet Mail Architecture 8 draft-crocker-email-arch-05 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 April 25, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 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 a simple split between the user world, 45 in the form of Mail User Agents (MUA), and the transmission world, in 46 the form of the Mail Handling Service (MHS) composed of Mail Transfer 47 Agents (MTA). Core aspects of the service, such as mailbox address 48 and basic message format style, have remained remarkably constant. 50 However today Internet Mail is marked by many independent operators, 51 many different components for providing users service and many others 52 for performing message transfer. Public discussion of the 53 architecture has not kept pace with the real-world technical and 54 operational refinements. This document offers an enhanced Internet 55 Mail architecture to reflect the current service. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Service Overview . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Field Referencing Convention . . . . . . . . . . . . . . . 5 62 1.3. Document terminology and conventions . . . . . . . . . . . 5 63 1.4. Discussion venue . . . . . . . . . . . . . . . . . . . . . 6 64 1.5. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2. Email Actor Roles . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.2. MHS Actors . . . . . . . . . . . . . . . . . . . . . . . . 9 68 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 12 69 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 3.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 15 72 3.3. Message Identifier . . . . . . . . . . . . . . . . . . . . 16 73 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 17 74 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 20 75 4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 22 76 4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 25 77 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 29 78 5.1. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 31 79 5.2. Re-Sending . . . . . . . . . . . . . . . . . . . . . . . . 32 80 5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 34 81 5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 36 82 5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 38 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 85 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 38 86 7.2. Descriptive . . . . . . . . . . . . . . . . . . . . . . . 40 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 89 Intellectual Property and Copyright Statements . . . . . . . . . . 42 91 1. Introduction 93 Over its thirty-five year history Internet Mail has undergone 94 significant changes in scale and complexity, as it has become a 95 global infrastructure service. However the changes have been 96 evolutionary, rather than revolutionary, reflecting a strong desire 97 to preserve its installed base of users and utility. 99 The first standardized architecture for networked email specified a 100 simple split between the user world, in the form of Mail User Agents 101 (MUA), and the transmission world, in the form of the Mail Handling 102 Service (MHS) composed of Mail Transfer Agents (MTA). The MHS is 103 responsible for accepting a message from one User and delivering it 104 to one or more others, creating a virtual MUA-to-MUA exchange 105 environment. 107 +--------+ 108 +---------------->| User | 109 | +--------+ 110 | ^ 111 +--------+ | +--------+ . 112 | User +--+--------->| User | . 113 +--------+ | +--------+ . 114 . | ^ . 115 . | +--------+ . . 116 . +-->| User | . . 117 . +--------+ . . 118 . ^ . . 119 . . . . 120 V . . . 121 +---+----------------+------+------+---+ 122 | . . . . | 123 | +...............>+ . . | 124 | . . . | 125 | +......................>+ . | 126 | . . | 127 | +.............................>+ | 128 | | 129 | Mail Handling Service (MHS) | 130 +--------------------------------------+ 132 Figure 1: Basic Internet Mail Service Model 134 Today Internet Mail is marked by many independent operators, many 135 different components for providing users service and many other 136 components for performing message transfer. So it is not surprising 137 that the operational service has sub-divided each of these "layers" 138 into more specialized modules. Core aspects of the service, such as 139 mailbox address and message style, have remained remarkably constant. 140 However public discussion of the architecture has not kept pace with 141 the real-world refinements. This document offers an enhanced 142 Internet Mail architecture to reflect the current service. The 143 original distinction between user-level concerns and transfer-level 144 concerns is retained, with an elaboration to each "level" of the 145 architecture that is discussed separately. The term "Internet Mail" 146 is used to refer to the entire collection of user and transfer 147 components. 149 For Internet Mail the term "end-to-end" usually refers to a single 150 posting and the set of deliveries directly resulting from its single 151 transiting of the MHS. A common exception is with group dialogue 152 that is mediated via a mailing list, so that two postings occur, 153 before intended recipients receive an originator's message. In fact, 154 some uses of email consider the entire email service -- including 155 Originator and Recipient -- as a subordinate component. For these 156 services "end-to-end" refers to points outside of the email service. 157 Examples are voicemail over email [RFC2423], EDI over email [RFC1767] 158 and facsimile over email.[ID-ffpim] 160 The current draft seeks to: 162 o Document refinements to the email model 164 o Clarify functional roles for the architectural components 166 o Clarify identity-related issues, across the email service 168 o Provide a document that serves as a common venue for further 169 defining and citing modern Internet Mail architecture 171 NOTE: 173 Any attempt to provide a retroactive description, for a service 174 that has evolved so extensively, is certain to claim definitions 175 and relationships that do not match the equally reasonable views 176 of some portion of the technical community. Ultimately the 177 "correct" choices are determined solely by the willingness of that 178 community to use the descriptions. 180 1.1. Service Overview 182 End-to-end Internet Mail exchange is accomplished by using a 183 standardized infrastructure comprising: 185 o An email object 187 o Global addressing 189 o An asynchronous sequence of point-to-point transfer mechanisms 191 o No prior arrangement between Originator and Recipient 193 o No prior arrangement between point-to-point transfer services, 194 over the open Internet 196 o No requirement for Originator and Recipient to be online at the 197 same time. 199 The end-to-end portion of the service is the email object, called a 200 message. Broadly the message, itself, is divided between handling 201 control information and user message content. 203 A precept to the design of mail over the open Internet is permitting 204 user-to-user and MTA-to-MTA interoperability to take place with no 205 prior direct administrative arrangement between independent 206 Administrative Management Domains. That is, all participants rely on 207 having the core services be universally supported, either directly or 208 through Gateways that translate between Internet Mail standards and 209 other email environments. 211 Within localized environments (Edge networks) prior administrative 212 arrangement can include access control, routing constraints and 213 lookup service configuration. In recent years one change to local 214 environments is an increased requirement for authentication or, at 215 least, accountability. In these cases a server performs explicit 216 validation of the client's identity. 218 1.2. Field Referencing Convention 220 In this document, references to structured fields of a message use a 221 two-part dotted notation. The first part cites the document that 222 contains the specification for the field and the second is the name 223 of the field. Hence is the From field in an email 224 content header and is the address in the SMTP 225 "Mail From" command. 227 1.3. Document terminology and conventions 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as specified in RFC 2119 [RFC2119]. 233 1.4. Discussion venue 235 Please direct discussion about this document to the IETF-SMTP mailing 236 list . 238 1.5. Changes 240 o Small modifications to figures 242 o Settled on term "ADministrative Management Domain (ADMD) to refer 243 to independent operational environments. A bit of an homage to 244 X.400... 246 o Various clarifications and wordsmithing. 248 2. Email Actor Roles 250 Internet Mail is a highly distributed service, with a variety of 251 actors serving different roles. These divide into 3 basic types: 253 o User 255 o Mail Handling Service (MHS) 257 o ADministrative Management Domain (ADMD) 259 Although related to a technical architecture, the focus on Actors 260 concerns participant responsibilities, rather than on functional 261 modules. Hence the labels used are different than for classic email 262 architecture diagrams. Actors often will be associated with 263 different organizations. This operational independence provides the 264 motivation for distinguishing among different ADMDs. 266 2.1. User Actors 268 Users are the sources and sinks of messages. They can be humans or 269 processes. They can have an exchange that iterates and they can 270 expand or contract the set of Users participating in a set of 271 exchanges. In Internet Mail there are three types of user-level 272 Actors: 274 o Originators 276 o Recipients 278 o Mediators 279 From the User-level perspective all mail transfer activities are 280 performed by a monolithic Mail Handling Service (MHS), even though 281 the actual service can be provided by many independent organizations. 282 Users are customers of this unified service. 284 The following depicts the flow of messages among Actors. 286 +------------+ 287 | |<---------------------------+ 288 | Originator |<----------------+ | 289 | |<----+ | | 290 +-+---+----+-+ | | | 291 | | | | | | 292 | | V | | | 293 | | +---------+-+ | | 294 | | | Recipient | | | 295 | | +-----------+ | | 296 | | | | 297 | | +--------+ | | 298 | | | | | | 299 | V V | | | 300 | +-----------+ +-+-------+-+ | 301 | | Mediator +--->| Recipient | | 302 | +-----------+ +-----------+ | 303 | | 304 | +-----------------------------+ | 305 | | +----------+ | | 306 | | | | | | 307 V V V | | | 308 +-----------+ +-----------+ +---+-+-+---+ 309 | Mediator +--->| Mediator +--->| Recipient | 310 +-----------+ +-----------+ +-----------+ 312 Figure 2: Relationships Among User Actors 314 2.1.1. Originator 316 Also called "Author", this is the user-level participant responsible 317 for creating original content and requesting its transmission. The 318 MHS operates to send and deliver mail among Originators and 319 Recipients. As described below, the MHS has a "Source" role that 320 correlates with the Author role. 322 2.1.2. Recipient 324 The Recipient is a consumer of delivered content. As described 325 below, the MHS has a "Dest[ination]" role that correlates with the 326 Recipient role. 328 A Recipient can close the user-level communication loop by creating 329 and submitting a new message that replies to an Originator. An 330 example of an automated form of reply is the Message Disposition 331 Notification, which informs the Originator about how the Recipient 332 handled the message. See Section 4.1. 334 2.1.3. Mediator 336 A Mediator receives, aggregates, reformulates and redistributes 337 messages as part of a potentially-protracted, higher-level exchange 338 among Users. Example uses of Mediators include group dialogue and 339 organizational message flow, as occurs with a purchase approval 340 process. Note that it is easy to confuse this user-level activity 341 with the underlying MHS transfer exchanges. However they serve very 342 different purposes and operate in very different ways. Mediators are 343 considered extensively in Section 5. 345 When mail is delivered to the mailbox address specified in the 346 RFC2821.MailFrom command, a receiving Mediator is viewed by the Mail 347 Handling Service as a Recipient. When submitting messages, the 348 Mediator is an Originator. What is distinctive is that a Mediator 349 preserves the Originator information of the message it reformulates, 350 but may make meaningful changes to the content. Hence the MHS sees a 351 new message, but Users receive a message that is interpreted as 352 primarily being from -- or, at least, initiated by -- the author of 353 the original message. The role of a Mediator permits distinct, 354 active creativity, rather than being limited to the more constrained 355 job of merely connecting together other participants. Hence it is 356 really the Mediator that is responsible for the new message. 358 A Mediator's task can be complex and contingent, such as by modifying 359 and adding content or regulating which users are allowed to 360 participate and when. The popular example of this role is a group 361 mailing list. A sequence of Mediators may even perform a series of 362 formal steps, such as reviewing, modifying and approving a purchase 363 request. 365 Because a Mediator originates messages, it might also receive 366 replies. So a Mediator really is a full-fledged User. 368 Gateway: A Gateway is a particularly interesting form of Mediator. 369 It is a hybrid of User and Relay that interconnects heterogeneous 370 mail services. Its goal is to emulate a Relay, so Gateway is 371 described in more detail, in Section 2.2.4. 373 2.2. MHS Actors 375 The Mail Handling Service (MHS) has the task of performing a single, 376 email-level, end-to-end transfer on behalf of the Originator and 377 reaching the Recipient address(es) specified in the envelope. 378 Mediated or protracted, iterative exchanges, such as those used for 379 collaboration over time, are part of the User-level service, and are 380 not part of this Transfer-level Handling Service. 382 The following depicts the relationships among transfer participants 383 in Internet Mail. It shows the Source as distinct from the 384 Originator, and Dest[ination] as distinct from Recipient, although it 385 is common for each pair to be the same actor. The figure also shows 386 multiple Relays in the sequence. It is legal to have no separate 387 Relay, where the Source and Dest interact directly. For intra- 388 organization mail services, it is common to have only one Relay. 390 +------------+ +-----------+ 391 | Originator | | Recipient | 392 +-----+------+ +-----------+ 393 | ^ 394 | Mail Handling Service | 395 /+=================================================+\ 396 || | | || 397 || | | || 398 V | 399 +---------+ +--------+ +----+----+ 400 | | | |<------------+ | 401 | Source +...>| Bounce | | Dest | 402 | | | |<---+ | | 403 +----+----+ +--------+ | +---------+ 404 | | ^ 405 V | | 406 +---------+ +----+----+ +----+----+ 407 | Relay +-->.......-->| Relay +-->| Relay | 408 +---------+ +----+----+ +---------+ 409 | 410 V 411 +---------+ 412 | Gateway +-->... 413 +---------+ 415 Figure 3: Relationships Among MHS Actors 417 2.2.1. Source 419 The Source role is responsible for ensuring that a message is valid 420 for posting and then submitting it to a Relay. Validity includes 421 conformance with Internet Mail standards, as well as with local 422 operational policies. The Source can simply review the message for 423 conformance and reject it if there are errors, or it can create some 424 or all of the necessary information. 426 The Source operates with dual "allegiance". It serves the Originator 427 and often it is the same entity. However its role in assuring 428 validity means that it MUST also represent the local operator of the 429 MHS, that is, the local ADministrative Management Domain (ADMD). 431 The Source also has the responsibility for any post-submission, 432 Originator-related administrative tasks associated with message 433 transmission and delivery. Notably this pertains to error and 434 delivery notices. Hence Source is best held accountable for the 435 message content, even when they did not create any or most of it. 437 2.2.2. Bounce Handler 439 The Bounce Handler processes service notifications that are generated 440 by the MHS, as a result of its efforts to transfer or deliver the 441 message. Notices can be about failures or completions and are sent 442 to an address that is specified by the Source. This Bounce handling 443 address (also known as a Return address) might have no visible 444 characteristics in common with the address of the Originator or 445 Source. 447 NOTE: 449 The choice of the label "Bounce" is unfortunate, due to its 450 negative implication. Currently, this is the most popular term 451 for the field. 453 2.2.3. Relay 455 A mail Relay performs email transfer-service routing and store-and- 456 forward. It adds envelope-level handling information and then 457 (re-)transmits the message on towards its Recipient(s). A Relay can 458 add information to the envelope, such as with trace information. 459 However it does not modify existing envelope information or the 460 message content semantics. It can modify message content syntax, 461 such as a change from text to binary transfer-encoding form, only as 462 required to meet the capabilities of the next hop in the MHS. 464 A set of Relays composes a Mail Handling Service (MHS) network. This 465 is above any underlying packet-switching network that they might be 466 using and below any gateways or other user-level Mediators. 468 In other words, interesting email scenarios can involve three 469 distinct architectural layers of store-and-forward service: 471 o User Mediators 473 o MHS Relays 475 o Packet Switches 477 with the bottom-most usually being the Internet's IP service. The 478 most basic email scenarios involve Relays and Switches. 480 Aborting a message transfer results in having the Relay become an 481 Originator and send an error message to the Bounce address. (The 482 potential for looping is avoided by having this message, itself, 483 contain no Bounce address.) 485 2.2.4. Gateway 487 A Gateway is a hybrid form of User and Relay that interconnects 488 heterogeneous mail services. Its purpose is simply to emulate a 489 Relay and the closer it comes to this, the better. However it 490 operates at the User level, because it MUST be able to modify message 491 content. 493 Differences between mail services can be as small as minor syntax 494 variations, but usually encompass significant, semantic distinctions. 495 One difference could have the concept of an email address be a 496 hierarchical, machine-specific address versus have it be a flat, 497 global name space. Another difference could be between text-only 498 content, versus multi-media. Hence the Relay function in a Gateway 499 offers significant design challenges, to make the result be as 500 seamless as possible. The more significant challenge is in ensuring 501 the user-to-user functionality that matches syntax and semantics of 502 independent email standards suites. 504 The basic test of a Gateway's adequacy is, of course, whether an 505 Originator on one side of a Gateway can send a message to a Recipient 506 on the other side, without requiring changes to any of the components 507 in the Originator's or Recipient's mail services, other than adding 508 the Gateway. To each of these otherwise independent services, the 509 Gateway will appear to be a "native" participant. However the 510 ultimate test of a Gateway's adequacy is whether the Originator and 511 Recipient can sustain a dialogue. In particular can a Recipient's 512 MUA automatically formulate a valid Reply that will reach the initial 513 Originator? 515 2.3. Administrative Actors 517 Operation of Internet Mail services is apportioned to different 518 providers (or operators). Each can be composed of an independent 519 ADministrative Management Domain (ADMD). Examples include an end- 520 user operating their desktop client, a department operating a local 521 Relay, an IT department operating an enterprise Relay and an ISP 522 operating a public shared email service. These can be configured 523 into many combinations of administrative and operational 524 relationships, with each ADMD potentially having a complex 525 arrangement of functional components. Figure 4 depicts the 526 relationships among ADMDs. Perhaps the most salient aspect of an 527 ADMD is the differential trust that determines its policies for 528 activities within the ADMD, versus those involving interactions with 529 other ADMDs. The architectural impact of needing to have boundaries 530 between ADMD's is discussed in [Tussle] 532 Basic types of ADMDs include: 534 Edge: Independent transfer services, in networks at the edge of the 535 open Internet Mail service. 537 User: End-user services. This might be subsumed under the Edge 538 service, such as is common for web-based email access. 540 Transit: These are Mail Service Providers (MSP) offering value- 541 added capabilities for Edge ADMDs, such as aggregation and 542 filtering. 544 Note that Transit services are quite different from packet-level 545 transit operation. Whereas end-to-end packet transfers usually go 546 through intermediate routers, email exchange across the open Internet 547 is often directly between the Boundary MTAs of Edge ADMDs, at the 548 email level. 550 +-------+ +------+ +-------+ 551 | ADMD1 | | ADMD3 | | ADMD4 | 552 | ----- | | ----- | | ----- | 553 | | +---------------------->| | | | 554 | User | | |-Edge--+--->|-User | 555 | | | | +--->| | | | 556 | V | | | +-------+ +-------+ 557 | Edge--+---+ | 558 | | | +---------+ | 559 +-------+ | | ADMD2 | | 560 | | ----- | | 561 | | | | 562 +--->|-Transit-+---+ 563 | | 564 +---------+ 566 Figure 4: ADministrative Management Domains (ADMD) Example 568 Edge networks can use proprietary email standards internally. 569 However the distinction between Transit network and Edge network 570 transfer services is primarily significant because it highlights the 571 need for concern over interaction and protection between independent 572 administrations. In particular this distinction calls for additional 573 care in assessing transitions of responsibility, as well as the 574 accountability and authorization relationships among participants in 575 email transfer. 577 The interactions between functional components within an ADMD are 578 subject to the policies of that domain. Policies can cover such 579 things as reliability, access control, accountability and even 580 content evaluation and modification. They can be implemented in 581 different functional components, according to the needs of the ADMD. 582 For example see [ID-spamops]. 584 User, Edge and Transit services can be offered by providers that 585 operate component services or sets of services. Further it is 586 possible for one ADMD to host services for other ADMDs. Common ADMD 587 examples are: 589 Enterprise Service Providers: 591 Operating an organization's internal data and/or mail services. 593 Internet Service Providers: 595 Operating underlying data communication services that, in turn, 596 are used by one or more Relays and Users. It is not necessarily 597 their job to perform email functions, but they can, instead, 598 provide an environment in which those functions can be performed. 600 Mail Service Providers: 602 Operating email services, such as for end-users, or mailing lists. 604 Operational pragmatics often dictate that providers be involved in 605 detailed administration and enforcement issues, to help ensure the 606 health of the overall Internet Mail Service. This can include 607 operators of lower-level packet services. 609 3. Identities 611 Internet Mail uses three forms of identity. The most common is the 612 end-point mailbox address [RFC2822] Also see the related 613 usage for
and in [RFC2821]. The other two forms 614 of email identity are the domain name Section 3.2 and 615 message identifier [RFC2822]. 617 3.1. Mailbox 619 "A mailbox sends and receives mail. It is a conceptual entity 620 which does not necessarily pertain to file storage." [RFC2822] 622 A mailbox is specified as an Internet Mail address . It 623 has two distinct parts, divided by an at-sign ("@"). The right-hand 624 side is a globally interpreted domain name that is part of an Common 625 Operating Group. Domain Names are discussed in Section 3.2. Formal 626 Internet Mail addressing syntax can support source routes, to 627 indicate the path through which a message should be sent. Although 628 legal, the use of source routes is not part of the modern Internet 629 Mail service and it is ignored in the rest of this document. 631 The portion to the left of the at-sign contains a string that is 632 globally opaque and is called the . It is to be 633 interpreted only by the entity specified in the address's right-hand 634 side. All other entities MUST treat the local-part as a 635 uninterpreted literal string and MUST preserve all of its original 636 details. As such its public distribution is equivalent to sending a 637 "cookie" that is only interpreted upon being returned to its 638 originator. 640 3.1.1. Global Standards for Local-Part 642 It is common for sites to have local structuring conventions for the 643 left-hand side (local-part) of an addr-spec. This permits sub- 644 addressing, such as for distinguishing different discussion groups by 645 the same participant. However it is worth stressing that these 646 conventions are strictly private to the user's organization and MUST 647 not be interpreted by any domain except the one listed in the right- 648 hand side of the addr-spec, and those specialized services conforming 649 to standardized conventions, as noted in the next paragraph. 651 A small class of addresses has an elaboration on basic email 652 addressing, with a standardized, global schema for the local-part. 653 These are conventions between originating end-systems and Recipient 654 Gateways, and they are invisible to the public email transfer 655 infrastructure. When an Originator is explicitly sending via a 656 Gateway out of the Internet, there are coding conventions for the 657 local-part, so that the Originator can formulate instructions for the 658 Gateway. Standardized examples of this are the telephone numbering 659 formats for VPIM [RFC2421], such as "+16137637582@vpim.example.com", 660 and iFax [RFC2304], such as 661 "FAX=+12027653000/T33S=1387@ifax.example.com". 663 3.1.2. Scope of Email Address Use 665 Email addresses are being used far beyond their original email 666 transfer and delivery role. In practical terms, email strings have 667 become a common form of user identity on the Internet. What is 668 essential, then, is to be clear about the nature and role of an 669 identity string in a particular context and to be clear about the 670 entity responsible for setting that string. 672 3.2. Domain Names 674 A domain name is a global reference to an Internet resource, such as 675 a host, a service or a network. A name usually maps to one or more 676 IP Addresses. Conceptually the name might encompass an entire 677 organization, or a collection of machines integrated into a 678 homogeneous service, or only a single machine. A domain name can be 679 administered to refer to individual users, but this is not common 680 practice. The name is structured as a hierarchical sequence of sub- 681 names, separated by dots ("."). Domain names are defined and 682 operated through the Domain Name Service (DNS) [RFC1034], [RFC1035], 683 [RFC2181]. 685 When not part of a mailbox address, a domain name is used in Internet 686 Mail to refer to the ADMD or the host that took action upon the 687 message, such as providing the administrative scope for a message 688 identifier, or performing transfer processing. 690 3.3. Message Identifier 692 There are two standardized tags, for identifying messages. 694 Message-ID: 696 The Message-ID is a user-level tag, primarily used for threading 697 and elimination of duplicates and is specified in [RFC2822]. It 698 is associated with the RFC2822.From, although any actor within the 699 originating ADMD might assign it. The recipient's ADMD is the 700 intended consumer of the Message-ID, although any actor along the 701 transmission path might use it. Internet Mail standards provide 702 for a single Message-ID; however more than one is sometimes 703 assigned. 705 Like a mailbox address, a Message-ID has two distinct parts, 706 divided by an at-sign ("@"). The right-hand side is globally 707 interpreted and specifies the ADMD or host assigning the 708 identifier. The left-hand side contains a string that is globally 709 opaque and serves to uniquely identify the message within the 710 domain referenced on the right-hand side. The duration of 711 uniqueness for the message identifier is undefined. 713 When a message is revised in any way, the question of whether to 714 assign a new Message-ID requires a subjective assessment, deciding 715 whether the editorial content has been changed enough to 716 constitute a new message. [RFC2822] says "a message identifier 717 pertains to exactly one instantiation of a particular message; 718 subsequent revisions to the message each receive new message 719 identifiers." However real-world experience dictates some 720 flexibility. An impossible test is whether the recipient will 721 consider the new message to be equivalent to the old. For most 722 components of Internet Mail, there is no way to predict a specific 723 recipient's preferences on this matter. Both creating and failing 724 to create a new Message-ID have their downsides. 726 The best that can be offered, here, are some guidelines and 727 examples: 729 * If a message is changed only in terms of form, such as 730 character-encoding, it clearly is still the same message. 732 * If a message has minor additions to the content, such as a 733 mailing list tag at the beginning of the RFC2822.Subject header 734 field, or some mailing list administrative information added to 735 the end of the primary body-part's text, then it probably is 736 still the same message. 738 * If a message has viruses deleted from it, it probably is still 739 the same message. 741 * If a message has offensive words deleted from it, then some 742 recipients will consider it the same message, but some will 743 not. 745 * If a message is translated into a different language, then some 746 recipients will consider it the same message, but some will 747 not. 749 The absence of objective, precise criteria for Message-ID re- 750 generation, along with the absence of strong protection associated 751 with the string, means that the presence of an ID can permit an 752 assessment that is marginally better than a heuristic, but the ID 753 certainly has no value for strict formal reference or comparison. 754 Hence it is not appropriate to use the Message-ID for any process 755 that might be called "security". 757 ENVID: 759 The ENVID (envelope identifier) is an envelope-level tag, 760 primarily for use within Delivery Status Notifications, so that 761 the Bounce Address (RFC2821.MailFrom) recipient can correlate the 762 DSN with a particular message. The ENVID is therefore used from 763 one message posting, until the directly-resulting message 764 deliveries. It does not survive re-postings [RFC3461]. 766 The format of an ENVID is free-form. Although its creator might 767 choose to impose structure on the string, none is imposed by 768 Internet standards. By implication, the scope of the string is 769 defined by the domain name of the Bounce Address. 771 4. Services and Standards 773 The Internet's MHS architecture distinguishes among six different 774 types of functional components, arranged to support a store-and- 775 forward service architecture: 777 o Message 779 o Mail User Agent (MUA) 781 o Message Submission Agent (MSA) 783 o Message Transfer Agent (MTA) 785 o Message Delivery Agent (MDA) 787 o Message Store (MS) 789 This section describes each functional component for Internet Mail, 790 and the standard protocols associated with their operation. 792 Software implementations of these architectural components often 793 compress them, such as having the same software do MSA, MTA and MDA 794 functions. However the requirements for each of these components of 795 the service are becoming more extensive. So their separation is 796 increasingly common. 798 NOTE: 800 A discussion about any interesting system architecture is often 801 complicated by confusion between architecture versus 802 implementation. An architecture defines the conceptual functions 803 of a service, divided into discrete conceptual modules. An 804 implementation of that architecture can combine or separate 805 architectural components, as needed for a particular operational 806 environment. It is important not to confuse the engineering 807 decisions that are made to implement a product, with the 808 architectural abstractions used to define conceptual functions. 810 This figure shows function modules and the protocols used between 811 them. Additional protocols and configurations are possible. 813 +------+ +---------+ 814 ...............+ oMUA |...| Disp |<----------------+ 815 . +--+---+ +---------+ | 816 . | {smtp, | 817 . V {submission | 818 . +------+ +---------+ | 819 . | MSA |...| Bounces |< -----+ | 820 . +--+---+ +---------+ | | 821 . | | | 822 . V {smtp | | 823 . +------+ /+===+===+\ | 824 . | MTA | || dsn || | 825 /+==========+\ +--+---+ \+=======+/ | 826 || MESSAGE || . ^ ^ | 827 ||----------|| . {smtp | | | 828 || Envelope || . | | | 829 || SMTP || V | | | 830 || RFC2822 || +------+ | | /+==+==+\ 831 || Content || | MTA +-------------------+ | || mdn || 832 || RFC2822 || +--+---+ | \+=====+/ 833 || MIME || | {local, smtp, | | 834 \+==========+/ V {lmtp | | 835 . +------+ | | 836 . | +-----------------------+ | 837 . | MDA | | 838 . | |<--------------------+ | 839 . +-+--+-+ | | 840 . local} | | | | 841 . V | | | 842 . +------+ | /+===+===+\ | 843 . | sMS | | || sieve || | 844 . +-+--+-+ | \+=======+/ | 845 . | | | {pop, imap ^ | 846 . | V V | | 847 . | +------+ | | 848 . | | uMS | | | 849 . | +--+---+ | | 850 . | | {pop, imap, | | 851 . V V {local | | 852 . +------+ | | 853 . | +------------------------+ | 854 ...........>| rMUA | | 855 | +----------------------------------+ 856 +------+ 858 Figure 5: Protocols and Services 860 4.1. Message Data 862 The purpose of the Mail Handling Service is to exchange a message 863 object among participants [RFC2822] [RFC0822]. Hence all of the 864 underlying mechanisms are merely in the service of getting that 865 message from its Originator to its Recipients. A message can be 866 explicitly labeled as to its nature [RFC3458]. 868 A message comprises a transit handling envelope and the end-user 869 message content. The envelope contains handling information used by 870 the Message Handling Service, or generated by it. The content is 871 divided into a structured header and the body. The body may be 872 unstructured simple lines of text, or it may be a tree of multi-media 873 subordinate objects, called body-parts. 875 Internet Mail has some special control data: 877 Delivery Status Notification (DSN): 879 A Delivery Status Notification (DSN) is a message that can be 880 generated by the Mail Handling Service (MSA, MTA or MDA) and sent 881 to the RFC2821.MailFrom address. The mailbox for this is shown as 882 Bounces in Figure 5 It provides information about message transit, 883 such as transmission errors or successful delivery. [RFC3461] 885 Message Disposition Notification (MDN): 887 A Message Disposition Notification (MDN) is a message that can be 888 generated by an rMUA and is sent to the 889 Disposition-Notification-To address(es). The mailbox for this is 890 shown as Disp in Figure 5. It provides information about user- 891 level, Recipient-side message processing, such as indicating that 892 the message has been displayed [RFC3798] or the form of content 893 that can be supported. [RFC3297] 895 Message Filtering (SIEVE): 897 SIEVE is a scripting language that permits specifying conditions 898 for differential handling of mail, at the time of delivery 899 [RFC3028]. It can be conveyed in a variety of ways, as a MIME 900 part. Figure 5 shows a Sieve specification going from the rMUA to 901 the MDA. However filtering can be done at many different points 902 along the transit path and any one or more of them might be 903 subject to Sieve directives, especially within a single ADMD. 904 Hence the Figure shows only one relationship, for simplicity. 906 4.1.1. Envelope 908 Information that is directly used by, or produced by, the MHS is 909 called the "envelope". It controls and records handling activities 910 by the transfer service. Internet Mail has a fragmented framework 911 for handling this "handling" information. The envelope exists partly 912 in the transfer protocol SMTP [RFC2821] and partly in the message 913 object [RFC2822]. The SMTP specification uses the term to refer only 914 to the transfer-protocol information. 916 NOTE: 918 Due to the frequent use of the term "envelope" to refer only to 919 SMTP constructs, there has been some call for using a different 920 term, to label the larger set of information defined here. So 921 far, no alternative term has developed any community support. 923 Direct envelope addressing information, as well as optional transfer 924 directives, are carried within the SMTP control channel. Other 925 envelope information, such as trace records, is carried within the 926 message object header fields. Upon delivery, some SMTP-level 927 envelope information is typically encoded within additional message 928 object header fields, such as Return-Path. 930 4.1.2. Header Fields 932 Header fields are attribute name/value pairs covering an extensible 933 range of email service, user content and user transaction meta- 934 information. The core set of header fields is defined in [RFC2822], 935 [RFC0822]. It is common to extend this set, for different 936 applications. Procedures for registering header fields are defined 937 in [RFC4021]. An extensive set of existing header field 938 registrations is provided in [RFC3864]. 940 One danger with placing additional information in header fields is 941 that Gateways often alter or delete them. 943 4.1.3. Body 945 The body of a message might simply be lines of ASCII text or it might 946 be hierarchically structured into a composition of multi-media body- 947 part attachments, using MIME [RFC2045], [RFC2046], [RFC2047], 948 [RFC2048], and [RFC2049]. MIME structures each body-part into a 949 recursive set of MIME header field meta-data and MIME Content 950 sections. 952 4.1.4. Identity References in a Message 954 For a message in transit, the core uses of identity references 955 combine into: 957 +-----------------------+-------------+---------------------+ 958 | Layer | Field | Set By | 959 +-----------------------+-------------+---------------------+ 960 | Message Body | MIME Header | Originator | 961 | Message header fields | From | Originator | 962 | | Sender | Source | 963 | | Reply-To | Originator | 964 | | To, CC, BCC | Originator | 965 | | Message-ID | Source | 966 | | Received | Source, Relay, Dest | 967 | | Return-Path | MDA, from MailFrom | 968 | | Resent-* | Mediator | 969 | SMTP | HELO | Latest Relay Client | 970 | | MailFrom | Source | 971 | | RcptTo | Originator | 972 | IP | IP Address | Latest Relay Client | 973 +-----------------------+-------------+---------------------+ 975 Layered Identities 977 4.2. User-Level Services 979 Interactions at the user level entail protocol exchanges, distinct 980 from those that occur at lower layers of the architecture. Because 981 the motivation for email, and much of its use, is for interaction 982 among humans, the nature and details of these protocol exchanges 983 often are determined by the needs of human and group communication. 984 In terms of efforts to specify behaviors, one effect of this is to 985 require subjective guidelines, rather than strict rules, for some 986 aspects of system behavior. Mailing Lists provide particularly 987 salient examples of this. 989 4.2.1. Mail User Agent (MUA) 991 A Mail User Agent (MUA) works on behalf of end-users and end-user 992 applications. It is their "representative" within the email service. 994 The Origination-side (oMUA) creates a message and performs initial 995 "submission" into the transfer infrastructure, via a Mail Submission 996 Agent (MSA). It can also perform any creation- and posting-time 997 archival. An MUA outbox is part of the origination-side MUA. 999 The Recipient-side rMUA works on behalf of the end-user Recipient to 1000 process received mail. This includes generating user-level return 1001 control messages, display and disposition of the received message, 1002 and closing or expanding the user communication loop, by initiating 1003 replies and forwarding new messages. 1005 An MUA can, itself, have a distributed implementation, such as a 1006 "thin" user interface module on a limited end-user device, with the 1007 bulk of the MUA functionality operated remotely on a more capable 1008 server. An example of such an architecture might use IMAP [RFC3501] 1009 for most of the interactions between an MUA client and an MUA server. 1011 A Mediator is special class of MUA. It performs message re-posting, 1012 as discussed in Section 2.1. 1014 Identity fields relevant to the MUA include: 1016 RFC2822.From 1018 Set by: Originator 1020 Names and addresses for author(s) of the message content are 1021 listed in the From field 1023 RFC2822.Reply-To 1025 Set by: Originator 1027 If a message Recipient sends a reply message that would otherwise 1028 use the RFC2822.From field address(es) contained in the original 1029 message, then they are instead to use the address(es) in the 1030 RFC2822.Reply-To field. In other words this field is a direct 1031 override of the From field, for responses from Recipients. 1033 RFC2822.Sender 1035 Set by: Source 1037 This specifies the address responsible for submitting the message 1038 into the transfer service. For efficiency this field can be 1039 omitted if it contains the same address as RFC2822.From. However 1040 this does not mean there is no Sender specified. Rather it means 1041 that that header field is virtual and that the address in the From 1042 field MUST be used. Specification of the error return addresses 1043 -- the "Bounce" address, contained in RFC2821.MailFrom -- is made 1044 by the RFC2822.Sender. Typically the Bounce address is the same 1045 as the Sender address. However some usage scenarios require it to 1046 be different. 1048 RFC2822.To, RFC2822.CC 1050 Set by: Originator 1052 These specify MUA Recipient addresses. The addresses in the 1053 fields might not be present in the RFC2821.RcptTo command. The 1054 distinction between To and CC is subjective. Generally a To 1055 addressee is considered primary and is expected to take action on 1056 the message. A CC addressee typically receives a copy only for 1057 their information. 1059 RFC2822.BCC 1061 Set by: Originator 1063 A message might be copied to an addressee whose participation is 1064 not to be disclosed to the RFC2822.To or RFC2822.CC Recipients 1065 and, usually, not to the other BCC Recipients. The BCC header 1066 field indicates a message copy to such a Recipient. Typically, 1067 the field lists no addresses or only lists the address of the 1068 Recipient receiving this copy. An MUA will typically make 1069 separate postings for TO and CC Recipients, versus BCC Recipients. 1070 The former will see no indication that any BCCs were sent, whereas 1071 the latter have a BCC field present. It might be empty, contain a 1072 comment, or contain one or more BCC addresses, depending upon the 1073 preferences of the Originator. 1075 4.2.2. Message Store (MS) 1077 An MUA can employ a long-term Message Store (MS). A rich set of 1078 choices for the use of that store derives from permitting more than 1079 one to be associated with a single user, demonstrated as a Server- 1080 based (sMS) User-based MS (uMS) in Figure 5. The sMS is shown as 1081 being remote from the MUA and the uMS as being local. Further the 1082 relationship between two message stores can vary. Between the MDA 1083 and the MUA, these choices are supported by a wide variety of 1084 protocol options. 1086 The operational relationship among MSs can be: 1088 Online: 1090 Only a remote MS is used, with messages being accessible only when 1091 the MUA is attached to the MS, and the MUA repeatedly fetches all 1092 or part of a message, from one session to the next. 1094 Offline: 1096 The MS is local to the user, and messages are completely moved 1097 from any remote store, rather than (also) being retained there. 1099 Disconnected: 1101 An r MS and a uMS are kept synchronized, for all or part of their 1102 contents, while there is a connection between them. While they 1103 are disconnected, mail can continue to arrive at the rMS and the 1104 user may continue to make changes to the uMS. Upon reconnections, 1105 the two stores are re-synchronized. 1107 4.3. MHS-Level Services 1109 4.3.1. Mail Submission Agent (MSA) 1111 A Mail Submission Agent (MSA) accepts the message submission from the 1112 oMUA and enforces the policies of the hosting ADMD and the 1113 requirements of Internet standards. Enforcement might be passive, 1114 involving review and approval or rejection, or it might be active, 1115 involving direct modification of the message. An MSA implements a 1116 server function to MUAs and a client function to MTAs (or MDAs). 1118 Examples of MSA-styled functions, in the world of paper mail, might 1119 range across the very different capabilities of administrative 1120 assistants, postal drop boxes, and post office front-counter 1121 employees. 1123 The MUA/MSA interface can be implemented within a single host and use 1124 private conventions for its interactions. Historically, standards- 1125 based MUA/MSA interactions have used SMTP [RFC2821]. However a 1126 recent alternative is SUBMISSION [RFC2476]. Although SUBMISSION 1127 derives from SMTP, it on a separate TCP port and imposes distinct 1128 requirements, such as access authorization. 1130 Identities relevant to the MSA include: 1132 RFC2821.HELO/.EHLO 1134 Set by: Source 1136 The MSA can specify its hosting domain identity for the SMTP HELO 1137 or EHLO command operation. 1139 RFC2821.MailFrom 1141 Set by: Source 1143 This is an end-to-end string that specifies an email address for 1144 receiving return control information, such as "bounces". The name 1145 of this field is misleading, because it is not required to specify 1146 either the author or the agent responsible for submitting the 1147 message. Rather, the agent responsible for submission specifies 1148 the RFC2821.MailFrom address. Ultimately the simple basis for 1149 deciding what address needs to be in the RFC2821.MailFrom is to 1150 determine what address needs to be informed about transmission- 1151 level problems (and, possibly, successes.) 1153 RFC2821.RcptTo 1155 Set by: Originator 1157 This specifies the MUA mailbox address of a recipient. The string 1158 might not be visible in the message content header. For example, 1159 the message destination address header fields, such as RFC2822.To, 1160 might specify a mailing list address, while the RFC2821.RcptTo 1161 address specifies a member of that list. 1163 RFC2821.Received 1165 Set by: Source 1167 An MSA can record a Received header field, to indicate initial 1168 submission trace information, including originating host and MSA 1169 host domain names and/or IP Addresses. 1171 4.3.2. Mail Transfer Agent (MTA) 1173 A Mail Transfer Agent (MTA) relays mail for one application-level 1174 "hop". It is like a packet-switch or IP router in that its job is to 1175 make routing assessments and to move the message closer to the 1176 Recipient(s). Relaying is performed by a sequence of MTAs, until the 1177 message reaches its destination MDA(s). Hence an MTA implements both 1178 client and server MTA functionality. It does not make changes to 1179 addresses in the envelope or reformulate the editorial content. 1180 Hence a change in data form, such as to the MIME Content-Transfer- 1181 Encoding, is within the purview of an MTA, whereas removal or 1182 replacement of body content is not. Also it can add trace 1183 information. Of course email objects are typically much larger than 1184 the payload of a packet or datagram, and the end-to-end latencies are 1185 typically much higher. 1187 Internet Mail primarily uses SMTP [RFC2821], [RFC0821] to effect 1188 point-to-point transfers between peer MTAs. Other transfer 1189 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1190 most network layer mechanisms Internet Mail's SMTP supports a basic 1191 level of reliability, by virtue of providing for retransmission after 1192 a temporary transfer failure. Contrary to typical packet switches 1193 (and Instant Messaging services) Internet Mail MTAs typically store 1194 messages in a manner that allows recovery across service 1195 interruptions, such as host system shutdown. However the degree of 1196 such robustness and persistence by an MTA can be highly variable. 1198 The primary "routing" mechanism for Internet Mail is the DNS MX 1199 record [RFC1035], which specifies a host through which the queried 1200 domain can be reached. This presumes a public -- or at least a 1201 common -- backbone that permits any attached host to connect to any 1202 other. 1204 An important characteristic of MTA-MTA communications, over the open 1205 Internet, is that they do not require prior arrangement between the 1206 independent administrations operating the different MTAs. Given the 1207 importance of spontaneity and serendipity in the world of human 1208 communications, this lack of prearrangement between the participants 1209 is a core benefit of Internet Mail and remains a core requirement for 1210 it. 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: 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 Using Internet protocols, delivery can be effected by a variety of 1267 standard protocols. When coupled with an internal local mechanism, 1268 SMTP [RFC2821] and LMTP [RFC2033] permit "push" delivery to the 1269 Recipient system, at the initiative of the upstream email service. 1270 POP [RFC1939] and IMAP [RFC3501] are used for "pull" delivery at the 1271 initiative of the Recipient system. POP and IMAP can also be used 1272 for repeated access to messages on a remote MS. 1274 Identities relevant to the MDA include: 1276 RFC2821.Return-Path 1278 Set by: Source 1279 The MDA records the RFC2821.MailFrom address into the 1280 RFC2822.Return-Path field. 1282 RFC2822.Received 1284 Set by: Destination 1286 An MDA can record a Received header field, to indicate trace 1287 information, including source host and receiving host domain names 1288 and/or IP Addresses. 1290 5. Mediators 1292 Basic email transfer from an Originator to the specified Recipients 1293 is accomplished by using an asynchronous, store-and-forward 1294 communication infrastructure, in a sequence of independent 1295 transmissions through some number of MTAs. A very different task is 1296 a User-level sequence of postings and deliveries, through Mediators. 1297 A Mediator forwards a message, through a re-posting process. The 1298 Mediator does share some functionality with basic MTA relaying, but 1299 it enjoys a degree of freedom with both addressing and content that 1300 is not available to MTAs. 1302 RFC2821.HELO/.EHLO 1304 Set by: Source or Relay 1306 The MSA can specify its hosting domain identity for the SMTP HELO 1307 or EHLO command operation. 1309 RFC2821.MailFrom 1311 Set by: Source 1313 This is an end-to-end string that specifies an email address for 1314 receiving return control Bounces. The name of this field is 1315 misleading, because it is not required to specify either the 1316 author or the agent responsible for submitting the message. 1317 Rather the agent responsible for submission specifies the 1318 RFC2821.MailFrom address. Ultimately the simple basis for 1319 deciding what address needs to be in the RFC2821.MailFrom is to 1320 determine what address needs to be informed about transmission- 1321 level problems (and, possibly, successes.) 1323 RFC2821.RcptTo 1325 Set by: Mediator 1327 This specifies the MUA mailbox address of a Recipient. The string 1328 might not be visible in the message content header. For example, 1329 the message destination address header fields, such as RFC2822.To, 1330 might specify a mailing list address, while the RFC2821.RcptTo 1331 address specifies a member of that list. 1333 RFC2821.Received 1335 Set by: Mediator 1337 An MSA can record a Received header field, to indicate initial 1338 submission trace information, including originating host and MSA 1339 host domain names and/or IP Addresses. 1341 The salient aspect of a Mediator, that distinguishes it from any 1342 other MUA creating an entirely new message, is that a Mediator 1343 preserves the integrity and tone of the original message, including 1344 the essential aspects of the original origination information. The 1345 Mediator might also add commentary. 1347 Examples of MUA message creation that are NOT performed by Mediators 1348 include -- 1350 New message that forwards an existing message: 1352 This action rather curiously provides a basic template for a class 1353 of Mediators. However for its typical occurrence it is not itself 1354 an example of a Mediator. The new message is viewed as being from 1355 the Agent doing the forwarding, rather than being from the 1356 original Originator. 1358 A new message encapsulates the original message and is seen as 1359 strictly "from" the Mediator. The Mediator might add commentary 1360 and certainly has the opportunity to modify the original message 1361 content. The forwarded message is therefore independent of the 1362 original message exchange and creates a new message dialogue. 1363 However the final Recipient sees the contained message as from the 1364 original Originator. 1366 Reply: 1368 When a Recipient formulates a response back to the original 1369 message's author, the new message is not typically viewed as being 1370 a "forwarding" of the original. Its focus is the new content, 1371 although it might contain all or part of the material in the 1372 original message. Therefore the earlier material is merely 1373 contextual and secondary. 1375 Annotator: 1377 The integrity of the original message is usually preserved, but 1378 one or more comments about the message are added in a manner that 1379 distinguishes commentary from original text. The tone of the new 1380 message is that it is primarily commentary from a new Originator, 1381 similar to a Reply. 1383 The remainder of this section describes common examples of Mediators. 1385 5.1. Aliasing 1387 Aliasing is a simple re-addressing facility, available in most MDA 1388 implementations. It is performed just before delivering a message to 1389 the specified Recipient's mailbox. Instead the message is submitted 1390 back to the transfer service, for delivery to one or more alternate 1391 addresses. Although implemented as part of the message delivery 1392 service, this facility is strictly a Recipient user function. It 1393 resubmits the message, replacing the envelope address, on behalf of 1394 the mailbox address that was listed in the envelope. 1396 What is most distinctive about this forwarding mechanism is how 1397 closely it compares to normal MTA store-and-forward Relaying. In 1398 reality its only interesting difference is that it changes the 1399 RFC2821.RcptTo value. Having the change be this small makes it easy 1400 to view aliasing as a part of the lower-level mail relaying activity. 1401 However the small change has a large semantic impact: The designated 1402 recipient has chosen a new recipient. 1404 Hence that original recipient SHOULD become responsible for any 1405 handling issues. This change would be reflected by replacing the 1406 message's RFC2821.MailFrom address to be one within the scope of the 1407 ADMD doing the aliasing. 1409 An MDA that is re-posting a message to an alias typically changes 1410 only envelope information: 1412 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1413 Set by: Originator 1415 These retain their original addresses. 1417 RFC2821.RcptTo 1419 Set by: Mediator 1421 This field contains an alias address. 1423 RFC2821.MailFrom 1425 Set by: Mediator or original Source 1427 The agent responsible for submission to an alias address will 1428 often retain the original address to receive handling Bounces. 1429 The benefit of retaining the original MailFrom value is to ensure 1430 that the origination-side agent knows that there has been a 1431 delivery problem. On the other hand, the responsibility for the 1432 problem usually lies with the Recipient, since the Alias mechanism 1433 is strictly under the Recipient's control. 1435 RFC2821.Received 1437 Set by: Mediator 1439 The agent can record Received information, to indicate the 1440 delivery to the original address and submission to the alias 1441 address. The trace of Received header fields can therefore 1442 include everything from original posting through final delivery to 1443 the alias. 1445 5.2. Re-Sending 1447 Also called Re-Directing, Re-Sending differs from Forwarding by 1448 virtue of having the Mediator "splice" a message's addressing 1449 information, to connect the Originator of the original message and 1450 the Recipient of the new message. This permits them to have direct 1451 exchange, using their normal MUA Reply functions. Hence the new 1452 Recipient sees the message as being From the original Originator, 1453 even if the Mediator adds commentary. 1455 Identities specified in a resent message include 1457 RFC2822.From 1458 Set by: original Originator 1460 Names and email addresses for the original author(s) of the 1461 message content are retained. The free-form (display-name) 1462 portion of the address might be modified to provide informal 1463 reference to the agent responsible for the redirection. 1465 RFC2822.Reply-To 1467 Set by: original Originator 1469 If this field is present in the original message, it is retained 1470 in the Resent message. 1472 RFC2822.Sender 1474 Set by: original Source 1476 This field is expected to contain the original Sender value. 1478 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1480 Set by: original Originator 1482 These specify the original message Recipients. 1484 RFC2822.Resent-From 1486 Set by: Mediator 1488 The address of the original Recipient who is redirecting the 1489 message. Otherwise the same rules apply for the Resent-From field 1490 as for an original RFC2822.From field 1492 RFC2822.Resent-Sender 1494 Set by: Mediator 1496 The address of the agent responsible for re-submitting the 1497 message. For efficiency this field is often omitted if it 1498 contains the same address as RFC2822.Resent-From. However this 1499 does not mean there is no Resend-Sender specified. Rather it 1500 means that that header field is virtual and that the address in 1501 the Resent-From field MUST be used. Specification of the error 1502 return addresses (the Notification address, contained in 1503 RFC2821.MailFrom) is made by the Resent-Sender. Typically the 1504 Bounce address is the same as the Resent-Sender address. However 1505 some usage scenarios require it to be different. 1507 RFC2822.Resent-To, RFC2822.Resent-cc, RFC2822.Resent-bcc: 1509 Set by: Mediator 1511 The addresses of the new Recipients who will now be able to reply 1512 to the original author. 1514 RFC2821.MailFrom 1516 Set by: Mediator 1518 The agent responsible for re-submission (RFC2822.Resent-Sender) is 1519 also responsible for specifying the new MailFrom address. 1521 RFC2821.RcptTo 1523 Set by: Mediator 1525 This will contain the address of a new Recipient 1527 RFC2822.Received 1529 Set by: Mediator 1531 When resending a message the submission agent can record a 1532 Received header field, to indicate the transition from original 1533 posting to resubmission. 1535 5.3. Mailing Lists 1537 Mailing lists have explicit email addresses and they forward messages 1538 to a list of subscribed members. The Mailing List Actor performs a 1539 task that can be viewed as an elaboration of the Re-Director role. 1540 In addition to sending the new message to a potentially large number 1541 of new Recipients, the Mediator can modify content, such as deleting 1542 attachments, formatting conversion, and adding list-specific 1543 comments. In addition, archiving list messages is common. Still the 1544 message retains characteristics of being "from" the original 1545 Originator. 1547 Identities relevant to a mailing list processor, when submitting a 1548 message, include: 1550 RFC2919.List-Id 1551 Set by: Mediator 1553 This provides a global mailing list naming framework that is 1554 independent of particular hosts. [RFC2919] 1556 RFC2369.List-* 1558 Set by: Mediator 1560 [RFC2369] defines a collection of message header fields for use by 1561 mailing lists. In effect they supply list-specific parameters for 1562 common mailing list user operations. The identifiers for these 1563 operations are for the list, itself, and the user-as-subscriber. 1564 [RFC2369] 1566 RFC2822.From 1568 Set by: original Originator 1570 Names and email addresses for the original author(s) of the 1571 message content are specified. 1573 RFC2822.Reply-To 1575 Set by: original Originator or Mediator 1577 Mailing lists have introduced an ambiguity for the Reply-To field. 1578 Some List operations choose to force all replies to go to all list 1579 members. They achieve this by placing the list address into the 1580 RFC2822.Reply-To field. Hence direct, "private" replies only to 1581 the original author cannot be achieved by using the MUA's typical 1582 "reply to author" function. If the author created a Reply-To 1583 field, its information is lost. 1585 RFC2822.Sender 1587 Set by: original Source or Mediator 1589 This will usually specify the address of the agent responsible for 1590 mailing list operations. However some mailing lists operate in a 1591 manner very similar to a simple MTA Relay, so that they preserve 1592 as much of the original handling information as possible, 1593 including the original RFC2822.Sender field. 1595 RFC2822.TO, RFC2822.CC 1596 Set by: original Originator 1598 These will usually contain the original list of Recipient 1599 addresses. 1601 RFC2821.MailFrom 1603 Set by: original Source or Mediator 1605 This can contain the original address to be notified of 1606 transmission issues, or the mailing list agent can set it to 1607 contain a new Notification address. Typically the value is set to 1608 a new address, so that mailing list members and posters are not 1609 burdened with transmission-related Bounces. 1611 RFC2821.RcptTo 1613 Set by: Mediator 1615 This contains the address of a mailing list member. 1617 RFC2821.Received 1619 Set by: Mediator 1621 A Mailing List Agent can record a Received header field, to 1622 indicate the transition from original posting to mailing list 1623 forwarding. The Agent can choose to have the message retain the 1624 original set of Received header fields or can choose to remove 1625 them. In the latter case it can ensure that the original Received 1626 header fields are otherwise available, to ensure later 1627 accountability and diagnostic access to them. 1629 5.4. Gateways 1631 Gateways perform the basic routing and transfer work of message 1632 relaying, but they also make any message or address modifications 1633 that are needed to send the message into a messaging environment that 1634 operates according to different standards or potentially incompatible 1635 policies. When a Gateway connects two differing messaging services, 1636 its role is easy to identify and understand. When it connects 1637 environments that have technical similarity, but can have significant 1638 administrative differences, it is easy to think that a Gateway is 1639 merely an MTA. The critical distinction between an MTA and a Gateway 1640 is that the latter transforms addresses and/or message content, in 1641 order to map between the standards of two, different messaging 1642 services. In virtually all cases, this mapping process results in 1643 some degree of semantic loss. The challenge of Gateway design is to 1644 minimize this loss. 1646 A Gateway can set any identity field available to a regular MUA. 1647 Identities typically relevant to Gateways include: 1649 RFC2822.From 1651 Set by: original Originator 1653 Names and email addresses for the original author(s) of the 1654 message content are retained. As for all original addressing 1655 information in the message, the Gateway can translate addresses in 1656 whatever way will allow them continue to be useful in the target 1657 environment. 1659 RFC2822.Reply-To 1661 Set by: original Originator 1663 The Gateway SHOULD retain this information, if it is originally 1664 present. The ability to perform a successful reply by a Gatewayed 1665 Recipient is a typical test of Gateway functionality. 1667 RFC2822.Sender 1669 Set by: original Source or Mediator 1671 This can retain the original value or can be set to a new address 1673 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1675 Set by: original Recipient 1677 These usually retain their original addresses. 1679 RFC2821.MailFrom 1681 Set by: original Source or Mediator 1683 The agent responsible for gatewaying the message can choose to 1684 specify a new address to receive handling notices. 1686 RFC2822.Received 1688 Set by: Mediator 1689 The Gateway can record a Received header field, to indicate the 1690 transition from original posting to the new messaging environment. 1692 5.5. Boundary Filter 1694 Organizations often enforce security boundaries by subjecting 1695 messages to analysis, for conformance with the organization's safety 1696 policies. An example is detection of content classed as spam or a 1697 virus. A Filter might alter the content, to render it safe, such as 1698 by removing content deemed unacceptable. Typically these actions 1699 will result in the addition of content that records the actions. 1701 6. Security Considerations 1703 This document does not specify any new Internet Mail functionality. 1704 Consequently it is not intended to introduce any security 1705 considerations. 1707 However its discussion of the roles and responsibilities for 1708 different mail service modules, and the information they create, 1709 highlights the considerable security issues that are present when 1710 implementing any component of the Internet Mail service. In 1711 addition, email transfer protocols can operate over authenticated 1712 and/or encrypted links, and message content can be authenticated or 1713 encrypted. 1715 7. References 1717 7.1. Normative 1719 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 1720 RFC 821, August 1982. 1722 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1723 text messages", STD 11, RFC 822, August 1982. 1725 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1726 STD 13, RFC 1034, November 1987. 1728 [RFC1035] Mockapetris, P., "Domain names - implementation and 1729 specification", STD 13, RFC 1035, November 1987. 1731 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1732 STD 53, RFC 1939, May 1996. 1734 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1735 October 1996. 1737 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1738 Extensions (MIME) Part One: Format of Internet Message 1739 Bodies", RFC 2045, November 1996. 1741 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1742 Extensions (MIME) Part Two: Media Types", RFC 2046, 1743 November 1996. 1745 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1746 Part Three: Message Header Extensions for Non-ASCII Text", 1747 RFC 2047, November 1996. 1749 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1750 Internet Mail Extensions (MIME) Part Four: Registration 1751 Procedures", BCP 13, RFC 2048, November 1996. 1753 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1754 Extensions (MIME) Part Five: Conformance Criteria and 1755 Examples", RFC 2049, November 1996. 1757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1758 Requirement Levels", BCP 14, RFC 2119, March 1997. 1760 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1761 Specification", RFC 2181, July 1997. 1763 [RFC2304] Allocchio, C., "Minimal FAX address format in Internet 1764 Mail", RFC 2304, March 1998. 1766 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1767 for Core Mail List Commands and their Transport through 1768 Message Header Fields", RFC 2369, July 1998. 1770 [RFC2421] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 1771 Mail - version 2", RFC 2421, September 1998. 1773 [RFC2423] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME 1774 Sub-type Registration", RFC 2423, September 1998. 1776 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1778 [RFC2476] Gellens, R. and J. Klensin, "Message Submission", 1779 RFC 2476, December 1998. 1781 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1782 Addresses", RFC 2465, August 1999. 1784 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1785 April 2001. 1787 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1788 April 2001. 1790 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1791 and Namespace for the Identification of Mailing Lists", 1792 RFC 2919, March 2001. 1794 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 1795 RFC 3028, January 2001. 1797 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 1798 Negotiation for Messaging Services based on Email", 1799 RFC 3297, July 2002. 1801 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1802 Context for Internet Mail", RFC 3458, January 2003. 1804 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1805 Extension for Delivery Status Notifications (DSNs)", 1806 RFC 3461, January 2003. 1808 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1809 4rev1", RFC 3501, March 2003. 1811 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1812 Notification", RFC 3798, May 2004. 1814 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1815 Procedures for Message Header Fields", RFC 3864, 1816 September 2004. 1818 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 1819 Header Fields", RFC 4021, March 2005. 1821 7.2. Descriptive 1823 [ID-ffpim] 1824 Crocker, D. and G. Klyne, "Full-mode Fax Profile for 1825 Internet Mail: FFPIM", March 2004. 1827 [ID-spamops] 1828 Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 1829 E. Allman, "Email Submission Between Independent 1830 Networks", draft-spamops-00 (work in progress), 1831 March 2004. 1833 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 1834 RFC 1767, March 1995. 1836 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 1837 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1838 ACM SIGCOMM, 2002. 1840 Appendix A. Acknowledgements 1842 This work derives from a section in draft-hutzler-spamops 1843 [ID-spamops]. Discussion of the Source actor role was greatly 1844 clarified during discussions in the IETF's Marid working group. 1846 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1847 insight on the framework and details of the original drafts. 1849 Later reviews and suggestions were provided by Nathaniel Borenstein, 1850 Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, 1851 Eric Hall, Brad Knowles, Bruce Lilly, Mark E. Mallett, David 1852 MacQuigg, Chris Newman, Daryl Odnert, Rahmat M. Samik-Ibrahim, Hector 1853 Santos, Jochen Topf, Willemien Hoogendoorn. 1855 Diligent proof-reading was performed by Bruce Lilly, 1857 Author's Address 1859 Dave Crocker 1860 Brandenburg InternetWorking 1861 675 Spruce Drive 1862 Sunnyvale, CA 94086 1863 USA 1865 Phone: +1.408.246.8253 1866 Email: dcrocker@bbiw.net 1868 Full Copyright Statement 1870 Copyright (C) The Internet Society (2006). 1872 This document is subject to the rights, licenses and restrictions 1873 contained in BCP 78, and except as set forth therein, the authors 1874 retain all their rights. 1876 This document and the information contained herein are provided on an 1877 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1878 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1879 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1880 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1881 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1882 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1884 Intellectual Property 1886 The IETF takes no position regarding the validity or scope of any 1887 Intellectual Property Rights or other rights that might be claimed to 1888 pertain to the implementation or use of the technology described in 1889 this document or the extent to which any license under such rights 1890 might or might not be available; nor does it represent that it has 1891 made any independent effort to identify any such rights. Information 1892 on the procedures with respect to rights in RFC documents can be 1893 found in BCP 78 and BCP 79. 1895 Copies of IPR disclosures made to the IETF Secretariat and any 1896 assurances of licenses to be made available, or the result of an 1897 attempt made to obtain a general license or permission for the use of 1898 such proprietary rights by implementers or users of this 1899 specification can be obtained from the IETF on-line IPR repository at 1900 http://www.ietf.org/ipr. 1902 The IETF invites any interested party to bring to its attention any 1903 copyrights, patents or patent applications, or other proprietary 1904 rights that may cover technology that may be required to implement 1905 this standard. Please address the information to the IETF at 1906 ietf-ipr@ietf.org. 1908 Acknowledgment 1910 Funding for the RFC Editor function is provided by the IETF 1911 Administrative Support Activity (IASA).