idnits 2.17.00 (12 Aug 2021) /tmp/idnits52509/draft-crocker-email-arch-03.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1720. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (February 14, 2005) is 6304 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 1669, but not defined == Missing Reference: 'ID-ffpim' is mentioned on line 1659, but not defined == Missing Reference: 'ID-spamops' is mentioned on line 1686, but not defined == Outdated reference: draft-klyne-hdrreg-mail has been published as RFC 4021 ** 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 2298 (Obsoleted by RFC 3798) ** 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) Summary: 21 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SMTP D. Crocker 2 Internet-Draft Brandenburg InternetWorking 3 Expires: August 15, 2005 February 14, 2005 5 Internet Mail Architecture 6 draft-crocker-email-arch-03 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 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 20 Internet-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 August 15, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 Over its thirty-four year history, Internet mail has undergone 42 significant changes in scale and complexity. The first standardized 43 architecture for email specified a simple split between the user 44 world, in the form of Mail User Agents (MUA), and the transmission 45 world, in the form of the Mail Handling Service (MHS) composed of 46 Mail Transfer Agents (MTA). Core aspects of the service, such as 47 address and message style, have remained remarkably constant. 48 However public discussion of the architecture has not kept pace with 49 the real-world refinements. This document offers an enhanced 50 Internet Mail architecture to reflect the current service. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Service Overview . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2 Discussion venue . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.3 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Email Actor Roles . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1 User Actors . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.2 MHS Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.3 Administrative Actors . . . . . . . . . . . . . . . . . . . . 11 62 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 3.1 Mailbox Addresses . . . . . . . . . . . . . . . . . . . . . . 13 64 3.2 Domain Names . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 3.3 Message Identifiers . . . . . . . . . . . . . . . . . . . . . 14 66 3.4 Identity Referencing Convention . . . . . . . . . . . . . . . 15 67 4. Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 4.1 Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 4.2 Mail User Agent (MUA) . . . . . . . . . . . . . . . . . . . . 19 70 4.3 Mail Submission Agent (MSA) . . . . . . . . . . . . . . . . . 21 71 4.4 Mail Transfer Agent (MTA) . . . . . . . . . . . . . . . . . . 22 72 4.5 Mail Delivery Agent (MDA) . . . . . . . . . . . . . . . . . . 24 73 4.6 Message Store (MS) . . . . . . . . . . . . . . . . . . . . . . 25 74 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 5.1 Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 76 5.2 ReSending . . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 5.3 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 30 78 5.4 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 79 5.5 Security Filter . . . . . . . . . . . . . . . . . . . . . . . 34 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 82 7.1 References - Normative . . . . . . . . . . . . . . . . . . . . 34 83 7.2 Reference - Descriptive . . . . . . . . . . . . . . . . . . . 36 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 37 85 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 86 Intellectual Property and Copyright Statements . . . . . . . . 38 88 1. Introduction 90 Over its thirty-four year history, Internet mail has undergone 91 significant changes in scale and complexity. The first standardized 92 architecture for email specified a simple split between the user 93 world, in the form of Mail User Agents (MUA), and the transmission 94 world, in the form of the Mail Handling Service (MHS) composed of 95 Mail Transfer Agents (MTA). 97 The MHS is responsible for accepting a message from one User and 98 delivering it to one or more others. 100 +--------+ 101 +---------------->| User | 102 | +--------+ 103 | . 104 +--------+ | +--------+ . 105 | User +--+--------->| User | . 106 +--------+ | +--------+ . 107 . | . . 108 . | +--------+ . . 109 . +-->| User | . . 110 . +--------+ . . 111 . . . . 112 . . . . 113 . . . . 114 +--------------------------------------+ 115 | Mail Handling Service (MHS) | 116 +--------------------------------------+ 118 Figure 1: Basic Email Service Model 120 Over time the operational service has sub-divided each of these 121 "layers" into more specialized modules. Core aspects of the service, 122 such as address and message style, have remained remarkably constant. 123 However public discussion of the architecture has not kept pace with 124 the real-world refinements. This document offers an enhanced 125 Internet Mail architecture to reflect the current service. The 126 original distinction between user-level concerns and transfer-level 127 concerns is retained, and the elaboration to each "level" of the 128 architecture is discussed separately. 130 For Internet mail, the term "end-to-end" usually refers to a single 131 posting and the set of deliveries directly resulting from its single 132 transiting of the MHS. However, note that some uses of email 133 consider the entire email service -- including Originator and 134 Recipient -- as a subordinate component. For these services, 135 "end-to-end" refers to points outside of the email service. Examples 136 are voicemail over email [RFC2423], EDI over email [RFC1767], and 137 facsimile over email.[ID-ffpim] 139 The current draft seeks to: 141 o Document refinements to the email model 143 o Clarify functional roles for the architectural components 145 o Clarify identity-related issues, across the email service 147 o Provide a document that serves as a common venue for further 148 defining and citing modern Internet mail architecture 150 1.1 Service Overview 152 End-to-end Internet mail exchange is accomplished by using a 153 standardized infrastructure comprising: 155 o An email object 157 o Global addressing 159 o A connected sequence of point-to-point transfer mechanisms 161 o No prior arrangement between Originator and Recipient 163 o No prior arrangement between point-to-point transfer services, 164 over the open Internet 166 The end-to-end portion of the service is the message. Broadly the 167 message, itself, is divided between handling control information and 168 user message content. 170 A precept to the design of Internet mail is permitting user-to-user 171 and MTA-to-MTA interoperability with no prior, direct administrative 172 arrangement. That is, all participants rely on having the core 173 services be universally supported, either directly or through 174 Gateways that translate between Internet mail standards and other 175 email conventions. 177 For localized environments (Edge networks) prior, administrative 178 arrangement can include access control, routing constraints and 179 lookup service configuration. In recent years one change to local 180 environments is an increased requirement for authentication or, at 181 least, accountability. In these cases, the server performs explicit 182 validation of the client's identity. 184 1.2 Discussion venue 186 Discussion about this document should be directed to the IETF-SMTP 187 mailing list . It is the most active, 188 long-standing venue for discussing email architecture. Although it 189 is primarily for discussing only the SMTP protocol, it is recommended 190 that discussion of this draft take place on that mailing list because 191 it attends to end-to-end infrastructure and architecture issues more 192 than other email-related mailing lists. 194 1.3 Changes 196 This is intended to be the last major revision, prior to seeking 197 publication. 199 Significant changes to this version: 201 Administrative Domain: Extensive discussion of this operational 202 construct, including distinguishing User, Edge and Transit ADs. 203 This elaborates the reference to "providers" in earlier drafts. 205 Mediator: Extensive revision both to the description of Mediator 206 and use of the construct throughout the document. 208 Gateway: The construct of a gateway is elaborated. 210 Set by: Tables that had an entry for "Actor:" have been changed to 211 "Set by:" in order to clarify the nature of the Actor reference 212 being made. It is intended to indicate who is responsible for 213 setting the identity, rather than indicate what identity is 214 referred to. The specific references were carefully reviewed and 215 modified, to reflect this focus. The list of "set by" entries was 216 extensively reviewed, with substantial modifications made. 218 Editorial proofing: A complete word-smithing pass over the 219 document. 221 2. Email Actor Roles 223 Internet Mail is a highly distributed service, with a variety of 224 actors serving different roles. These divide into: 226 o User 228 o Mail Handling Service (MHS) 230 o Administrative Domain 231 Although related to a technical architecture, the focus on Actors 232 concerns participant responsibilities, rather than on functional 233 modules. Hence the labels used are different than for classic email 234 architecture diagrams. Actors often will be associated with 235 different organizations. This operational independence provides the 236 motivation for distinguishing Administrative Domains. 238 2.1 User Actors 240 Users are the sources and sinks of messages. They may have an 241 exchange that iterates and they may expand or contract the set of 242 Users participating in a set of exchanges. In Internet Mail there 243 are three types of user-level Actors: 245 o Originators 247 o Recipients 249 o Mediators 251 From the User-level perspective all mail transfer activities are 252 performed by a monolithic, shared MHS. Users are customers of this 253 service. 255 The following depicts the relationships among them. 257 +------------+ 258 | Originator |<--------------+ 259 +-+---+----+-+ | 260 | | | | 261 | | V | 262 | | +-----------+ | 263 | | | Recipient | | 264 | | +-----------+ | 265 | | | 266 | | +----------+ | 267 | | | | | 268 | V V | | 269 | +-----------+ +---+---+---+ 270 | | Mediator +--->| Recipient | 271 | +-----------+ +-----------+ 272 | 273 V 274 +-----------+ +-----------+ +-----------+ 275 | Mediator +--->| Mediator +--->| Recipient | 276 +-----------+ +-----------+ +-----------+ 278 Figure 2: Relationships Among User Actors 280 2.1.1 Originator 282 Also called "Author", this is the user-level participant responsible 283 for creating original content and requesting its transmission. The 284 MHS operates to send and deliver mail among Originators and 285 Recipients. 287 2.1.2 Recipient 289 The Recipient is a consumer of delivered content. 291 A Recipient may close the user-level communication loop by creating 292 and submitting a new message that replies to an Originator. An 293 example of an automated form of reply is the Message Disposition 294 Notification, which informs the Originator about the Recipient's 295 disposition of the message. See Section 4.1. 297 2.1.3 Mediator 299 A Mediator receives, aggregates, reformulates and redistributes 300 messages as part of a potentially-protracted, higher-level exchange 301 among Users. Example uses of Mediators include group dialogue and 302 organizational message flow, as occurs with a purchase approval 303 process. Note that it is easy to confuse this user-level activity 304 with the underlying MHS exchanges. However they serve very different 305 purposes and operate is very different ways. Mediators are 306 considered extensively in Section 5. 308 When mail is delivered to an envelope address, a Mediator is viewed 309 by the Mail Handling Service as a Recipient. When submitting 310 messages, the Mediator is an Originator. What is distinctive is that 311 a Mediator preserves the Originator information of the message it 312 reformulates, but may make meaningful changes to the content. Hence 313 the MHS sees a new message, but Users receive a message that is 314 interpreted as primarily being from -- or, at least, initiated by -- 315 the author of the original message. The role of a Mediator permits 316 distinct, active creativity, rather than being limited to the more 317 constrained job of merely connecting together other participants. 318 Hence it is really the Mediator that is responsible for the new 319 message. 321 A Mediator's task may be complex and contingent, such as by modifying 322 and adding content or regulating which users may participate and 323 when. The popular example of this role is a group mailing list. A 324 sequence of mediators may even perform a series of formal steps, such 325 as reviewing, modifying and approving a purchase request. 327 Because a Mediator originates messages, it might also receive 328 replies. So, a Mediator really is a full-fledged User. 330 Gateway: A Gateway is a particularly interesting form of Mediator. 331 It is a hybrid of User and Relay that interconnects heterogeneous 332 mail services. Its goal of emulating a Relay, so Gateway is 333 described in the next section. 335 2.2 MHS Actors 337 The Mail Handling Service (MHS) has the task of performing a single, 338 email-level end-to-end transfer, on behalf of the Originator and 339 reaching the Recipient address(es) specified in the envelope. 340 Mediated or protracted, iterative exchanges, such as those used for 341 collaboration over time, are part of the User-level service, and are 342 not part of this Transfer-level service. 344 The following depicts the relationships among transfer participants 345 in Internet Mail. It shows the Source as distinct from the 346 Originator, and Destination as distinct from Recipient, although it 347 is common for each pair to be the same actor. The figure also shows 348 multiple Relays in the sequence. It is legal to have only one, and 349 for intra-organization mail services, this is common. 351 +------------+ +-----------+ 352 | Originator | | Recipient | 353 +-----+------+ +-----------+ 354 | ^ 355 | Mail Handling Service | 356 /+=================================================+\ 357 || | | || 358 || | | || 359 V | 360 +---------+ +--------+ +----+----+ 361 | | | |<------------+ | 362 | Source +...>| Notice | | Dest | 363 | | | |<---+ | | 364 +----+----+ +--------+ | +---------+ 365 | | ^ 366 V | | 367 +---------+ +----+----+ +----+----+ 368 | Relay +-->.......-->| Relay +-->| Relay | 369 +---------+ +----+----+ +---------+ 370 | 371 V 372 +---------+ 373 | Gateway +-->... 374 +---------+ 376 Figure 3: Relationships Among MHS Actors 378 2.2.1 Source 380 The Source role is responsible for ensuring that a message is valid 381 for posting and then submitting it to a Relay. Validity includes 382 conformance with Internet mail standards, as well as with local 383 operational policies. The source may simply review the message for 384 conformance, and reject it if there are errors, or it may create some 385 or all of the necessary information. 387 The Source operates with dual "allegiance". It serves the Originator 388 and often it is the same entity. However its role in assuring 389 validity means that it must also represent the local operator of the 390 MHS, that is, the local Administrative Domain. 392 The Source also has the responsibility for any post-submission, 393 Originator-related administrative tasks associated with message 394 transmission and delivery. Notably this pertains to error and 395 delivery notices. Hence, Source is best held accountable for the 396 message content, even when they did not create any or most of it. 398 2.2.2 Notifications Handler 400 The Notifications Handler processes service notifications that are 401 generated by the MHS, as a result of its efforts to transfer or 402 deliver the message. Notices may be about failures or completions 403 and are sent to an address that is specified by the Source. This 404 Notices handling address (also known as a Bounce or Return address) 405 might have no visible characteristics in common with the address of 406 the Originator or Source. 408 2.2.3 Relay 410 A mail Relay performs email transfer-service routing and 411 store-and-forward. It adds envelope-level handling information and 412 then (re-)transmits the message on towards its Recipient(s). A Relay 413 may add information to the envelope, such as with trace information. 414 However it does not modify existing envelope information or the 415 message content semantics. It may modify message content syntax, 416 such as a change from text to binary transfer-encoding form, only as 417 required to meet the capabilities of the next hop in the MHS. 419 A set of Relays composes a Mail Handling Service network. This is 420 above any underlying packet-switching network that they might be 421 using. Hence, interesting email scenarios can involve three levels 422 of store-and-forward: 424 o User Mediators 426 o MHS Relays 428 o Packet Switches 430 Aborting a message transfer results in having the Relay become an 431 Originator and send an error message to the Notifications (Bounce) 432 address. (The potential for looping is avoided by having this 433 message, itself, contain no Notifications address.) 435 2.2.4 Gateway 437 A Gateway is a hybrid form of User and Relay that interconnects 438 heterogeneous mail services. It operates as a User process, but its 439 purpose is simply to Relay messages. The more closely a Gateway is 440 able to operate as a Relay, the better. Differences between mail 441 services can be as small as minor syntax variations, but usually 442 encompass significant, semantic distinctions. For example, the 443 concept of an email address might be as different as a hierarchical, 444 machine-specific address versus a flat, global name space. Or 445 between text-only content and multi-media. Hence the Relay function 446 in a Gateway offers the minor challenge in design. The more 447 significant challenge is in ensuring the user-to-user functionality 448 that matches syntax and semantics of independent email standards 449 suites. 451 The basic test of a Gateway's adequacy is, of course, whether an 452 Originator on one side of a Gateway can send a message to a Recipient 453 on the other side, without requiring changes to any of the components 454 in the Originator's or Recipient's mail services, other than adding 455 the Gateway. To each of these otherwise independent services, the 456 Gateway will appear to be a "native" participant. However the 457 ultimate test of a Gateway's adequacy is whether the Originator and 458 Recipient can sustain a dialogue. In particular, can a Recipient's 459 MUA automatically formulate a valid Reply? 461 2.3 Administrative Actors 463 Operation of Internet mail services is apportioned to different 464 providers (or operators). Each can be composed of an independent 465 Administrative Domain (AD). Examples include an end-user operating 466 their desktop client, a department operating a local Relay, an IT 467 department operating an enterprise Relay, and an ISP operating a 468 public, shared email service. These can be configured into many 469 combinations of administrative and operational relationships, with 470 each Administrative Domain potentially having a complex arrangement 471 of functional components. Figure 4 depicts the relationships among 472 ADs. Perhaps the most salient aspect of an AD is the differential 473 trust that determines its policies for activities within the AD, 474 versus those involving interactions with other ADs. 476 Basic components of AD distinction include: 478 Transit: These are Mail Service Providers (MSP) offering 479 value-added capabilities for Edge ADs, such as aggregation and 480 filtering. 482 Edge: Independent transfer services, in networks at the edge of the 483 Internet mail service. 485 User: End-user services. This might be subsumed under the Edge 486 service, such as is common for web-based email access. 488 Note that Transit services are quite different from packet-level 489 transit operation. Whereas end-to-end packet transfers usually go 490 through intermediate routers. Email exchange across the open 491 Internet is often directly between the Edge ADs, at the email level. 493 +------ +------+ +------+ 494 | AD-1 | | AD-3 | | AD-4 | 495 | ---- | | ---- | | ---- | 496 | | +---------------------->| | | | 497 | User | | |-Edge-+---->|-User | 498 | | | | +--->| | | | 499 | V | | | +------+ +------+ 500 | Edge-+----+ | 501 | | | +---------+ | 502 +------+ | | AD-2 | | 503 | | ------- | | 504 | | | | 505 +--->|-Transit-+---+ 506 | | 507 +---------+ 509 Figure 4: Administrative Domains (AD) 511 Edge networks may use proprietary email standards internally. 512 However the distinction between Transit network and Edge network 513 transfer services is primarily significant because it highlights the 514 need for concern over interaction and protection between independent 515 administrations. In particular, this distinctions calls for 516 additional care in assessing transitions of responsibility, as well 517 as the accountability and authorization relationships among 518 participants in email transfer. 520 The interactions between functional components within an 521 Administrative Domain are subject to the policies of that domain. 522 Policies can cover such things as reliability, access control, 523 accountability and even content evaluation and modification. They 524 may be implemented in different functional components, according to 525 the needs of the Administrative Domain. For example, see 526 [ID-spamops]. 528 User, Edge and Transit services can be offered by providers that 529 operate component services or sets of services. Further, it is 530 possible for one AD to host services for other ADs. Common AD 531 examples are: 533 Enterprise Service Providers: 535 Operating an organization's internal data and/or mail operations. 537 Internet Service Providers: 539 Operating underlying data communication services that, in turn, 540 are used by one or more Relays and Users. It is not their job to 541 perform email functions, but to provide an environment in which 542 those functions can be performed. 544 Mail Service Providers: 546 Operate email services, such as for end-users, or mailing lists. 548 Operational pragmatics often dictate that providers be involved in 549 detailed administration and enforcement issues, to help ensure the 550 health of the overall Internet Mail Service. This can include 551 operators of lower-level packet services. 553 3. Identities 555 Internet mail uses three forms of identity. The most common is the 556 mailbox address [RFC2822]. The other two are the domain 557 name [RFC1034] and message identifier [RFC2822]. 559 3.1 Mailbox Addresses 561 "A mailbox sends and receives mail. It is a conceptual entity 562 which does not necessarily pertain to file storage." [RFC2822] 564 A mailbox is specified as an Internet mail address . It 565 has two distinct parts, divided by an at-sign ("@"). The right-hand 566 side contains a globally interpreted name for an administrative 567 domain. This domain name might refer to an entire organization, or 568 to a collection of machines integrated into a homogeneous service, or 569 to a single machine. Domain names are defined and operated through 570 the Domain Name Service (DNS) [RFC1034], [RFC1035], [RFC2181]. 572 The portion to the left of the at-sign contains a string that is 573 globally opaque and is called the . It is to be 574 interpreted only by the entity specified in the address's right-hand 575 side. All other entities must treat the local-part as a 576 uninterpreted, literal string and must preserve all of its original 577 details. As such, its public distribution is equivalent to sending a 578 "cookie" that is only interpreted upon being returned to its 579 originator. 581 3.1.1 Global Standards for Local-Part 583 It is common for sites to have local structuring conventions for the 584 left-hand side (local-part) of an addr-spec. This permits 585 sub-addressing, such as for distinguishing different discussion 586 groups by the same participant. However it must be stressed that 587 these conventions are strictly private to the user's organization and 588 must not be interpreted by any domain except the one listed in the 589 right-hand side of the addr-spec. 591 A small class of addresses has an elaboration on basic email 592 addressing, with a standardized, global schema for the local-part. 593 These are conventions between originating end-systems and Recipient 594 Gateways, and they are invisible to the public email transfer 595 infrastructure. When an Originator is explicitly sending via a 596 Gateway out of the Internet, there are coding conventions for the 597 local-part, so that the Originator can formulate instructions for the 598 Gateway. Standardized examples of this are the telephone numbering 599 formats for VPIM [RFC2421], such as "+16137637582@vpim.example.com", 600 and iFax [RFC2304], such as "FAX=+12027653000/ 601 T33S=1387@ifax.example.com". 603 3.1.2 Scope of Email Address Use 605 Email addresses are being used far beyond their original email 606 transfer and delivery role. In practical terms, email strings have 607 become a common form of user identity on the Internet. What is 608 essential, then, is to be clear about the nature and role of an 609 identity string in a particular context and to be clear about the 610 entity responsible for setting that string. 612 3.2 Domain Names 614 A domain name is a global reference to an Internet resource, such as 615 a host, a service or a network. A name usually maps to one or more 616 IP Addresses. A domain name can be administered to refer to 617 individual users, but this is not common practice. The name is 618 structure as a hierarchical sequence of sub-names, separated by dots 619 ("."). 621 When not part of a mailbox address, a domain name is used in Internet 622 mail to refer to a node that took action upon the message, such as 623 providing the administrative scope for a message identifier, or 624 performing transfer processing. 626 3.3 Message Identifiers 628 Like mailbox addresses, message identifiers have two distinct parts, 629 divided by an at-sign ("@"). The right-hand side is globally 630 interpreted and specifies the administrative domain assigning the 631 identifier. The left-hand side of the at-sign contains a string that 632 is globally opaque and serves to uniquely identify the message within 633 the domain referenced on the right-hand side. The duration of 634 uniqueness for the message identifier is undefined. 636 The identifier may be assigned by the user or by any component of the 637 system along the path, within the AD responsible for the indicated 638 domain. Although Internet mail standards provide for a single 639 identifier, more than one is sometimes assigned. 641 3.4 Identity Referencing Convention 643 In this document, fields references to identities are labeled in a 644 two-part, dotted notation. The first part cites the document 645 defining the identity and the second defines the name of the 646 identity. Hence, is the From field in an email 647 content header, and is the address in the SMTP 648 "Mail From" command. 650 4. Services 652 The Internet's MHS architecture distinguishes six types of functional 653 components, arranged to support a store-and-forward service 654 architecture: 656 o Message 658 o Mail User Agent (MUA) 660 o Message Submission Agent (MSA) 662 o Message Transfer Agent (MTA) 664 o Message Delivery Agent (MDA) 666 o Message Store (MS) 668 This section describes the specific functional components for 669 Internet Mail, and the standard protocols associated with performing 670 them. 672 This figure shows function modules and the protocols used between 673 them. 675 +------+ 676 ...............+ oMUA |<------------------------------+ 677 . +--+---+ | 678 . | {smtp, submission | 679 . V | 680 . +------+ | 681 . | MSA |<--------------------+ | 682 . +--+---+ | | 683 . | {smtp | | 684 . V | | 685 . +------+ /+===+===+\ | 686 . | MTA | || dsn || | 687 /+==========+\ +--+---+ \+=======+/ | 688 || MESSAGE || . {smtp ^ ^ | 689 ||----------|| . | | | 690 || Envelope || . | | | 691 || SMTP || V | | | 692 || RFC2822 || +------+ | | /+==+==+\ 693 || Content || | MTA +-------------------+ | || mdn || 694 || RFC2822 || +--+---+ | \+=====+/ 695 || MIME || | {local, smtp, lmtp | | 696 \+==========+/ V | | 697 . +------+ | | 698 . | +-----------------------+ | 699 . | MDA | | 700 . | |<--------------------+ | 701 . +-+--+-+ | | 702 . local} | | | | 703 . V | | | 704 . +------+ | /+===+===+\ | 705 . | MS-1 | | || sieve || | 706 . +-+--+-+ | \+=======+/ | 707 . | | | {pop, imap ^ | 708 . | V V | | 709 . | +------+ | | 710 . | | MS-2 | | | 711 . | +--+---+ | | 712 . | | {pop, imap, local | | 713 . V V | | 714 . +------+ | | 715 ...........>| rMUA +------------------------+---------+ 716 +------+ 718 Figure 5: Protocols and Services 720 Software implementations of these architectural components often 721 compress them, such as having the same software do MSA, MTA and MDA 722 functions. However the requirements for each of these components of 723 the service are becoming more extensive. So, their separation is 724 increasingly common. 726 NOTE: 728 A discussion about any interesting system architecture is often 729 complicated by confusion between architecture versus 730 implementation. An architecture defines the conceptual functions 731 of a service, divided into discrete conceptual modules. An 732 implementation of that architecture may combine or separate 733 architectural components, as needed for a particular operational 734 environment. It is important not to confuse the engineering 735 decisions that are made to implement a product, with the 736 architectural abstractions used to define conceptual functions. 738 4.1 Message 740 The purpose of the Mail Handling Service is to exchange a message 741 object among participants. Hence, all of the underlying mechanisms 742 are merely in the service of getting that message from its Originator 743 to its Recipients. A message may be explicitly labeled as to its 744 nature. [RFC3458] 746 A message comprises a transit handling envelope and the end-user 747 message content. The envelope contains handling information used by 748 the Message Handling Service, or generated by it. The content is 749 divided into a structured header and the body. The body may be 750 unstructured, simple text, or it may be a tree of multi-media 751 subordinate objects. 753 Internet mail has distinguished some special versions of messages, 754 for exchanging control information: 756 Delivery Status Notification (DSN): 758 A Delivery Status Notification (DSN) may be generated by the Mail 759 Handling Service (MSA, MTA or MDA) and sent to the 760 RFC2821.MailFrom address. It provides information about message 761 transit, such as transmission errors or successful delivery. 762 [RFC3461] 764 Message Disposition Notification (MDN): 766 A Message Disposition Notification (MDN) may be generated by an 767 rMUA and is sent to the Disposition-Notification-To address. It 768 provides information about Recipient-side message processing, such 769 as indicating that the message has been read [RFC2298] or the form 770 of content that can be supported. [RFC3297] 772 Message Filtering (SIEVE): 774 SIEVE provides a means of specifying conditions for differential 775 handling of mail, at the time of delivery. [RFC3028] 777 4.1.1 Envelope 779 Information that is directly used by, or produced by, the email 780 transfer service is called the "envelope". It controls and records 781 handling activities by the transfer service. Internet mail has a 782 fragmented framework for handling this "handling" information. The 783 envelope exists partly in the transfer protocol SMTP [RFC2821] and 784 partly in the message object [RFC2822]. The SMTP specification uses 785 the term to refer only to the transfer-protocol information. 787 NOTE: 789 Due to the frequent use of the term "envelope" to refer only to 790 SMTP constructs, there has been some call for using a different 791 term, to label the larger set of information defined here. So 792 far, no alternative term has developed any community support. 794 Direct envelope addressing information, as well as optional transfer 795 directives, are carried within the SMTP control channel. Other 796 envelope information, such as trace records, is carried within the 797 content header fields. Upon delivery, SMTP-level envelope 798 information is typically encoded within additional content header 799 fields, such as Return-Path. 801 4.1.2 Message Header Fields 803 Header fields are attribute/value pairs covering an extensible range 804 of email service, user content and user transaction meta-information. 805 The core set of header fields is defined in [RFC2822], [RFC0822]. It 806 is common to extend this set, for different applications. A complete 807 set of registered header fields is being developed through 808 [ID-hdr-reg]. 810 One danger with placing additional information in header fields is 811 that Gateways often alter or delete them. 813 4.1.3 Body 815 The body of a message might simply be lines of ASCII text or it might 816 be structured into a composition of multi-media, body-part 817 attachments, using MIME [RFC2045], [RFC2046], [RFC2047], [RFC2048], 818 and [RFC2049]. It should be noted that MIME structures each 819 body-part into a recursive set of MIME header field meta-data and 820 MIME Content sections. 822 4.1.4 Identity References in a Message 824 For a message in transit, the core uses of identity references 825 combine into: 827 +-----------------------+-------------+---------------------+ 828 | Layer | Field | Set By | 829 +-----------------------+-------------+---------------------+ 830 | Message Body | MIME Header | Originator | 831 | Message header fields | From | Originator | 832 | | Sender | Source | 833 | | Reply-To | Originator | 834 | | To, CC, BCC | Originator | 835 | | Message-ID | Source | 836 | | Received | Source, Relay, Dest | 837 | | Return-Path | MDA, from MailFrom | 838 | | Resent-* | Mediator | 839 | SMTP | HELO | Latest Relay Client | 840 | | MailFrom | Source | 841 | | RcptTo | Originator | 842 | IP | IP Address | Latest Relay Client | 843 +-----------------------+-------------+---------------------+ 845 4.2 Mail User Agent (MUA) 847 A Mail User Agent (MUA) works on behalf of end-users and end-user 848 applications. It is their "representative" within the email service. 850 At the origination side of the service, the oMUA is used to create a 851 message and perform initial "submission" into the transfer 852 infrastructure, via a Mail Submission Agent (MSA). It may also 853 perform any creation- and posting-time archival. An MUA outbox is 854 part of the origination-side MUA. 856 The Recipient-side rMUA works on behalf of the end-user Recipient to 857 process received mail. This includes generating user-level return 858 control messages, display and disposition of the received message, 859 and closing or expanding the user communication loop, by initiating 860 replies and forwarding new messages. 862 An MUA may, itself, have a distributed architecture, such as 863 implementing a "thin" user interface module on a limited end-user 864 device, with the bulk of the MUA functionality operated remotely on a 865 more capable server. An example of such an architecture might use 866 IMAP [RFC3501] for most of the interactions between an MUA client and 867 an MUA server. 869 A Mediator is special class of MUA performs message re-posting, as 870 discussed in Section 2.1. 872 Identity fields relevant to the MUA include: 874 RFC2822.From 876 Set by: Originator 878 Names and addresses for author(s) of the message content are 879 listed in the From field 881 RFC2822.Reply-To 883 Set by: Originator 885 If a message Recipient sends a reply message that would otherwise 886 use the RFC2822.From field address(es) contained in the original 887 message, then they are instead to use the address(es) in the 888 RFC2822.Reply-To field. In other words, this field is a direct 889 override of the From field, for responses from Recipients. 891 RFC2822.Sender 893 Set by: Source 895 This specifies the address responsible for submitting the message 896 into the transfer service. For efficiency, this field should be 897 omitted if it contains the same address as RFC2822.From. However 898 this does not mean there is no Sender specified. Rather, it means 899 that that header field is virtual and that the address in the From 900 field must be used. Specification of the error return addresses 901 -- the "Notifications" (or "bounces") address, contained in 902 RFC2821.MailFrom -- is made by the RFC2822.Sender. Typically the 903 Notifications address is the same as the Sender address. However 904 some usage scenarios require it to be different. 906 RFC2822.To, RFC2822.CC 908 Set by: Originator 910 These specify MUA Recipient addresses. The addresses in the 911 fields might not be present in the RFC2821.RcptTo command. The 912 distinction between To and CC is subjective. Generally, a To 913 addressee is considered primary and is expected to take action on 914 the message. A CC addressee typically receives a copy only for 915 their information. 917 RFC2822.BCC 919 Set by: Originator 921 A message might be copied to an addressee whose participation is 922 not to be disclosed to the RFC2822.To or RFC2822.CC Recipients 923 and, usually, not to the other BCC Recipients. The BCC header 924 field indicates a message copy to such a Recipient. Typically, 925 the field lists no addresses or only lists the address of the 926 Recipient receiving this copy. An MUA will typically make 927 separate postings for TO and CC Recipients, versus BCC Recipients. 928 The former will see no indication that any BCCs were sent, whereas 929 the latter have a BCC field present. It might be empty, contain a 930 comment, or contain one or more BCC addresses, depending upon the 931 preferences or the Originator. 933 4.3 Mail Submission Agent (MSA) 935 A Mail Submission Agent (MSA) accepts the message submission from the 936 oMUA and enforces the policies of the hosting AD and the requirements 937 of Internet standards. Enforcement might be passive, involving 938 review and approval or rejection, or it might be active, involving 939 direct modification of the message. An MSA implements a server 940 function to MUAs and a client function to MTAs (or MDAs). 942 Examples of MSA-styled functions, in the world of paper mail, might 943 range across the very different capabilities of administrative 944 assistants, postal drop boxes, and post office front-counter 945 employees. 947 The MUA/MSA interface can be implemented within a single host and use 948 private conventions for its interactions. Historically, 949 standards-based MUA/MSA interactions have used SMTP [RFC2821]. 950 However a recent alternative is SUBMISSION [RFC2476]. Although 951 SUBMISSION derives from SMTP, it operates on a separate TCP port, and 952 will typically impose distinct requirements, such as access 953 authorization. 955 Identities relevant to the MSA include: 957 RFC2821.HELO or RFC2821.EHLO 958 Set by: Source 960 The MSA may specify its hosting domain identity for the SMTP HELO 961 or EHLO command operation. 963 RFC2821.MailFrom 965 Set by: Source 967 This is an end-to-end string that specifies an email address for 968 receiving return control information, such as "bounces". The name 969 of this field is misleading, because it is not required to specify 970 either the author or the agent responsible for submitting the 971 message. Rather, the agent responsible for submission specifies 972 the RFC2821.MailFrom address. Ultimately the simple basis for 973 deciding what address needs to be in the RFC2821.MailFrom is to 974 determine what address needs to be informed about 975 transmission-level problems (and, possibly, successes.) 977 RFC2821.RcptTo 979 Set by: Originator 981 This specifies the MUA mailbox address of a recipient. The string 982 might not be visible in the message content header. For example, 983 the message destination address header fields, such as RFC2822.To, 984 might specify a mailing list address, while the RFC2821.RcptTo 985 address specifies a member of that list. 987 RFC2821.Received 989 Set by: Source 991 An MSA may record a Received header field, to indicate initial 992 submission trace information, including originating host and MSA 993 host domain names and/or IP Addresses. 995 4.4 Mail Transfer Agent (MTA) 997 A Mail Transfer Agent (MTA) relays mail. It is like a packet-switch 998 or IP router in that its job is to make routing assessments and to 999 move the message closer to the Recipient(s). Relaying is performed 1000 by a sequence of MTAs, until the message reaches its destination MDA. 1001 Hence an MTA implements both client and server MTA functionality. It 1002 does not make changes to addresses in the envelope or reformulate the 1003 content, except as transfer-encoding requirements dictate. Also it 1004 may add trace information. 1006 The primary "routing" mechanism for Internet mail is the DNS MX 1007 record [RFC1035]. As with most network layer mechanisms Internet 1008 mail's SMTP supports a basic level of reliability, by virtue of 1009 providing for retransmission after a temporary transfer failure. 1010 However the degree of persistence by an MTA can be highly variable. 1012 Of course email objects are typically much larger than the payload of 1013 a packet or datagram, and the end-to-end latencies are typically much 1014 higher. Contrary to typical packet switches (and Instant Messaging 1015 services) Internet mail MTAs typically store messages in a manner 1016 that allows recovery across service interruptions, such as host 1017 system shutdown. 1019 Internet mail primarily uses SMTP [RFC2821], [RFC0821] to effect 1020 point-to-point transfers between peer MTAs. Other transfer 1021 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. 1023 An important characteristic of MTA-MTA communications, over the open 1024 Internet, is that they do not require prior arrangement between the 1025 independent administrations operating the different MTAs. Given the 1026 importance of spontaneity and serendipity in the world of human 1027 communications, this lack of prearrangement, between the 1028 participants, is a core benefit of Internet mail and remains a core 1029 requirement for it. 1031 Identities relevant to the MTA include: 1033 RFC2821.HELO 1035 Set by: Relay 1037 The MTA may specify its hosting domain identity for the SMTP HELO 1038 or EHLO command. This is the only standardized way of identifying 1039 the agent responsible for operation of the Relay, during the 1040 transfer operation. 1042 RFC2821.MailFrom 1044 Set by: Source 1046 This is an end-to-end string that specifies an email address for 1047 receiving return control Notifications, such as "bounces". The 1048 name of this field is misleading, because it is not required to 1049 specify either the author or the agent responsible for submitting 1050 the message. Rather, the agent responsible for submission 1051 specifies the MailFrom address. Ultimately the simple basis for 1052 deciding what address needs to be in the RFC2821.MailFrom is to 1053 determine what address needs to be informed about 1054 transmission-level problems (and, possibly, successes.) 1056 RFC2821.RcptTo 1058 Set by: Originator 1060 This specifies the MUA mailbox address of a Recipient. The string 1061 might not be visible in the message content header. For example, 1062 the message destination address header fields, such as RFC2822.To, 1063 might specify a mailing list address, while the RFC2821.RcptTo 1064 address specifies a member of that list. 1066 RFC2822.Received 1068 Set by: Relay 1070 An MTA must record a Received header field, to indicate trace 1071 information, including source host and receiving host domain names 1072 and/or IP Addresses. 1074 4.5 Mail Delivery Agent (MDA) 1076 A Mail Delivery Agent (MDA) delivers email to the Recipient's 1077 mailbox. It can provide distinctive, address-based functionality, 1078 made possible by its detailed knowledge of the properties of the 1079 destination address. This knowledge might also be present elsewhere 1080 in the Recipient's Administrative Domain, such as at an 1081 organizational border Relay. However it is required for the MDA, if 1082 only because the MDA must know where to deliver the message. 1084 Using Internet protocols, delivery can be effected by a variety of 1085 standard protocols. When coupled with an internal, local mechanism, 1086 SMTP [RFC2821] and LMTP [RFC2033] permit "push" delivery to the 1087 Recipient system, at the initiative of the upstream email service. 1088 POP [RFC1939] and IMAP [RFC3501] are used for "pull" delivery at the 1089 initiative of the Recipient system. POP and IMAP can also be used 1090 for repeated access to messages on a remote MS. 1092 Identities relevant to the MDA include: 1094 RFC2821.Return-Path 1096 Set by: Source 1098 The MDA records the RFC2821.MailFrom address into the 1099 RFC2822.Return-Path field. 1101 RFC2822.Received 1103 Set by: Destination 1105 An MDA must record a Received header field, to indicate trace 1106 information, including source host and receiving host domain names 1107 and/or IP Addresses. 1109 4.6 Message Store (MS) 1111 An MUA can use a long-term Message Store (MS). A rich set of choices 1112 for the use of that store derives from permitting more than one to be 1113 associated with a single user, demonstrated as MS-1 and MS-2 in 1114 Figure 5. MS-1 is shown as being remote from the MUA and MS-2 as 1115 being local. Further the relationship between two message store may 1116 vary. Between the MDA and the MUA, these choices are supported by a 1117 wide variety of protocol options. 1119 The operational relationship among two MSs can be: 1121 Online: 1123 Only a remote MS is used, with messages being accessible only when 1124 the MUA is attached to the MS, and the MUA repeatedly fetches all 1125 or part of a message, from one session to the next. 1127 Offline: 1129 The MS is local to the user, and messages are moved from any 1130 remote store, rather than (also) being retained there. 1132 Disconnected: 1134 A remote MS and a local MS synchronize all or parts of their 1135 contents, while connected. The user may make changes while 1136 disconnected, and the two stores are re-synchronized upon 1137 reconnection. 1139 5. Mediators 1141 Basic email transfer is accomplished with an asynchronous 1142 store-and-forward communication infrastructure, in a sequence of 1143 independent transmissions through some number of MTAs. A very 1144 different task is a User-level sequence of postings and deliveries, 1145 through Mediators. For such re-postings, a Mediator does share some 1146 functionality with basic MTA relaying, but it enjoys a degree of 1147 freedom with both addressing and content that is not available to 1148 MTAs. 1150 RFC2821.HELO or RFC2821.EHLO 1152 Set by: Source or Relay 1154 The MSA may specify its hosting domain identity for the SMTP HELO 1155 or EHLO command operation. 1157 RFC2821.MailFrom 1159 Set by: Source 1161 This is an end-to-end string that specifies an email address for 1162 receiving return control Notifications, such as "bounces". The 1163 name of this field is misleading, because it is not required to 1164 specify either the author or the agent responsible for submitting 1165 the message. Rather, the agent responsible for submission 1166 specifies the RFC2821.MailFrom address. Ultimately the simple 1167 basis for deciding what address needs to be in the 1168 RFC2821.MailFrom is to determine what address needs to be informed 1169 about transmission-level problems (and, possibly, successes.) 1171 RFC2821.RcptTo 1173 Set by: Mediator 1175 This specifies the MUA mailbox address of a Recipient. The string 1176 might not be visible in the message content header. For example, 1177 the message destination address header fields, such as RFC2822.To, 1178 might specify a mailing list address, while the RFC2821.RcptTo 1179 address specifies a member of that list. 1181 RFC2821.Received 1183 Set by: Mediator 1185 An MSA may record a Received header field, to indicate initial 1186 submission trace information, including originating host and MSA 1187 host domain names and/or IP Addresses. 1189 The salient aspect of a Mediator, that distinguishes it from any 1190 other MUA creating an entirely new message, is that a Mediator 1191 preserves the integrity and tone of the original message, including 1192 the essential aspects of the original origination information. The 1193 Mediator might also add commentary. 1195 Examples of MUA message creation that are not performed by Mediators 1196 include: 1198 New Message Forwarding Existing Message: 1200 Curiously, this action provides a basic template for a class of 1201 Mediators. However by itself, it's typical occurrence is not, in 1202 fact, an example of a Mediator. The new message is viewed as 1203 being from the Agent doing the forwarding, rather than being from 1204 the original Originator. 1206 A new message encapsulates the original message and is seen as 1207 strictly "from" the Mediator. The Mediator might add commentary 1208 and certainly has the opportunity to modify the original message 1209 content. The forwarded message is therefore independent of the 1210 original message exchange and creates a new message dialogue. 1211 However the final Recipient sees the contained message as from the 1212 original Originator. 1214 Reply: 1216 When a Recipient formulates a response to a message, the new 1217 message is not typically viewed as being a "forwarding" of the 1218 original. It's focus is the new content; any inclusion of 1219 material from the original message is contextual and secondary. 1221 Annotator: 1223 The integrity of the original message is usually preserved, but 1224 one or more comments about the message are added in a manner that 1225 distinguishes commentary from original text. The tone of the new 1226 message is that it is primarily commentary from a new Originator, 1227 similar to a Reply. 1229 The remainder of this section describes common examples of Mediators. 1231 5.1 Aliasing 1233 A simple re-addressing facility that is available in most MDA 1234 implementations is called Aliasing. It is performed just before 1235 delivering a message to the specified Recipient's mailbox. Instead, 1236 the message is submitted back to the transfer service, for delivery 1237 to one or more alternate addresses. Although implemented as part of 1238 the message delivery service, this facility is strictly a Recipient 1239 user function. It resubmits the message, replacing the envelope 1240 address, on behalf of the mailbox address that was listed in the 1241 envelope. 1243 What is most distinctive about this forwarding mechanism is how 1244 closely it compares to normal MTA store-and-forward Relaying. In 1245 reality its only interesting difference is that it changes the 1246 RFC2821.RcptTo value. 1248 An MDA that is re-posting a message to an alias typically changes 1249 only envelope information: 1251 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1253 Set by: Originator 1255 These retain their original addresses. 1257 RFC2821.RcptTo 1259 Set by: Mediator 1261 This field contains an alias address. 1263 RFC2821.MailFrom 1265 Set by: Mediator or original Source 1267 The agent responsible for submission to an alias address will 1268 often retain the original address to receive handling 1269 Notifications. The benefit of retaining the original MailFrom 1270 value is to ensure that the origination-side agent knows that 1271 there has been a delivery problem. On the other hand, the 1272 responsibility for the problem usually lies with the Recipient, 1273 since the Alias mechanism is strictly under the Recipient's 1274 control. 1276 RFC2821.Received 1278 Set by: Mediator 1280 The agent should record Received information, to indicate the 1281 delivery to the original address and submission to the alias 1282 address. The trace of Received header fields should therefore 1283 include everything from original posting through final delivery to 1284 the alias. 1286 5.2 ReSending 1288 Also called ReDirecting, ReSending differs from Forwarding by virtue 1289 of having the Mediator "splice" a message's addressing information, 1290 to connect the Originator of the original message and the Recipient 1291 of the new message. This permits them to have direct exchange, using 1292 their normal MUA Reply functions. Hence the new Recipient sees the 1293 message as being From the original Originator, even if the Mediator 1294 adds commentary. 1296 Identities specified in a resent message include 1298 RFC2822.From 1300 Set by: original Originator 1302 Names and email addresses for the original author(s) of the 1303 message content are retained. The free-form (display-name) 1304 portion of the address might be modified to provide informal 1305 reference to the agent responsible for the redirection. 1307 RFC2822.Reply-To 1309 Set by: original Originator 1311 If this field is present in the original message, it is retained 1312 in the Resent message. 1314 RFC2822.Sender 1316 Set by: original Source 1318 This field is expected to contain the original Sender value. 1320 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1322 Set by: original Originator 1324 These specify the original message Recipients. 1326 RFC2822.Resent-From 1328 Set by: Mediator 1330 The address of the original Recipient who is redirecting the 1331 message. Otherwise, the same rules apply for the Resent-From 1332 field as for an original RFC2822.From field 1334 RFC2822.Resent-Sender 1335 Set by: Mediator 1337 The address of the agent responsible for re-submitting the 1338 message. For efficiency this field is often omitted if it 1339 contains the same address as RFC2822.Resent-From. However this 1340 does not mean there is no Resend-Sender specified. Rather, it 1341 means that that header field is virtual and that the address in 1342 the Resent-From field must be used. Specification of the error 1343 return addresses (the Notification address, contained in 1344 RFC2821.MailFrom) is made by the Resent-Sender. Typically the 1345 Notifications address is the same as the Resent-Sender address. 1346 However some usage scenarios require it to be different. 1348 RFC2822.Resent-To, RFC2822.Resent-cc, RFC2822.Resent-bcc: 1350 Set by: Mediator 1352 The addresses of the new Recipients who will now be able to reply 1353 to the original author. 1355 RFC2821.MailFrom 1357 Set by: Mediator 1359 The agent responsible for re-submission (RFC2822.Resent-Sender) is 1360 also responsible for specifying the new MailFrom address. 1362 RFC2821.RcptTo 1364 Set by: Mediator 1366 This will contain the address of a new Recipient 1368 RFC2822.Received 1370 Set by: Mediator 1372 When resending a message, the submission agent may record a 1373 Received header field, to indicate the transition from original 1374 posting to resubmission. 1376 5.3 Mailing Lists 1378 Mailing lists have explicit email addresses and they forward messages 1379 to a list of subscribed members. The Mailing List Actor performs a 1380 task that can be viewed as an elaboration of the ReDirector role. In 1381 addition to sending the new message to a potentially large number of 1382 new Recipients, the Mediator can modify content, such as deleting 1383 attachments, formatting conversion, and adding list-specific 1384 comments. In addition, archiving list messages is common. Still, 1385 the message retains characteristics of being "from" the original 1386 Originator. 1388 Identities relevant to a mailing list processor, when submitting a 1389 message, include: 1391 RFC2919.List-id 1393 Set by: Mediator 1395 This provides a global mailing list naming framework that is 1396 independent of particular hosts. Although [RFC2919] is a 1397 standards-track specification, it has not gained significant 1398 adoption. 1400 RFC2369.List-* 1402 Set by: Mediator 1404 [RFC2369] defines a collection of message header fields for use by 1405 mailing lists. In effect, they supply list-specific parameters 1406 for common mailing list user operations. The identifiers for 1407 these operations are for the list, itself, and the 1408 user-as-subscriber. 1410 RFC2822.From 1412 Set by: original Originator 1414 Names and email addresses for the original author(s) of the 1415 message content are specified. 1417 RFC2822.Reply-To 1419 Set by: original Originator or Mediator 1421 Mailing lists have introduced an ambiguity for the Reply-To field. 1422 Some List operations choose to force all replies to go to all list 1423 members. They achieve this by placing the list address into the 1424 RFC2822.Reply-To field. Hence, direct, "private" replies only to 1425 the original author cannot be achieved by using the MUA's typical 1426 "reply to author" function. If the author created a Reply-To 1427 field, its information is lost. 1429 RFC2822.Sender 1431 Set by: original Source or Mediator 1433 This will usually specify the address of the agent responsible for 1434 mailing list operations. However, some mailing lists operate in a 1435 manner very similar to a simple MTA Relay, so that they preserve 1436 as much of the original handling information as possible, 1437 including the original RFC2822.Sender field. 1439 RFC2822.TO, RFC2822.CC 1441 Set by: original Originator 1443 These will usually contain the original list of Recipient 1444 addresses. 1446 RFC2821.MailFrom 1448 Set by: original Source or Mediator 1450 This may contain the original address to be notified of 1451 transmission issues, or the mailing list agent may set it to 1452 contain a new Notification address. Typically, the value is set 1453 to a new address, so that mailing list members and posters are not 1454 burdened with transmission-related Notifications. 1456 RFC2821.RcptTo 1458 Set by: Mediator 1460 This contains the address of a mailing list member. 1462 RFC2821.Received 1464 Set by: Mediator 1466 An Mailing List Agent should record a Received header field, to 1467 indicate the transition from original posting to mailing list 1468 forwarding. The Agent may choose to have the message retain the 1469 original set of Received header fields or may choose to remove 1470 them. In the latter case, it should ensure that the original 1471 Received header fields are otherwise available, to ensure later 1472 accountability and diagnostic access to it. 1474 5.4 Gateways 1476 Gateways perform the basic routing and transfer work of message 1477 relaying, but they also make any message or address modifications 1478 that are needed to send the message into the next messaging 1479 environment. When a Gateway connects two differing messaging 1480 services, its role is easy to identify and understand. When it 1481 connects environments that have technical similarity, but may have 1482 significant administrative differences, it is easy to think that a 1483 Gateway is merely an MTA. The critical distinction between an MTA 1484 and a Gateway is that the latter transforms addresses and/or message 1485 content, in order to map between the standards of two, different 1486 messaging services. In virtually all cases, this mapping process 1487 results in some degree of semantic loss. The challenge of Gateway 1488 design is to minimize this loss. 1490 A Gateway may set any identity field available to a regular MUA. 1491 Identities typically relevant to Gateways include: 1493 RFC2822.From 1495 Set by: original Originator 1497 Names and email addresses for the original author(s) of the 1498 message content are retained. As for all original addressing 1499 information in the message, the Gateway may translate addresses in 1500 whatever way will allow them continue to be useful in the target 1501 environment. 1503 RFC2822.Reply-To 1505 Set by: original Originator 1507 The Gateway should retain this information, if it is originally 1508 present. The ability to perform a successful reply by a Gatewayed 1509 Recipient is a typical test of Gateway functionality. 1511 RFC2822.Sender 1513 Set by: original Source or Mediator 1515 This may retain the original value or may be set to a new address 1517 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1519 Set by: original Recipient 1520 These usually retain their original addresses. 1522 RFC2821.MailFrom 1524 Set by: original Source or Mediator 1526 The agent responsible for gatewaying the message may choose to 1527 specify a new address to receive handling notices. 1529 RFC2822.Received 1531 Set by: Mediator 1533 The Gateway may record a Received header field, to indicate the 1534 transition from original posting to the new messaging environment. 1536 5.5 Security Filter 1538 Organizations often enforce security boundaries by having message 1539 subjected to analysis for conformance with the organization's safety 1540 policies. Examples are detection of content classed as spam or a 1541 virus. A Security Filter might alter the content, to render it safe, 1542 such as by removing content deemed unacceptable. Typically these 1543 actions will result in the addition of content that records the 1544 actions. 1546 6. Security Considerations 1548 This document does not specify any new Internet mail functionality. 1549 Consequently it should introduce no new security considerations. 1551 However its discussion of the roles and responsibilities for 1552 different mail service modules, and the information they create, 1553 highlights the considerable security considerations that must be 1554 present when implementing any component of the Internet mail service. 1556 7. References 1558 7.1 References - Normative 1560 [ID-hdr-reg] 1561 "Registration of mail and MIME header fields", 1562 draft-klyne-hdrreg-mail-04.txt (work in progress), Apr 1563 2004. 1565 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 1566 821, August 1982. 1568 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1569 text messages", STD 11, RFC 822, August 1982. 1571 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1572 STD 13, RFC 1034, November 1987. 1574 [RFC1035] Mockapetris, P., "Domain names - implementation and 1575 specification", STD 13, RFC 1035, November 1987. 1577 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1578 STD 53, RFC 1939, May 1996. 1580 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1581 October 1996. 1583 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1584 Extensions (MIME) Part One: Format of Internet Message 1585 Bodies", RFC 2045, November 1996. 1587 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1588 Extensions (MIME) Part Two: Media Types", RFC 2046, 1589 November 1996. 1591 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1592 Part Three: Message Header Extensions for Non-ASCII Text", 1593 RFC 2047, November 1996. 1595 [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 1596 Internet Mail Extensions (MIME) Part Four: Registration 1597 Procedures", BCP 13, RFC 2048, November 1996. 1599 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1600 Extensions (MIME) Part Five: Conformance Criteria and 1601 Examples", RFC 2049, November 1996. 1603 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1604 Specification", RFC 2181, July 1997. 1606 [RFC2298] Fajman, R., "An Extensible Message Format for Message 1607 Disposition Notifications", RFC 2298, March 1998. 1609 [RFC2304] Allocchio, C., "Minimal FAX address format in Internet 1610 Mail", RFC 2304, March 1998. 1612 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1613 for Core Mail List Commands and their Transport through 1614 Message Header Fields", RFC 2369, July 1998. 1616 [RFC2421] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 1617 Mail - version 2", RFC 2421, September 1998. 1619 [RFC2423] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME 1620 Sub-type Registration", RFC 2423, September 1998. 1622 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1624 [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 1625 2476, December 1998. 1627 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1628 Addresses", RFC 2465, August 1999. 1630 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1631 April 2001. 1633 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1634 2001. 1636 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1637 and Namespace for the Identification of Mailing Lists", 1638 RFC 2919, March 2001. 1640 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 1641 3028, January 2001. 1643 [RFC3297] Klyne, G., Iwazaki, R. and D. Crocker, "Content 1644 Negotiation for Messaging Services based on Email", RFC 1645 3297, July 2002. 1647 [RFC3458] Burger, E., Candell, E., Eliot, C. and G. Klyne, "Message 1648 Context for Internet Mail", RFC 3458, January 2003. 1650 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1651 Extension for Delivery Status Notifications (DSNs)", RFC 1652 3461, January 2003. 1654 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1655 4rev1", RFC 3501, March 2003. 1657 7.2 Reference - Descriptive 1659 [ID-ffpim] 1660 Crocker, D. and G. Klyne, "Full-mode Fax Profile for 1661 Internet Mail: FFPIM", March 2004. 1663 [ID-spamops] 1664 Hutzler, C., Crocker, D., Resnick, P., Sanderson, R. and 1665 E. Allman, "Email Submission Between Independent 1666 Networks", draft-spamops-00 (work in progress), March 1667 2004. 1669 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1670 1767, March 1995. 1672 Author's Address 1674 Dave Crocker 1675 Brandenburg InternetWorking 1676 675 Spruce Drive 1677 Sunnyvale, CA 94086 1678 USA 1680 Phone: +1.408.246.8253 1681 EMail: dcrocker@bbiw.net 1683 Appendix A. Acknowledgements 1685 This work derives from a section in draft-hutzler-spamops 1686 [ID-spamops]. Discussion of the Source actor role was greatly 1687 clarified during discussions in the IETF's Marid working group. 1689 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1690 insight on the framework and details of early drafts. 1692 Additional review and suggestions were provided by Nathaniel 1693 Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, 1694 Ned Freed, Eric Hall, Bruce Lilly, Mark E. Mallett, Chris Newman, 1695 Daryl Odnert, Rahmat M. Samik-Ibrahim, Hector Santos, Jochen Topf, 1696 Willemien. 1698 Intellectual Property Statement 1700 The IETF takes no position regarding the validity or scope of any 1701 Intellectual Property Rights or other rights that might be claimed to 1702 pertain to the implementation or use of the technology described in 1703 this document or the extent to which any license under such rights 1704 might or might not be available; nor does it represent that it has 1705 made any independent effort to identify any such rights. Information 1706 on the procedures with respect to rights in RFC documents can be 1707 found in BCP 78 and BCP 79. 1709 Copies of IPR disclosures made to the IETF Secretariat and any 1710 assurances of licenses to be made available, or the result of an 1711 attempt made to obtain a general license or permission for the use of 1712 such proprietary rights by implementers or users of this 1713 specification can be obtained from the IETF on-line IPR repository at 1714 http://www.ietf.org/ipr. 1716 The IETF invites any interested party to bring to its attention any 1717 copyrights, patents or patent applications, or other proprietary 1718 rights that may cover technology that may be required to implement 1719 this standard. Please address the information to the IETF at 1720 ietf-ipr@ietf.org. 1722 Disclaimer of Validity 1724 This document and the information contained herein are provided on an 1725 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1726 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1727 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1728 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1729 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1730 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1732 Copyright Statement 1734 Copyright (C) The Internet Society (2005). This document is subject 1735 to the rights, licenses and restrictions contained in BCP 78, and 1736 except as set forth therein, the authors retain all their rights. 1738 Acknowledgment 1740 Funding for the RFC Editor function is currently provided by the 1741 Internet Society.