idnits 2.17.1 draft-crocker-email-arch-04.txt: -(1725): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1776. ** 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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 (March 28, 2005) is 6941 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 1721, but not defined == Missing Reference: 'ID-ffpim' is mentioned on line 1711, but not defined == Missing Reference: 'Tussle' is mentioned on line 1724, but not defined == Missing Reference: 'ID-spamops' is mentioned on line 1715, but not defined == Outdated reference: A later version (-05) exists of draft-klyne-hdrreg-mail-04 ** 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 (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ��� 2 SMTP D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Expires: September 29, 2005 March 28, 2005 6 Internet Mail Architecture 7 draft-crocker-email-arch-04 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 29, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Over its thirty-four year history, Internet Mail has undergone 43 significant changes in scale and complexity, as it has become a 44 global infrastructure service. The first standardized architecture 45 for email specified a simple split between the user world, in the 46 form of Mail User Agents (MUA), and the transmission world, in the 47 form of the Mail Handling Service (MHS) composed of Mail Transfer 48 Agents (MTA). Core aspects of the service, such as address and 49 message style, have remained remarkably constant. Today, Internet 50 Mail is marked by many independent operators, many different 51 components for providing users service and many others for performing 52 message transfer. Public discussion of the architecture has not kept 53 pace with the real-world technical and operational refinements. This 54 document offers an enhanced Internet Mail architecture to reflect the 55 current service. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Service Overview . . . . . . . . . . . . . . . . . . . . . 4 61 1.2 Discussion venue . . . . . . . . . . . . . . . . . . . . . 5 62 1.3 Changes . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Email Actor Roles . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1 User Actors . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2 MHS Actors . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.3 Administrative Actors . . . . . . . . . . . . . . . . . . 11 67 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 3.1 Mailbox Addresses . . . . . . . . . . . . . . . . . . . . 13 69 3.2 Domain Names . . . . . . . . . . . . . . . . . . . . . . . 14 70 3.3 Message Identifiers . . . . . . . . . . . . . . . . . . . 15 71 3.4 Identity Referencing Convention . . . . . . . . . . . . . 15 72 4. Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.1 Message . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 4.2 Mail User Agent (MUA) . . . . . . . . . . . . . . . . . . 20 75 4.3 Mail Submission Agent (MSA) . . . . . . . . . . . . . . . 22 76 4.4 Mail Transfer Agent (MTA) . . . . . . . . . . . . . . . . 23 77 4.5 Mail Delivery Agent (MDA) . . . . . . . . . . . . . . . . 25 78 4.6 Message Store (MS) . . . . . . . . . . . . . . . . . . . . 26 79 5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 5.1 Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 28 81 5.2 ReSending . . . . . . . . . . . . . . . . . . . . . . . . 30 82 5.3 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 31 83 5.4 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 34 84 5.5 Boundary Filter . . . . . . . . . . . . . . . . . . . . . 35 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 87 7.1 References - Normative . . . . . . . . . . . . . . . . . . 35 88 7.2 Reference - Descriptive . . . . . . . . . . . . . . . . . 38 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 38 90 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 91 Intellectual Property and Copyright Statements . . . . . . . . 39 93 1. Introduction 95 Over its thirty-four year history, Internet Mail has undergone 96 significant changes in scale and complexity, as it has become a 97 global infrastructure service. 99 The first standardized architecture for email specified a simple 100 split between the user world, in the form of Mail User Agents (MUA), 101 and the transmission world, in the form of the Mail Handling Service 102 (MHS) composed of Mail Transfer Agents (MTA). The MHS is responsible 103 for accepting a message from one User and delivering it to one or 104 more others. 106 +--------+ 107 +---------------->| User | 108 | +--------+ 109 | . 110 +--------+ | +--------+ . 111 | User +--+--------->| User | . 112 +--------+ | +--------+ . 113 . | . . 114 . | +--------+ . . 115 . +-->| User | . . 116 . +--------+ . . 117 . . . . 118 . . . . 119 . . . . 120 +--------------------------------------+ 121 | Mail Handling Service (MHS) | 122 +--------------------------------------+ 124 Figure 1: Basic Internet Mail Service Model 126 Today, Internet Mail is marked by many independent operators, many 127 different components for providing users service and many other 128 components for performing message transfer. So it is not surprising 129 that the operational service has sub-divided each of these "layers" 130 into more specialized modules. Core aspects of the service, such as 131 address and message style, have remained remarkably constant. 132 However public discussion of the architecture has not kept pace with 133 the real-world refinements. This document offers an enhanced 134 Internet Mail architecture to reflect the current service. The 135 original distinction between user-level concerns and transfer-level 136 concerns is retained, and the elaboration to each "level" of the 137 architecture is discussed separately. The term "Internet Mail" is 138 used to refer to the entire collection of user and transfer 139 components. 141 For Internet Mail, the term "end-to-end" usually refers to a single 142 posting and the set of deliveries directly resulting from its single 143 transiting of the MHS. However, note that some uses of email 144 consider the entire email service -- including Originator and 145 Recipient -- as a subordinate component. For these services, "end- 146 to-end" refers to points outside of the email service. Examples are 147 voicemail over email [RFC2423], EDI over email [RFC1767], and 148 facsimile over email.[ID-ffpim] 150 The current draft seeks to: 152 o Document refinements to the email model 154 o Clarify functional roles for the architectural components 156 o Clarify identity-related issues, across the email service 158 o Provide a document that serves as a common venue for further 159 defining and citing modern Internet Mail architecture 161 NOTE: 163 Any attempt to provide a retroactive description, for a service 164 that evolved so extensively, is certain to claim definitions and 165 relationships that do not match the equally reasonable views of 166 some portion of the technical community. Ultimately, the 167 "correct" choices are determined solely by the willingness of that 168 community to use the descriptions. 170 1.1 Service Overview 172 End-to-end Internet Mail exchange is accomplished by using a 173 standardized infrastructure comprising: 175 o An email object 177 o Global addressing 179 o An asynchronous sequence of point-to-point transfer mechanisms 181 o No prior arrangement between Originator and Recipient 183 o No prior arrangement between point-to-point transfer services, 184 over the open Internet 186 o No requirement for Originator and Recipient to be online at the 187 same time. 189 The end-to-end portion of the service is the email object, called a 190 message. Broadly the message, itself, is divided between handling 191 control information and user message content. 193 A precept to the design of Internet Mail is permitting user-to-user 194 and MTA-to-MTA interoperability with no prior, direct administrative 195 arrangement. That is, all participants rely on having the core 196 services be universally supported, either directly or through 197 Gateways that translate between Internet Mail standards and other 198 email conventions. 200 For localized environments (Edge networks) prior, administrative 201 arrangement can include access control, routing constraints and 202 lookup service configuration. In recent years one change to local 203 environments is an increased requirement for authentication or, at 204 least, accountability. In these cases, the server performs explicit 205 validation of the client's identity. 207 1.2 Discussion venue 209 Discussion about this document should be directed to the IETF-SMTP 210 mailing list . It is the most active, 211 long-standing venue for discussing email architecture. Although it 212 is primarily for discussing only the SMTP protocol, it is recommended 213 that discussion of this draft take place on that mailing list because 214 it attends to end-to-end infrastructure and architecture issues more 215 than other email-related mailing lists. 217 1.3 Changes 219 This is intended to be the last major revision, prior to seeking 220 publication. 222 Significant changes to this version: 224 Administrative Unit: Changed from Administrative Domain to 225 Administrative Unit, to remove possible confusion with "domain 226 name". Added Tussle reference 228 Sieve: Noted ability to have other places to run sieve 229 instructions. 231 Word Smithing: Assorted small tweaks to definitions, diagrams and 232 comments. 234 Notices, Bounces and Disp: Added Bounce module to Services diagram, 235 to make clear that MHS return messages can go to an independent 236 address. Dotted link to MSA shows responsibility for setting 237 Notices address. Changed "Notification" to "Bounce", to use more 238 popular term and to avoid confusion with MDN notices. Added Disp 239 module to Services, to distinguish DSN traffic from MDN. 241 2. Email Actor Roles 243 Internet Mail is a highly distributed service, with a variety of 244 actors serving different roles. These divide into: 246 o User 248 o Mail Handling Service (MHS) 250 o Administrative Unit 252 Although related to a technical architecture, the focus on Actors 253 concerns participant responsibilities, rather than on functional 254 modules. Hence the labels used are different than for classic email 255 architecture diagrams. Actors often will be associated with 256 different organizations. This operational independence provides the 257 motivation for distinguishing Administrative Units. 259 2.1 User Actors 261 Users are the sources and sinks of messages. They may be humans or 262 processes. They may have an exchange that iterates and they may 263 expand or contract the set of Users participating in a set of 264 exchanges. In Internet Mail there are three types of user-level 265 Actors: 267 o Originators 269 o Recipients 271 o Mediators 273 From the User-level perspective all mail transfer activities are 274 performed by a monolithic Mail Handling Service (MHS), even though 275 the actual service may be provided by many independent organizations. 276 Users are customers of this service. 278 The following depicts the flow of messages among Actors. 280 +------------+ 281 | Originator |<--------------+ 282 +-+---+----+-+ | 283 | | | | 284 | | V | 285 | | +-----------+ | 286 | | | Recipient | | 287 | | +-----------+ | 288 | | | 289 | | +----------+ | 290 | | | | | 291 | V V | | 292 | +-----------+ +---+---+---+ 293 | | Mediator +--->| Recipient | 294 | +-----------+ +-----------+ 295 | 296 V 297 +-----------+ +-----------+ +-----------+ 298 | Mediator +--->| Mediator +--->| Recipient | 299 +-----------+ +-----------+ +-----------+ 301 Figure 2: Relationships Among User Actors 303 2.1.1 Originator 305 Also called "Author", this is the user-level participant responsible 306 for creating original content and requesting its transmission. The 307 MHS operates to send and deliver mail among Originators and 308 Recipients. As described below, the MHS has a "Source" role, that 309 correlates with the Author role. 311 2.1.2 Recipient 313 The Recipient is a consumer of delivered content. As described 314 below, the MHS has a "Dest" role, that correlates with the Recipient 315 role. 317 A Recipient may close the user-level communication loop by creating 318 and submitting a new message that replies to an Originator. An 319 example of an automated form of reply is the Message Disposition 320 Notification, which informs the Originator about the Recipient's 321 disposition of the message. See Section 4.1. 323 2.1.3 Mediator 325 A Mediator receives, aggregates, reformulates and redistributes 326 messages as part of a potentially-protracted, higher-level exchange 327 among Users. Example uses of Mediators include group dialogue and 328 organizational message flow, as occurs with a purchase approval 329 process. Note that it is easy to confuse this user-level activity 330 with the underlying MHS transfer exchanges. However they serve very 331 different purposes and operate is very different ways. Mediators are 332 considered extensively in Section 5. 334 When mail is delivered to an envelope address, a Mediator is viewed 335 by the Mail Handling Service as a Recipient. When submitting 336 messages, the Mediator is an Originator. What is distinctive is that 337 a Mediator preserves the Originator information of the message it 338 reformulates, but may make meaningful changes to the content. Hence 339 the MHS sees a new message, but Users receive a message that is 340 interpreted as primarily being from -- or, at least, initiated by -- 341 the author of the original message. The role of a Mediator permits 342 distinct, active creativity, rather than being limited to the more 343 constrained job of merely connecting together other participants. 344 Hence it is really the Mediator that is responsible for the new 345 message. 347 A Mediator's task may be complex and contingent, such as by modifying 348 and adding content or regulating which users may participate and 349 when. The popular example of this role is a group mailing list. A 350 sequence of mediators may even perform a series of formal steps, such 351 as reviewing, modifying and approving a purchase request. 353 Because a Mediator originates messages, it might also receive 354 replies. So, a Mediator really is a full-fledged User. 356 Gateway: A Gateway is a particularly interesting form of Mediator. 357 It is a hybrid of User and Relay that interconnects heterogeneous 358 mail services. Its goal is to emulate a Relay, so Gateway is 359 described in more detail, in the next section. 361 2.2 MHS Actors 363 The Mail Handling Service (MHS) has the task of performing a single, 364 email-level end-to-end transfer, on behalf of the Originator and 365 reaching the Recipient address(es) specified in the envelope. 366 Mediated or protracted, iterative exchanges, such as those used for 367 collaboration over time, are part of the User-level service, and are 368 not part of this Transfer-level Handling Service. 370 The following depicts the relationships among transfer participants 371 in Internet Mail. It shows the Source as distinct from the 372 Originator, and Destination as distinct from Recipient, although it 373 is common for each pair to be the same actor. The figure also shows 374 multiple Relays in the sequence. It is legal to have no separate 375 Relay, where the Source and Dest interact directly. For intra- 376 organization mail services, it is common to have only one Relay. 378 +------------+ +-----------+ 379 | Originator | | Recipient | 380 +-----+------+ +-----------+ 381 | ^ 382 | Mail Handling Service | 383 /+=================================================+\ 384 || | | || 385 || | | || 386 V | 387 +---------+ +--------+ +----+----+ 388 | | | |<------------+ | 389 | Source +...>| Bounce | | Dest | 390 | | | |<---+ | | 391 +----+----+ +--------+ | +---------+ 392 | | ^ 393 V | | 394 +---------+ +----+----+ +----+----+ 395 | Relay +-->.......-->| Relay +-->| Relay | 396 +---------+ +----+----+ +---------+ 397 | 398 V 399 +---------+ 400 | Gateway +-->... 401 +---------+ 403 Figure 3: Relationships Among MHS Actors 405 2.2.1 Source 407 The Source role is responsible for ensuring that a message is valid 408 for posting and then submitting it to a Relay. Validity includes 409 conformance with Internet Mail standards, as well as with local 410 operational policies. The source may simply review the message for 411 conformance, and reject it if there are errors, or it may create some 412 or all of the necessary information. 414 The Source operates with dual "allegiance". It serves the Originator 415 and often it is the same entity. However its role in assuring 416 validity means that it must also represent the local operator of the 417 MHS, that is, the local Administrative Domain. 419 The Source also has the responsibility for any post-submission, 420 Originator-related administrative tasks associated with message 421 transmission and delivery. Notably this pertains to error and 422 delivery notices. Hence, Source is best held accountable for the 423 message content, even when they did not create any or most of it. 425 2.2.2 Bounce Handler 427 The Bounce Handler processes service notifications that are generated 428 by the MHS, as a result of its efforts to transfer or deliver the 429 message. Notices may be about failures or completions and are sent 430 to an address that is specified by the Source. This Bounce handling 431 address (also known as a Return address) might have no visible 432 characteristics in common with the address of the Originator or 433 Source. 435 2.2.3 Relay 437 A mail Relay performs email transfer-service routing and store-and- 438 forward. It adds envelope-level handling information and then 439 (re-)transmits the message on towards its Recipient(s). A Relay may 440 add information to the envelope, such as with trace information. 441 However it does not modify existing envelope information or the 442 message content semantics. It may modify message content syntax, 443 such as a change from text to binary transfer-encoding form, only as 444 required to meet the capabilities of the next hop in the MHS. 446 A set of Relays composes a Mail Handling Service network. This is 447 above any underlying packet-switching network that they might be 448 using and below any gateways or other user-level Mediators. 450 In other words, interesting email scenarios can involve three, 451 distinct architectural layers of store-and-forward service: 453 o User Mediators 455 o MHS Relays 457 o Packet Switches 459 with the bottom-most usually being the Internet's IP service. The 460 most basic email scenarios involve Relays and Switches. 462 Aborting a message transfer results in having the Relay become an 463 Originator and send an error message to the Bounce (Bounce) address. 464 (The potential for looping is avoided by having this message, itself, 465 contain no Bounce address.) 467 2.2.4 Gateway 469 A Gateway is a hybrid form of User and Relay that interconnects 470 heterogeneous mail services. Its purpose is simply to emulate a 471 Relay and the closer it comes to this, the better. However it 472 operates at the User level, because it must be able to modify message 473 content. 475 Differences between mail services can be as small as minor syntax 476 variations, but usually encompass significant, semantic distinctions. 477 For example, the concept of an email address might be as different as 478 a hierarchical, machine-specific address versus a flat, global name 479 space. Or between text-only content and multi-media. Hence the 480 Relay function in a Gateway offers the minor challenge in design. 481 The more significant challenge is in ensuring the user-to-user 482 functionality that matches syntax and semantics of independent email 483 standards suites. 485 The basic test of a Gateway's adequacy is, of course, whether an 486 Originator on one side of a Gateway can send a message to a Recipient 487 on the other side, without requiring changes to any of the components 488 in the Originator's or Recipient's mail services, other than adding 489 the Gateway. To each of these otherwise independent services, the 490 Gateway will appear to be a "native" participant. However the 491 ultimate test of a Gateway's adequacy is whether the Originator and 492 Recipient can sustain a dialogue. In particular, can a Recipient's 493 MUA automatically formulate a valid Reply? 495 2.3 Administrative Actors 497 Operation of Internet Mail services is apportioned to different 498 providers (or operators). Each can be composed of an independent 499 Administrative Unit (AU). Examples include an end-user operating 500 their desktop client, a department operating a local Relay, an IT 501 department operating an enterprise Relay, and an ISP operating a 502 public, shared email service. These can be configured into many 503 combinations of administrative and operational relationships, with 504 each Administrative Unit potentially having a complex arrangement of 505 functional components. Figure 4 depicts the relationships among AUs. 506 Perhaps the most salient aspect of an AU is the differential trust 507 that determines its policies for activities within the AU, versus 508 those involving interactions with other AUs. The architectural 509 impact of needing to have boundaries between AU's is discussed in 510 [Tussle] 512 Basic components of AU distinction include: 514 Edge: Independent transfer services, in networks at the edge of the 515 Internet Mail service. 517 User: End-user services. This might be subsumed under the Edge 518 service, such as is common for web-based email access. 520 Transit: These are Mail Service Providers (MSP) offering value- 521 added capabilities for Edge AUs, such as aggregation and 522 filtering. 524 Note that Transit services are quite different from packet-level 525 transit operation. Whereas end-to-end packet transfers usually go 526 through intermediate routers, email exchange across the open Internet 527 is often directly between the Edge AUs, at the email level. 529 +------ +------+ +------+ 530 | AU-1 | | AU-3 | | AU-4 | 531 | ---- | | ---- | | ---- | 532 | | +---------------------->| | | | 533 | User | | |-Edge-+---->|-User | 534 | | | | +--->| | | | 535 | V | | | +------+ +------+ 536 | Edge-+----+ | 537 | | | +---------+ | 538 +------+ | | AU-2 | | 539 | | ------- | | 540 | | | | 541 +--->|-Transit-+---+ 542 | | 543 +---------+ 545 Figure 4: Administrative Units (AU) Example 547 Edge networks may use proprietary email standards internally. 548 However the distinction between Transit network and Edge network 549 transfer services is primarily significant because it highlights the 550 need for concern over interaction and protection between independent 551 administrations. In particular, this distinctions calls for 552 additional care in assessing transitions of responsibility, as well 553 as the accountability and authorization relationships among 554 participants in email transfer. 556 The interactions between functional components within an 557 Administrative Unit are subject to the policies of that domain. 558 Policies can cover such things as reliability, access control, 559 accountability and even content evaluation and modification. They 560 may be implemented in different functional components, according to 561 the needs of the Administrative Unit. For example, see [ID-spamops]. 563 User, Edge and Transit services can be offered by providers that 564 operate component services or sets of services. Further, it is 565 possible for one AU to host services for other AUs. Common AU 566 examples are: 568 Enterprise Service Providers: 570 Operating an organization's internal data and/or mail services. 572 Internet Service Providers: 574 Operating underlying data communication services that, in turn, 575 are used by one or more Relays and Users. It is not their job to 576 perform email functions, but to provide an environment in which 577 those functions can be performed. 579 Mail Service Providers: 581 Operating email services, such as for end-users, or mailing lists. 583 Operational pragmatics often dictate that providers be involved in 584 detailed administration and enforcement issues, to help ensure the 585 health of the overall Internet Mail Service. This can include 586 operators of lower-level packet services. 588 3. Identities 590 Internet Mail uses three forms of identity. The most common is the 591 mailbox address [RFC2822] Also see
and 592 in [RFC2821]. The other two are the domain name 593 Section 3.2 and message identifier [RFC2822]. 595 3.1 Mailbox Addresses 597 "A mailbox sends and receives mail. It is a conceptual entity 598 which does not necessarily pertain to file storage." [RFC2822] 600 A mailbox is specified as an Internet Mail address . It 601 has two distinct parts, divided by an at-sign ("@"). The right-hand 602 side contains a globally interpreted name for an Administrative Unit. 603 Domain Names are discussed in Section 3.2. 605 The portion to the left of the at-sign contains a string that is 606 globally opaque and is called the . It is to be 607 interpreted only by the entity specified in the address's right-hand 608 side. All other entities must treat the local-part as a 609 uninterpreted, literal string and must preserve all of its original 610 details. As such, its public distribution is equivalent to sending a 611 "cookie" that is only interpreted upon being returned to its 612 originator. 614 3.1.1 Global Standards for Local-Part 616 It is common for sites to have local structuring conventions for the 617 left-hand side (local-part) of an addr-spec. This permits sub- 618 addressing, such as for distinguishing different discussion groups by 619 the same participant. However it must be stressed that these 620 conventions are strictly private to the user's organization and must 621 not be interpreted by any domain except the one listed in the right- 622 hand side of the addr-spec. 624 A small class of addresses has an elaboration on basic email 625 addressing, with a standardized, global schema for the local-part. 626 These are conventions between originating end-systems and Recipient 627 Gateways, and they are invisible to the public email transfer 628 infrastructure. When an Originator is explicitly sending via a 629 Gateway out of the Internet, there are coding conventions for the 630 local-part, so that the Originator can formulate instructions for the 631 Gateway. Standardized examples of this are the telephone numbering 632 formats for VPIM [RFC2421], such as "+16137637582@vpim.example.com", 633 and iFax [RFC2304], such as 634 "FAX=+12027653000/T33S=1387@ifax.example.com". 636 3.1.2 Scope of Email Address Use 638 Email addresses are being used far beyond their original email 639 transfer and delivery role. In practical terms, email strings have 640 become a common form of user identity on the Internet. What is 641 essential, then, is to be clear about the nature and role of an 642 identity string in a particular context and to be clear about the 643 entity responsible for setting that string. 645 3.2 Domain Names 647 A domain name is a global reference to an Internet resource, such as 648 a host, a service or a network. A name usually maps to one or more 649 IP Addresses. Conceptually, the name might encompass an entire 650 organization, or a collection of machines integrated into a 651 homogeneous service, or only a single machine. A domain name can be 652 administered to refer to individual users, but this is not common 653 practice. The name is structured as a hierarchical sequence of sub- 654 names, separated by dots ("."). Domain names are defined and 655 operated through the Domain Name Service (DNS) [RFC1034], [RFC1035], 656 [RFC2181]. 658 When not part of a mailbox address, a domain name is used in Internet 659 Mail to refer to a node that took action upon the message, such as 660 providing the administrative scope for a message identifier, or 661 performing transfer processing. 663 3.3 Message Identifiers 665 Like mailbox addresses, message identifiers have two distinct parts, 666 divided by an at-sign ("@"). The right-hand side is globally 667 interpreted and specifies the Administrative Unit assigning the 668 identifier. The left-hand side of the at-sign contains a string that 669 is globally opaque and serves to uniquely identify the message within 670 the domain referenced on the right-hand side. The duration of 671 uniqueness for the message identifier is undefined. 673 The identifier may be assigned by the user or by any component of the 674 system along the path, within the AU responsible for the indicated 675 domain. Although Internet Mail standards provide for a single 676 identifier, more than one is sometimes assigned. 678 3.4 Identity Referencing Convention 680 In this document, fields references to identities are labeled in a 681 two-part, dotted notation. The first part cites the document 682 defining the identity and the second defines the name of the 683 identity. Hence, is the From field in an email 684 content header, and is the address in the SMTP 685 "Mail From" command. 687 4. Services 689 The Internet's MHS architecture distinguishes six types of functional 690 components, arranged to support a store-and-forward service 691 architecture: 693 o Message 695 o Mail User Agent (MUA) 697 o Message Submission Agent (MSA) 699 o Message Transfer Agent (MTA) 701 o Message Delivery Agent (MDA) 703 o Message Store (MS) 705 This section describes the specific functional components for 706 Internet Mail, and the standard protocols associated with performing 707 them. 709 Software implementations of these architectural components often 710 compress them, such as having the same software do MSA, MTA and MDA 711 functions. However the requirements for each of these components of 712 the service are becoming more extensive. So, their separation is 713 increasingly common. 715 NOTE: 717 A discussion about any interesting system architecture is often 718 complicated by confusion between architecture versus 719 implementation. An architecture defines the conceptual functions 720 of a service, divided into discrete conceptual modules. An 721 implementation of that architecture may combine or separate 722 architectural components, as needed for a particular operational 723 environment. It is important not to confuse the engineering 724 decisions that are made to implement a product, with the 725 architectural abstractions used to define conceptual functions. 727 This figure shows function modules and the protocols used between 728 them. Additional protocols and configurations are possible. 730 +------+ +---------+ 731 ...............+ oMUA |...| Disp |<----------------+ 732 . +--+---+ +---------+ | 733 . | {smtp, | 734 . V {submission | 735 . +------+ +---------+ | 736 . | MSA |...| Bounces |< -----+ | 737 . +--+---+ +---------+ | | 738 . | | | 739 . V {smtp | | 740 . +------+ /+===+===+\ | 741 . | MTA | || dsn || | 742 /+==========+\ +--+---+ \+=======+/ | 743 || MESSAGE || . ^ ^ | 744 ||----------|| . {smtp | | | 745 || Envelope || . | | | 746 || SMTP || V | | | 747 || RFC2822 || +------+ | | /+==+==+\ 748 || Content || | MTA +-------------------+ | || mdn || 749 || RFC2822 || +--+---+ | \+=====+/ 750 || MIME || | {local, smtp, | | 751 \+==========+/ V {lmtp | | 752 . +------+ | | 753 . | +-----------------------+ | 754 . | MDA | | 755 . | |<--------------------+ | 756 . +-+--+-+ | | 757 . local} | | | | 758 . V | | | 759 . +------+ | /+===+===+\ | 760 . | sMS | | || sieve || | 761 . +-+--+-+ | \+=======+/ | 762 . | | | {pop, imap ^ | 763 . | V V | | 764 . | +------+ | | 765 . | | uMS | | | 766 . | +--+---+ | | 767 . | | {pop, imap, | | 768 . V V {local | | 769 . +------+ | | 770 . | +---- -------------------+ | 771 ...........>| rMUA | | 772 | +----------------------------------+ 773 +------+ 775 Figure 5: Protocols and Services 777 4.1 Message 779 The purpose of the Mail Handling Service is to exchange a message 780 object among participants. Hence, all of the underlying mechanisms 781 are merely in the service of getting that message from its Originator 782 to its Recipients. A message may be explicitly labeled as to its 783 nature. [RFC3458] 785 A message comprises a transit handling envelope and the end-user 786 message content. The envelope contains handling information used by 787 the Message Handling Service, or generated by it. The content is 788 divided into a structured header and the body. The body may be 789 unstructured, simple text, or it may be a tree of multi-media 790 subordinate objects, called body-parts. 792 Internet Mail has distinguished some special versions of messages, 793 for exchanging control information: 795 Delivery Status Notification (DSN): 797 A Delivery Status Notification (DSN) may be generated by the Mail 798 Handling Service (MSA, MTA or MDA) and sent to the 799 RFC2821.MailFrom address. It provides information about message 800 transit, such as transmission errors or successful delivery. 801 [RFC3461] 803 Message Disposition Notification (MDN): 805 A Message Disposition Notification (MDN) may be generated by an 806 rMUA and is sent to the Disposition-Notification-To address(es). 807 It provides information about user-level, Recipient-side message 808 processing, such as indicating that the message has been read 809 [RFC2298] or the form of content that can be supported. [RFC3297] 811 Message Filtering (SIEVE): 813 SIEVE provides a means of specifying conditions for differential 814 handling of mail, at the time of delivery [RFC3028]. Figure 5 815 shows a Sieve specification going from the rMUA to the MDA. 816 However filtering can be done at many different points along the 817 transit path and any one or more of them might be subject to Sieve 818 directives, especially within a single AU. Hence, the Figure 819 shows only one relationship, for simplicity. 821 4.1.1 Envelope 823 Information that is directly used by, or produced by, the MHS is 824 called the "envelope". It controls and records handling activities 825 by the transfer service. Internet Mail has a fragmented framework 826 for handling this "handling" information. The envelope exists partly 827 in the transfer protocol SMTP [RFC2821] and partly in the message 828 object [RFC2822]. The SMTP specification uses the term to refer only 829 to the transfer-protocol information. 831 NOTE: 833 Due to the frequent use of the term "envelope" to refer only to 834 SMTP constructs, there has been some call for using a different 835 term, to label the larger set of information defined here. So 836 far, no alternative term has developed any community support. 838 Direct envelope addressing information, as well as optional transfer 839 directives, are carried within the SMTP control channel. Other 840 envelope information, such as trace records, is carried within the 841 content header fields. Upon delivery, some SMTP-level envelope 842 information is typically encoded within additional content header 843 fields, such as Return-Path. 845 4.1.2 Message Header Fields 847 Header fields are attribute/value pairs covering an extensible range 848 of email service, user content and user transaction meta-information. 849 The core set of header fields is defined in [RFC2822], [RFC0822]. It 850 is common to extend this set, for different applications. Procedures 851 for registering headers are provided in [RFC4021]. A complete set of 852 registered header fields is being developed through [ID-hdr-reg]. 854 One danger with placing additional information in header fields is 855 that Gateways often alter or delete them. 857 4.1.3 Body 859 The body of a message might simply be lines of ASCII text or it might 860 be structured into a composition of multi-media, body-part 861 attachments, using MIME [RFC2045], [RFC2046], [RFC2047], [RFC2048], 862 and [RFC2049]. MIME structures each body-part into a recursive set 863 of MIME header field meta-data and MIME Content sections. 865 4.1.4 Identity References in a Message 867 For a message in transit, the core uses of identity references 868 combine into: 870 +-----------------------+-------------+---------------------+ 871 | Layer | Field | Set By | 872 +-----------------------+-------------+---------------------+ 873 | Message Body | MIME Header | Originator | 874 | Message header fields | From | Originator | 875 | | Sender | Source | 876 | | Reply-To | Originator | 877 | | To, CC, BCC | Originator | 878 | | Message-ID | Source | 879 | | Received | Source, Relay, Dest | 880 | | Return-Path | MDA, from MailFrom | 881 | | Resent-* | Mediator | 882 | SMTP | HELO | Latest Relay Client | 883 | | MailFrom | Source | 884 | | RcptTo | Originator | 885 | IP | IP Address | Latest Relay Client | 886 +-----------------------+-------------+---------------------+ 888 4.2 Mail User Agent (MUA) 890 A Mail User Agent (MUA) works on behalf of end-users and end-user 891 applications. It is their "representative" within the email service. 893 At the origination side of the service, the oMUA is used to create a 894 message and perform initial "submission" into the transfer 895 infrastructure, via a Mail Submission Agent (MSA). It may also 896 perform any creation- and posting-time archival. An MUA outbox is 897 part of the origination-side MUA. 899 The Recipient-side rMUA works on behalf of the end-user Recipient to 900 process received mail. This includes generating user-level return 901 control messages, display and disposition of the received message, 902 and closing or expanding the user communication loop, by initiating 903 replies and forwarding new messages. 905 An MUA may, itself, have a distributed implementation, such as a 906 "thin" user interface module on a limited end-user device, with the 907 bulk of the MUA functionality operated remotely on a more capable 908 server. An example of such an architecture might use IMAP [RFC3501] 909 for most of the interactions between an MUA client and an MUA server. 911 A Mediator is special class of MUA. It performs message re-posting, 912 as discussed in Section 2.1. 914 Identity fields relevant to the MUA include: 916 RFC2822.From 918 Set by: Originator 920 Names and addresses for author(s) of the message content are 921 listed in the From field 923 RFC2822.Reply-To 925 Set by: Originator 927 If a message Recipient sends a reply message that would otherwise 928 use the RFC2822.From field address(es) contained in the original 929 message, then they are instead to use the address(es) in the 930 RFC2822.Reply-To field. In other words, this field is a direct 931 override of the From field, for responses from Recipients. 933 RFC2822.Sender 935 Set by: Source 937 This specifies the address responsible for submitting the message 938 into the transfer service. For efficiency, this field should be 939 omitted if it contains the same address as RFC2822.From. However 940 this does not mean there is no Sender specified. Rather, it means 941 that that header field is virtual and that the address in the From 942 field must be used. Specification of the error return addresses 943 -- the "Bounce" address, contained in RFC2821.MailFrom -- is made 944 by the RFC2822.Sender. Typically the Bounce address is the same 945 as the Sender address. However some usage scenarios require it to 946 be different. 948 RFC2822.To, RFC2822.CC 950 Set by: Originator 952 These specify MUA Recipient addresses. The addresses in the 953 fields might not be present in the RFC2821.RcptTo command. The 954 distinction between To and CC is subjective. Generally, a To 955 addressee is considered primary and is expected to take action on 956 the message. A CC addressee typically receives a copy only for 957 their information. 959 RFC2822.BCC 960 Set by: Originator 962 A message might be copied to an addressee whose participation is 963 not to be disclosed to the RFC2822.To or RFC2822.CC Recipients 964 and, usually, not to the other BCC Recipients. The BCC header 965 field indicates a message copy to such a Recipient. Typically, 966 the field lists no addresses or only lists the address of the 967 Recipient receiving this copy. An MUA will typically make 968 separate postings for TO and CC Recipients, versus BCC Recipients. 969 The former will see no indication that any BCCs were sent, whereas 970 the latter have a BCC field present. It might be empty, contain a 971 comment, or contain one or more BCC addresses, depending upon the 972 preferences or the Originator. 974 4.3 Mail Submission Agent (MSA) 976 A Mail Submission Agent (MSA) accepts the message submission from the 977 oMUA and enforces the policies of the hosting AU and the requirements 978 of Internet standards. Enforcement might be passive, involving 979 review and approval or rejection, or it might be active, involving 980 direct modification of the message. An MSA implements a server 981 function to MUAs and a client function to MTAs (or MDAs). 983 Examples of MSA-styled functions, in the world of paper mail, might 984 range across the very different capabilities of administrative 985 assistants, postal drop boxes, and post office front-counter 986 employees. 988 The MUA/MSA interface can be implemented within a single host and use 989 private conventions for its interactions. Historically, standards- 990 based MUA/MSA interactions have used SMTP [RFC2821]. However a 991 recent alternative is SUBMISSION [RFC2476]. Although SUBMISSION 992 derives from SMTP, it operates on a separate TCP port, and will 993 typically impose distinct requirements, such as access authorization. 995 Identities relevant to the MSA include: 997 RFC2821.HELO or RFC2821.EHLO 999 Set by: Source 1001 The MSA may specify its hosting domain identity for the SMTP HELO 1002 or EHLO command operation. 1004 RFC2821.MailFrom 1006 Set by: Source 1008 This is an end-to-end string that specifies an email address for 1009 receiving return control information, such as "bounces". The name 1010 of this field is misleading, because it is not required to specify 1011 either the author or the agent responsible for submitting the 1012 message. Rather, the agent responsible for submission specifies 1013 the RFC2821.MailFrom address. Ultimately the simple basis for 1014 deciding what address needs to be in the RFC2821.MailFrom is to 1015 determine what address needs to be informed about transmission- 1016 level problems (and, possibly, successes.) 1018 RFC2821.RcptTo 1020 Set by: Originator 1022 This specifies the MUA mailbox address of a recipient. The string 1023 might not be visible in the message content header. For example, 1024 the message destination address header fields, such as RFC2822.To, 1025 might specify a mailing list address, while the RFC2821.RcptTo 1026 address specifies a member of that list. 1028 RFC2821.Received 1030 Set by: Source 1032 An MSA may record a Received header field, to indicate initial 1033 submission trace information, including originating host and MSA 1034 host domain names and/or IP Addresses. 1036 4.4 Mail Transfer Agent (MTA) 1038 A Mail Transfer Agent (MTA) relays mail for one, application-level 1039 "hop". It is like a packet-switch or IP router in that its job is to 1040 make routing assessments and to move the message closer to the 1041 Recipient(s). Relaying is performed by a sequence of MTAs, until the 1042 message reaches its destination MDA(s). Hence an MTA implements both 1043 client and server MTA functionality. It does not make changes to 1044 addresses in the envelope or reformulate the content, except as 1045 transfer-encoding requirements dictate. Also it may add trace 1046 information. Of course email objects are typically much larger than 1047 the payload of a packet or datagram, and the end-to-end latencies are 1048 typically much higher. 1050 Internet Mail primarily uses SMTP [RFC2821], [RFC0821] to effect 1051 point-to-point transfers between peer MTAs. Other transfer 1052 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]. As with 1053 most network layer mechanisms Internet Mail's SMTP supports a basic 1054 level of reliability, by virtue of providing for retransmission after 1055 a temporary transfer failure. Contrary to typical packet switches 1056 (and Instant Messaging services) Internet Mail MTAs typically store 1057 messages in a manner that allows recovery across service 1058 interruptions, such as host system shutdown. However the degree of 1059 such robustness and persistence by an MTA can be highly variable. 1061 The primary "routing" mechanism for Internet Mail is the DNS MX 1062 record [RFC1035], which specifies a host, through which the queried 1063 domain can be reached. This presumes a public -- or at least a 1064 common -- backbone that permits any attached host to connect to any 1065 other. 1067 An important characteristic of MTA-MTA communications, over the open 1068 Internet, is that they do not require prior arrangement between the 1069 independent administrations operating the different MTAs. Given the 1070 importance of spontaneity and serendipity in the world of human 1071 communications, this lack of prearrangement, between the 1072 participants, is a core benefit of Internet Mail and remains a core 1073 requirement for it. 1075 Identities relevant to the MTA include: 1077 RFC2821.HELO 1079 Set by: Relay 1081 The MTA may specify its hosting domain identity for the SMTP HELO 1082 or EHLO command. This is the only standardized way of identifying 1083 the agent responsible for operation of the Relay, during the 1084 transfer operation. 1086 RFC2821.MailFrom 1088 Set by: Source 1090 This is an MHS end-to-end string that specifies an email address 1091 for receiving return control Bounce, such as delivery 1092 confirmations and error notices. The protocol name of this field 1093 is misleading, because it is not required to specify either the 1094 author or the agent responsible for submitting the message. 1095 Rather, the agent responsible for submission specifies the 1096 MailFrom address. Ultimately the simple basis for deciding what 1097 address needs to be in the RFC2821.MailFrom is to determine what 1098 address needs to be informed about transmission-level problems 1099 (and, possibly, successes.) 1101 RFC2821.RcptTo 1103 Set by: Originator 1105 This specifies the MUA mailbox address of a Recipient. The string 1106 might not be visible in the message content header. For example, 1107 the message destination address header fields, such as RFC2822.To, 1108 might specify a mailing list address, while the RFC2821.RcptTo 1109 address specifies a member of that list. 1111 RFC2822.Received 1113 Set by: Relay 1115 An MTA must record a Received header field, to indicate trace 1116 information, including source host and receiving host domain names 1117 and/or IP Addresses. 1119 4.5 Mail Delivery Agent (MDA) 1121 A Mail Delivery Agent (MDA) delivers email to the Recipient's 1122 mailbox. It can provide distinctive, address-based functionality, 1123 made possible by its detailed knowledge of the properties of the 1124 destination address. This knowledge might also be present elsewhere 1125 in the Recipient's Administrative Unit, such as at an organizational 1126 border Relay. However it is required for the MDA, if only because 1127 the MDA must know where to deliver the message. 1129 Using Internet protocols, delivery can be effected by a variety of 1130 standard protocols. When coupled with an internal, local mechanism, 1131 SMTP [RFC2821] and LMTP [RFC2033] permit "push" delivery to the 1132 Recipient system, at the initiative of the upstream email service. 1133 POP [RFC1939] and IMAP [RFC3501] are used for "pull" delivery at the 1134 initiative of the Recipient system. POP and IMAP can also be used 1135 for repeated access to messages on a remote MS. 1137 Identities relevant to the MDA include: 1139 RFC2821.Return-Path 1141 Set by: Source 1142 The MDA records the RFC2821.MailFrom address into the 1143 RFC2822.Return-Path field. 1145 RFC2822.Received 1147 Set by: Destination 1149 An MDA must record a Received header field, to indicate trace 1150 information, including source host and receiving host domain names 1151 and/or IP Addresses. 1153 4.6 Message Store (MS) 1155 An MUA can use a long-term Message Store (MS). A rich set of choices 1156 for the use of that store derives from permitting more than one to be 1157 associated with a single user, demonstrated as a server-based MS 1158 (sMS) and user-based MS (uMS) in Figure 5. sMS is shown as being 1159 remote from the MUA and uMS as being local. Further the relationship 1160 between two message store may vary. Between the MDA and the MUA, 1161 these choices are supported by a wide variety of protocol options. 1163 The operational relationship among two MSs can be: 1165 Online: 1167 Only a remote MS is used, with messages being accessible only when 1168 the MUA is attached to the MS, and the MUA repeatedly fetches all 1169 or part of a message, from one session to the next. 1171 Offline: 1173 The MS is local to the user, and messages are moved from any 1174 remote store, rather than (also) being retained there. 1176 Disconnected: 1178 A remote MS and a local MS synchronize all or parts of their 1179 contents, while connected. The user may make changes while 1180 disconnected, and the two stores are re-synchronized upon 1181 reconnection. 1183 5. Mediators 1185 Basic email transfer is accomplished with an asynchronous store-and- 1186 forward communication infrastructure, in a sequence of independent 1187 transmissions through some number of MTAs. A very different task is 1188 a User-level sequence of postings and deliveries, through Mediators. 1189 For such re-postings, a Mediator does share some functionality with 1190 basic MTA relaying, but it enjoys a degree of freedom with both 1191 addressing and content that is not available to MTAs. 1193 RFC2821.HELO or RFC2821.EHLO 1195 Set by: Source or Relay 1197 The MSA may specify its hosting domain identity for the SMTP HELO 1198 or EHLO command operation. 1200 RFC2821.MailFrom 1202 Set by: Source 1204 This is an end-to-end string that specifies an email address for 1205 receiving return control Bounces. The name of this field is 1206 misleading, because it is not required to specify either the 1207 author or the agent responsible for submitting the message. 1208 Rather, the agent responsible for submission specifies the 1209 RFC2821.MailFrom address. Ultimately the simple basis for 1210 deciding what address needs to be in the RFC2821.MailFrom is to 1211 determine what address needs to be informed about transmission- 1212 level problems (and, possibly, successes.) 1214 RFC2821.RcptTo 1216 Set by: Mediator 1218 This specifies the MUA mailbox address of a Recipient. The string 1219 might not be visible in the message content header. For example, 1220 the message destination address header fields, such as RFC2822.To, 1221 might specify a mailing list address, while the RFC2821.RcptTo 1222 address specifies a member of that list. 1224 RFC2821.Received 1226 Set by: Mediator 1228 An MSA may record a Received header field, to indicate initial 1229 submission trace information, including originating host and MSA 1230 host domain names and/or IP Addresses. 1232 The salient aspect of a Mediator, that distinguishes it from any 1233 other MUA creating an entirely new message, is that a Mediator 1234 preserves the integrity and tone of the original message, including 1235 the essential aspects of the original origination information. The 1236 Mediator might also add commentary. 1238 Examples of MUA message creation that are NOT performed by Mediators 1239 include: 1241 New message forwarding existing message: 1243 This action rather curiously provides a basic template for a class 1244 of Mediators. However for it's typical occurrence it is not 1245 itself an example of a Mediator. The new message is viewed as 1246 being from the Agent doing the forwarding, rather than being from 1247 the original Originator. 1249 A new message encapsulates the original message and is seen as 1250 strictly "from" the Mediator. The Mediator might add commentary 1251 and certainly has the opportunity to modify the original message 1252 content. The forwarded message is therefore independent of the 1253 original message exchange and creates a new message dialogue. 1254 However the final Recipient sees the contained message as from the 1255 original Originator. 1257 Reply: 1259 When a Recipient formulates a response to a message, the new 1260 message is not typically viewed as being a "forwarding" of the 1261 original. It's focus is the new content; any inclusion of 1262 material from the original message is contextual and secondary. 1264 Annotator: 1266 The integrity of the original message is usually preserved, but 1267 one or more comments about the message are added in a manner that 1268 distinguishes commentary from original text. The tone of the new 1269 message is that it is primarily commentary from a new Originator, 1270 similar to a Reply. 1272 The remainder of this section describes common examples of Mediators. 1274 5.1 Aliasing 1276 A simple re-addressing facility that is available in most MDA 1277 implementations is called Aliasing. It is performed just before 1278 delivering a message to the specified Recipient's mailbox. Instead, 1279 the message is submitted back to the transfer service, for delivery 1280 to one or more alternate addresses. Although implemented as part of 1281 the message delivery service, this facility is strictly a Recipient 1282 user function. It resubmits the message, replacing the envelope 1283 address, on behalf of the mailbox address that was listed in the 1284 envelope. 1286 What is most distinctive about this forwarding mechanism is how 1287 closely it compares to normal MTA store-and-forward Relaying. In 1288 reality its only interesting difference is that it changes the 1289 RFC2821.RcptTo value. Having the change be this small makes it easy 1290 to view aliasing as a part of the lower-level mail relaying activity. 1291 However the small change has a large semantic impact: The designated 1292 recipient has chosen a new recipient. Hence, that original recipient 1293 must become responsible for any handling issues. 1295 An MDA that is re-posting a message to an alias typically changes 1296 only envelope information: 1298 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1300 Set by: Originator 1302 These retain their original addresses. 1304 RFC2821.RcptTo 1306 Set by: Mediator 1308 This field contains an alias address. 1310 RFC2821.MailFrom 1312 Set by: Mediator or original Source 1314 The agent responsible for submission to an alias address will 1315 often retain the original address to receive handling Bounces. 1316 The benefit of retaining the original MailFrom value is to ensure 1317 that the origination-side agent knows that there has been a 1318 delivery problem. On the other hand, the responsibility for the 1319 problem usually lies with the Recipient, since the Alias mechanism 1320 is strictly under the Recipient's control. 1322 RFC2821.Received 1324 Set by: Mediator 1326 The agent should record Received information, to indicate the 1327 delivery to the original address and submission to the alias 1328 address. The trace of Received header fields should therefore 1329 include everything from original posting through final delivery to 1330 the alias. 1332 5.2 ReSending 1334 Also called ReDirecting, ReSending differs from Forwarding by virtue 1335 of having the Mediator "splice" a message's addressing information, 1336 to connect the Originator of the original message and the Recipient 1337 of the new message. This permits them to have direct exchange, using 1338 their normal MUA Reply functions. Hence the new Recipient sees the 1339 message as being From the original Originator, even if the Mediator 1340 adds commentary. 1342 Identities specified in a resent message include 1344 RFC2822.From 1346 Set by: original Originator 1348 Names and email addresses for the original author(s) of the 1349 message content are retained. The free-form (display-name) 1350 portion of the address might be modified to provide informal 1351 reference to the agent responsible for the redirection. 1353 RFC2822.Reply-To 1355 Set by: original Originator 1357 If this field is present in the original message, it is retained 1358 in the Resent message. 1360 RFC2822.Sender 1362 Set by: original Source 1364 This field is expected to contain the original Sender value. 1366 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1368 Set by: original Originator 1370 These specify the original message Recipients. 1372 RFC2822.Resent-From 1374 Set by: Mediator 1376 The address of the original Recipient who is redirecting the 1377 message. Otherwise, the same rules apply for the Resent-From 1378 field as for an original RFC2822.From field 1380 RFC2822.Resent-Sender 1382 Set by: Mediator 1384 The address of the agent responsible for re-submitting the 1385 message. For efficiency this field is often omitted if it 1386 contains the same address as RFC2822.Resent-From. However this 1387 does not mean there is no Resend-Sender specified. Rather, it 1388 means that that header field is virtual and that the address in 1389 the Resent-From field must be used. Specification of the error 1390 return addresses (the Notification address, contained in 1391 RFC2821.MailFrom) is made by the Resent-Sender. Typically the 1392 Bounce address is the same as the Resent-Sender address. However 1393 some usage scenarios require it to be different. 1395 RFC2822.Resent-To, RFC2822.Resent-cc, RFC2822.Resent-bcc: 1397 Set by: Mediator 1399 The addresses of the new Recipients who will now be able to reply 1400 to the original author. 1402 RFC2821.MailFrom 1404 Set by: Mediator 1406 The agent responsible for re-submission (RFC2822.Resent-Sender) is 1407 also responsible for specifying the new MailFrom address. 1409 RFC2821.RcptTo 1411 Set by: Mediator 1413 This will contain the address of a new Recipient 1415 RFC2822.Received 1417 Set by: Mediator 1419 When resending a message, the submission agent may record a 1420 Received header field, to indicate the transition from original 1421 posting to resubmission. 1423 5.3 Mailing Lists 1425 Mailing lists have explicit email addresses and they forward messages 1426 to a list of subscribed members. The Mailing List Actor performs a 1427 task that can be viewed as an elaboration of the ReDirector role. In 1428 addition to sending the new message to a potentially large number of 1429 new Recipients, the Mediator can modify content, such as deleting 1430 attachments, formatting conversion, and adding list-specific 1431 comments. In addition, archiving list messages is common. Still, 1432 the message retains characteristics of being "from" the original 1433 Originator. 1435 Identities relevant to a mailing list processor, when submitting a 1436 message, include: 1438 RFC2919.List-id 1440 Set by: Mediator 1442 This provides a global mailing list naming framework that is 1443 independent of particular hosts. Although [RFC2919] is a 1444 standards-track specification, it has not gained significant 1445 adoption. 1447 RFC2369.List-* 1449 Set by: Mediator 1451 [RFC2369] defines a collection of message header fields for use by 1452 mailing lists. In effect, they supply list-specific parameters 1453 for common mailing list user operations. The identifiers for 1454 these operations are for the list, itself, and the user-as- 1455 subscriber. 1457 RFC2822.From 1459 Set by: original Originator 1461 Names and email addresses for the original author(s) of the 1462 message content are specified. 1464 RFC2822.Reply-To 1466 Set by: original Originator or Mediator 1468 Mailing lists have introduced an ambiguity for the Reply-To field. 1469 Some List operations choose to force all replies to go to all list 1470 members. They achieve this by placing the list address into the 1471 RFC2822.Reply-To field. Hence, direct, "private" replies only to 1472 the original author cannot be achieved by using the MUA's typical 1473 "reply to author" function. If the author created a Reply-To 1474 field, its information is lost. 1476 RFC2822.Sender 1478 Set by: original Source or Mediator 1480 This will usually specify the address of the agent responsible for 1481 mailing list operations. However, some mailing lists operate in a 1482 manner very similar to a simple MTA Relay, so that they preserve 1483 as much of the original handling information as possible, 1484 including the original RFC2822.Sender field. 1486 RFC2822.TO, RFC2822.CC 1488 Set by: original Originator 1490 These will usually contain the original list of Recipient 1491 addresses. 1493 RFC2821.MailFrom 1495 Set by: original Source or Mediator 1497 This may contain the original address to be notified of 1498 transmission issues, or the mailing list agent may set it to 1499 contain a new Notification address. Typically, the value is set 1500 to a new address, so that mailing list members and posters are not 1501 burdened with transmission-related Bounces. 1503 RFC2821.RcptTo 1505 Set by: Mediator 1507 This contains the address of a mailing list member. 1509 RFC2821.Received 1511 Set by: Mediator 1513 An Mailing List Agent should record a Received header field, to 1514 indicate the transition from original posting to mailing list 1515 forwarding. The Agent may choose to have the message retain the 1516 original set of Received header fields or may choose to remove 1517 them. In the latter case, it should ensure that the original 1518 Received header fields are otherwise available, to ensure later 1519 accountability and diagnostic access to it. 1521 5.4 Gateways 1523 Gateways perform the basic routing and transfer work of message 1524 relaying, but they also make any message or address modifications 1525 that are needed to send the message into the next messaging 1526 environment. When a Gateway connects two differing messaging 1527 services, its role is easy to identify and understand. When it 1528 connects environments that have technical similarity, but may have 1529 significant administrative differences, it is easy to think that a 1530 Gateway is merely an MTA. The critical distinction between an MTA 1531 and a Gateway is that the latter transforms addresses and/or message 1532 content, in order to map between the standards of two, different 1533 messaging services. In virtually all cases, this mapping process 1534 results in some degree of semantic loss. The challenge of Gateway 1535 design is to minimize this loss. 1537 A Gateway may set any identity field available to a regular MUA. 1538 Identities typically relevant to Gateways include: 1540 RFC2822.From 1542 Set by: original Originator 1544 Names and email addresses for the original author(s) of the 1545 message content are retained. As for all original addressing 1546 information in the message, the Gateway may translate addresses in 1547 whatever way will allow them continue to be useful in the target 1548 environment. 1550 RFC2822.Reply-To 1552 Set by: original Originator 1554 The Gateway should retain this information, if it is originally 1555 present. The ability to perform a successful reply by a Gatewayed 1556 Recipient is a typical test of Gateway functionality. 1558 RFC2822.Sender 1560 Set by: original Source or Mediator 1562 This may retain the original value or may be set to a new address 1564 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1565 Set by: original Recipient 1567 These usually retain their original addresses. 1569 RFC2821.MailFrom 1571 Set by: original Source or Mediator 1573 The agent responsible for gatewaying the message may choose to 1574 specify a new address to receive handling notices. 1576 RFC2822.Received 1578 Set by: Mediator 1580 The Gateway may record a Received header field, to indicate the 1581 transition from original posting to the new messaging environment. 1583 5.5 Boundary Filter 1585 Organizations often enforce security boundaries by subjecting 1586 messages to analysis, for conformance with the organization's safety 1587 policies. An example is detection of content classed as spam or a 1588 virus. A Filter might alter the content, to render it safe, such as 1589 by removing content deemed unacceptable. Typically these actions 1590 will result in the addition of content that records the actions. 1592 6. Security Considerations 1594 This document does not specify any new Internet Mail functionality. 1595 Consequently it should introduce no new security considerations. 1597 However its discussion of the roles and responsibilities for 1598 different mail service modules, and the information they create, 1599 highlights the considerable security considerations that must be 1600 present when implementing any component of the Internet Mail service. 1601 In addition, email transfer protocols can operate over authenticated 1602 and/or encrypted links, and message content can be authenticated or 1603 encrypted. 1605 7. References 1607 7.1 References - Normative 1609 [ID-hdr-reg] 1610 "Registration of mail and MIME header fields", 1611 draft-klyne-hdrreg-mail-04.txt (work in progress), 1612 Apr 2004. 1614 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 1615 RFC 821, August 1982. 1617 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1618 text messages", STD 11, RFC 822, August 1982. 1620 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1621 STD 13, RFC 1034, November 1987. 1623 [RFC1035] Mockapetris, P., "Domain names - implementation and 1624 specification", STD 13, RFC 1035, November 1987. 1626 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1627 STD 53, RFC 1939, May 1996. 1629 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1630 October 1996. 1632 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1633 Extensions (MIME) Part One: Format of Internet Message 1634 Bodies", RFC 2045, November 1996. 1636 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1637 Extensions (MIME) Part Two: Media Types", RFC 2046, 1638 November 1996. 1640 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1641 Part Three: Message Header Extensions for Non-ASCII Text", 1642 RFC 2047, November 1996. 1644 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1645 Internet Mail Extensions (MIME) Part Four: Registration 1646 Procedures", BCP 13, RFC 2048, November 1996. 1648 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1649 Extensions (MIME) Part Five: Conformance Criteria and 1650 Examples", RFC 2049, November 1996. 1652 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1653 Specification", RFC 2181, July 1997. 1655 [RFC2298] Fajman, R., "An Extensible Message Format for Message 1656 Disposition Notifications", RFC 2298, March 1998. 1658 [RFC2304] Allocchio, C., "Minimal FAX address format in Internet 1659 Mail", RFC 2304, March 1998. 1661 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1662 for Core Mail List Commands and their Transport through 1663 Message Header Fields", RFC 2369, July 1998. 1665 [RFC2421] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 1666 Mail - version 2", RFC 2421, September 1998. 1668 [RFC2423] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME 1669 Sub-type Registration", RFC 2423, September 1998. 1671 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1673 [RFC2476] Gellens, R. and J. Klensin, "Message Submission", 1674 RFC 2476, December 1998. 1676 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1677 Addresses", RFC 2465, August 1999. 1679 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1680 April 2001. 1682 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1683 April 2001. 1685 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1686 and Namespace for the Identification of Mailing Lists", 1687 RFC 2919, March 2001. 1689 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 1690 RFC 3028, January 2001. 1692 [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content 1693 Negotiation for Messaging Services based on Email", 1694 RFC 3297, July 2002. 1696 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1697 Context for Internet Mail", RFC 3458, January 2003. 1699 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1700 Extension for Delivery Status Notifications (DSNs)", 1701 RFC 3461, January 2003. 1703 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1704 4rev1", RFC 3501, March 2003. 1706 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 1707 Header Fields", RFC 4021, March 2005. 1709 7.2 Reference - Descriptive 1711 [ID-ffpim] 1712 Crocker, D. and G. Klyne, "Full-mode Fax Profile for 1713 Internet Mail: FFPIM", March 2004. 1715 [ID-spamops] 1716 Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and 1717 E. Allman, "Email Submission Between Independent 1718 Networks", draft-spamops-00 (work in progress), 1719 March 2004. 1721 [RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", 1722 RFC 1767, March 1995. 1724 [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 1725 "Tussle in Cyberspace: Defining Tomorrow���s Internet", 1726 ACM SIGCOMM, 2002. 1728 Author's Address 1730 Dave Crocker 1731 Brandenburg InternetWorking 1732 675 Spruce Drive 1733 Sunnyvale, CA 94086 1734 USA 1736 Phone: +1.408.246.8253 1737 Email: dcrocker@bbiw.net 1739 Appendix A. Acknowledgements 1741 This work derives from a section in draft-hutzler-spamops [ID- 1742 spamops]. Discussion of the Source actor role was greatly clarified 1743 during discussions in the IETF's Marid working group. 1745 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1746 insight on the framework and details of the original drafts. 1748 Later reviews and suggestions were provided by Nathaniel Borenstein, 1749 Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, 1750 Eric Hall, Brad Knowles, Bruce Lilly, Mark E. Mallett, David 1751 MacQuigg, Chris Newman, Daryl Odnert, Rahmat M. Samik-Ibrahim, Hector 1752 Santos, Jochen Topf, Willemien Hoogendoorn. 1754 Intellectual Property Statement 1756 The IETF takes no position regarding the validity or scope of any 1757 Intellectual Property Rights or other rights that might be claimed to 1758 pertain to the implementation or use of the technology described in 1759 this document or the extent to which any license under such rights 1760 might or might not be available; nor does it represent that it has 1761 made any independent effort to identify any such rights. Information 1762 on the procedures with respect to rights in RFC documents can be 1763 found in BCP 78 and BCP 79. 1765 Copies of IPR disclosures made to the IETF Secretariat and any 1766 assurances of licenses to be made available, or the result of an 1767 attempt made to obtain a general license or permission for the use of 1768 such proprietary rights by implementers or users of this 1769 specification can be obtained from the IETF on-line IPR repository at 1770 http://www.ietf.org/ipr. 1772 The IETF invites any interested party to bring to its attention any 1773 copyrights, patents or patent applications, or other proprietary 1774 rights that may cover technology that may be required to implement 1775 this standard. Please address the information to the IETF at 1776 ietf-ipr@ietf.org. 1778 Disclaimer of Validity 1780 This document and the information contained herein are provided on an 1781 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1782 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1783 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1784 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1785 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1786 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1788 Copyright Statement 1790 Copyright (C) The Internet Society (2005). This document is subject 1791 to the rights, licenses and restrictions contained in BCP 78, and 1792 except as set forth therein, the authors retain all their rights. 1794 Acknowledgment 1796 Funding for the RFC Editor function is currently provided by the 1797 Internet Society.