idnits 2.17.00 (12 Aug 2021) /tmp/idnits59396/draft-crocker-email-arch-02.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 1536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1526. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (January 26, 2005) is 6323 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) == Unused Reference: 'RFC2033' is defined on line 1405, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 1428, but no explicit reference was found in the text == Unused Reference: 'RFC2298' is defined on line 1431, but no explicit reference was found in the text == Unused Reference: 'RFC2423' is defined on line 1444, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 1455, but no explicit reference was found in the text == Unused Reference: 'RFC3028' is defined on line 1469, but no explicit reference was found in the text == Unused Reference: 'RFC3461' is defined on line 1472, but no explicit reference was found in the text == Outdated reference: draft-klyne-hdrreg-mail has been published as RFC 4021 -- No information found for draft-spamops - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID-spamops' ** 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: 22 errors (**), 0 flaws (~~), 10 warnings (==), 9 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: July 27, 2005 January 26, 2005 5 Internet Mail Architecture 6 draft-crocker-email-arch-02 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 July 27, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 Over its thirty year history, Internet mail has undergone significant 42 changes in scale and complexity. The first standardized architecture 43 for email specified a simple split between the user world and the 44 transmission world, in the form of Mail User Agents (MUA) and Mail 45 Transfer Agents (MTA). Over time each of these has divided into 46 multiple, specialized modules. Public discussion and agreement about 47 the nature of the changes to Internet mail has not kept pace, and 48 abuses of the Internet mail service have brought these issues into 49 stark relief. This draft offers clarifications and enhancements, to 50 provide a more consistent base for community discussion of email 51 service problems and proposed email service enhancements. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Service Overview . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2 Document Changes . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.3 Discussion venue . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Email Actor Roles . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1 User-Level Actors . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2 Transfer-Level Actors . . . . . . . . . . . . . . . . . . . . 8 62 2.3 Administrative Actors . . . . . . . . . . . . . . . . . . . . 11 63 3. Email Identities . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.1 Mailbox Addresses . . . . . . . . . . . . . . . . . . . . . . 12 65 3.2 Domain Names . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 3.3 Message Identifers . . . . . . . . . . . . . . . . . . . . . . 13 67 3.4 Identity Referencing Convention . . . . . . . . . . . . . . . 13 68 4. Protocols and Services . . . . . . . . . . . . . . . . . . . . 13 69 4.1 Service Components . . . . . . . . . . . . . . . . . . . . . . 15 70 4.2 Operational Configuration . . . . . . . . . . . . . . . . . . 21 71 4.3 Layers of Identity References . . . . . . . . . . . . . . . . 21 72 5. Message Data . . . . . . . . . . . . . . . . . . . . . . . . . 22 73 5.1 Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 5.2 Message Header Fields . . . . . . . . . . . . . . . . . . . . 22 75 5.3 Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 6. Two Levels of Store-And-Forward . . . . . . . . . . . . . . . 23 77 6.1 MTA Relaying . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 6.2 MUA Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 23 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33 82 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 83 Intellectual Property and Copyright Statements . . . . . . . . 34 85 1. Introduction 87 Over its thirty year history, Internet mail has undergone significant 88 changes in scale and complexity. The first standardized architecture 89 for email specified a simple split between the user world and the 90 transmission world, in the form of Mail User Agents (MUA) and Mail 91 Transfer Agents (MTA). Over time each of these has sub-divided into 92 more specialized modules. However the basic style and use of names, 93 addresses and message structure have remained remarkably constant. 95 There are two, basic categories of participants in Internet Mail. 96 Users are customers of the Mail Handling Service (MHS). They 97 represent the sources and sinks of that service. The Mail Handling 98 Service is responsible for accepting a message from one user and 99 delivering to one or more others. 101 +--------+ 102 +---------------->| User | 103 | +--------+ 104 | . 105 +--------+ | +--------+ . 106 | User +--+--------->| User | . 107 +--------+ | +--------+ . 108 | . . 109 . | +--------+ . . 110 . +-->| User | . . 111 . +--------+ . . 112 . . . . 113 . . . . 114 . . . . 115 +--------------------------------------+ 116 | | 117 | Mail Handling Service (MHS) | 118 | | 119 +--------------------------------------+ 121 Figure 1: Basic Email Service Model 123 Public discussion and agreement about terms of reference have not 124 kept pace with the changes, and abuses of the Internet mail service 125 have brought this into stark relief. So, it is necessary to produce 126 a revised architecture. However it is important that the original 127 distinction between user-level concerns and transfer-level concerns 128 be retained. This becomes challenging when the user-level exchange 129 is, itself, a sequence, such as with group dialogue or organizational 130 message flow, as occurs with a purchase approval process. It is easy 131 to confuse this user-level activity with the underlying mail 132 transmission service exchanges. 134 For Internet mail, the term "end-to-end" usually refers to single 135 posting and the set of deliveries resulting from a single transiting 136 of the MHS. However, note that specialized uses of email consider 137 the entire email service -- including Originator and Recipient -- as 138 a subordinate component. For these services, "end-to-end" refers to 139 points outside of the email service. Examples are voicemail over 140 email and EDI over email. 142 The current draft seeks to: 144 1. Document changes that have taken place in refining the email 145 model 147 2. Clarify functional roles for the architectural components 149 3. Clarify identity-related issues, across the email service 151 4. Provide a common venue for further defining and citing modern 152 Internet mail architecture 154 1.1 Service Overview 156 End-to-end Internet mail exchange is accomplished by using a 157 standardized infrastructure comprising: 159 1. An email object 161 2. Global addressing 163 3. A connected sequence of point-to-point transfer mechanisms 165 4. No prior arrangement between originator and recipient 167 5. No prior arrangement between point-to-point transfer services, 168 over the open Internet 170 The end-to-end portion of the service is the message. Broadly the 171 message, itself, is divided between handling control information and 172 user message payload. 174 A precept to the design of Internet mail is to permit user-to-user 175 and MTA-to-MTA interoperability with no prior, direct administrative 176 arrangement. That is, all participants rely on having the core 177 services be universally supported, either directly or through 178 gateways that translate between Internet mail standards and other 179 email conventions. 181 For localized environments (edge networks) prior, administrative 182 arrangement can include access control, routing constraints and 183 lookup service configuration. In recent years one change to local 184 environments is an increased requirement for authentication or, at 185 least, accountability. In these cases, the server performs explicit 186 validation of the client's identity. 188 1.2 Document Changes 190 The major changes from the previous version of this document are: 192 Overall: Clarify roles and responsibilities 194 Diagrams: Revised diagrams and tightened things up 196 Distinct architectural 'sections': Added concept of ADMDs, as 197 operational layer, separate from functional or architectural 198 layer. Added user "layer", as distinct from transfer. Introduced 199 'mediator'. 201 1.3 Discussion venue 203 NOTE: This document is the work of a single person, about a topic 204 with considerable diversity of views. It is certain to be 205 incomplete and inaccurate. Some errors simply need to be 206 reported; they will get fixed. Others need to be discussed by the 207 community, because the real requirement is to develop common 208 community views. To this end, please treat the draft as a 209 touchstone for public discussion. 211 Discussion about this document should be directed to the: 212 mailing list. The IETF-SMTP mailing list 213 is the most active, 214 long-standing venue for discussing email architecture. Although this 215 list is primarily for discussing only the SMTP protocol, it is 216 recommended that discussion of this draft take place on that mailing 217 list. This list tends to attend to end-to-end infrastructure and 218 architecture issues more than other email-related mailing lists. 220 2. Email Actor Roles 222 Discussion of email architecture requires distinguishing different 223 actors within the service, and being clear about the job each 224 performs. The best way to maintain the distinction between user 225 activity and handling activities is to depict their details in 226 separate diagrams. Current Internet mail provides only a small set 227 of capabilities for supporting different kinds of ongoing, user-level 228 exchanges. 230 Although related to a technical architecture, the focus of a 231 discussions on Actors is on participant responsibilities, rather than 232 functional modules. Hence the labels used are different than for 233 classic email architecture diagrams. The figures depict the 234 relationships among the Actors. Actors often will be associated with 235 entirely independent organizations from other Actors who are 236 participating in the email service. 238 2.1 User-Level 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. 244 In Internet Mail there are three, basic types of user-level Actors: 245 Originators, Recipients, and Mediators. Fromhe t User-level 246 perspective all mail transfer activities are performed by a 247 monolithic, shared handling service. Users are customers of this 248 service. The following depicts the relationships among them. 250 +------------+ 251 | Originator |<--------------+ 252 +-+---+----+-+ | 253 | | | | 254 | | V | 255 | | +-----------+ | 256 | | | Recipient | | 257 | | +-----------+ | 258 | | | 259 | | +----------+ | 260 | | | | | 261 | V V | | 262 | +-----------+ +---+---+---+ 263 | | Mediator +--->| Recipient | 264 | +-----------+ +-----------+ 265 | 266 V 267 +-----------+ +-----------+ +-----------+ 268 | Mediator +--->| Mediator +--->| Recipient | 269 +-----------+ +-----------+ +-----------+ 271 The functions of these Actors are: 273 2.1.1 Originator 275 Also called "Author", this is the user-level participant responsible 276 for creating original content and requesting its transmission. The 277 Mail Handling Service operates to send and deliver mail among 278 Originators and Recipients. 280 2.1.2 Recipient 282 The Recipient is a consumer of delivered content. 284 A recipient may close the user-level communication loop by creating 285 and submitting a new message that replies to an originator. An 286 automated, or semi-automated form of reply informs the Originator 287 about the Recipient's disposition of the message. 289 2.1.3 Mediator 291 A Mediator receives, aggregates, reformulates and distributes 292 messages as part of a potentially-protracted, higher-level exchange 293 among users. A Mediator is viewed by the Mail Handling Service, when 294 the Mediator's address is specified in the envelope. When submitting 295 messages, the Mediator is an Originator. What is distinctive is that 296 a Mediator preserves Originator information of the message(s) it 297 reformulates, but makes meaningful changes to the content. Hence the 298 Mail Handling Service sees a new message, but Users receive a message 299 that is interpreted as primarily being from the author of the 300 original message. The role of a Mediator permits distinct, active 301 creativity, rather than being limited the more passive job of merely 302 connecting together other participants. Hence it is really the 303 Mediator that is responsible for the new message. 305 A Mediator's task may be complex, contingent and creative, such as by 306 modifying and adding content or regulating which users may 307 participate and when. The popular example of this role is a group 308 mailing list. A sequence of mediators may even perform a series of 309 formal steps, such as reviewing, modifying and approving a purchase 310 request. 312 Because a Mediator originates messages, it might also receive 313 replies. That is, a Mediator is a full-fledged User. 315 Specialized Mediators include: 317 Forwarder: A new message encapsulates the original message and is 318 seen as strictly "from" the Mediator. However the Mediator might 319 add commentary and certainly has the opportunity to modify the 320 original message content. 322 Redirector: Redirection differs from Forwarding by virtue of having 323 the Mediator "splice" communication between the Originator of the 324 original message and the Recipient of the new message. Hence the 325 new Recipient sees the message as being From the original 326 Originator. 328 Mailing List: This Actor performs a task that can be viewed as an 329 elaboration of the Redirector role. In addition to sending the 330 new message to a potentially large number of new Recipients, 331 content might be modified, such as deletion of attachments, 332 formatting conversion, and addition of list-specific comments. In 333 additional, archival of list messages is common. 335 Annotator: The integrity of the original message is preserved, but 336 one or more comments about the message are added in a manner that 337 distinguishes commentary from original text. 339 Adaptor: {per Ned Freed} 341 Security Filter: Organizations often enforce security boundaries by 342 having message subjected to analysis for conformance with the 343 organization's safety policies. Examples are detection of content 344 classed as spam or a virus. A Security Filter might alter the 345 content, to render it safe, such as by removing content deemed 346 unacceptable. Typically these actions will result in the addition 347 of content that records the actions. 349 2.2 Transfer-Level Actors 351 The Mail Handling Service has the task of performing a single, 352 end-to-end transfer on behalf of the originator and reaching the 353 recipient address(es) specified in the envelope. Protracted, 354 iterative exchanges, such as those used for collaboration over time, 355 are part of the User-level service, and are not part of this 356 Transfer-level service. 358 The following depicts the relationships among transfer participants 359 in Internet Mail. It shows Source as distinct from the Originator, 360 although it is common for them to be the same actor. The figure also 361 shows multiple Relays in the sequence. It is legal to have only one, 362 and for intra-organization mail services, this is common. 364 +------------+ +-----------+ 365 | Originator | | Recipient | 366 +-----+------+ +-----------+ 367 | ^ 368 | Mail Handling Service | 369 +===================================================+ 370 || | | || 371 || | | || 372 V | 373 +---------+ +--------+ +----+----+ 374 | | | |<------------+ | 375 | Source +...>| Notice | | Dest | 376 | | | |<---+ | | 377 +----+----+ +--------+ | +---------+ 378 | | ^ 379 V | | 380 +---------+ +----+----+ +----+----+ 381 | Relay +-->.......-->| Relay +-->| Relay | 382 +---------+ +----+----+ +---------+ 383 | 384 V 385 +---------+ 386 | Gateway +-->... 387 +---------+ 389 2.2.1 Source 391 The Source role is responsible for ensuring that a message is valid 392 for posting and then submitting it to a mail relay. Validity 393 includes conformance with Internet mail standards, as well as local 394 operational policies. Source may simply review the message for 395 conformance, and reject it if there are errors, or it may create some 396 or all of the necessary information. 398 Source operates with dual allegiance. It serves the Originator and 399 often it is the same entity. However its role in assuring validity 400 means that it must represent the local operator of the Mail Handling 401 Service. 403 Source also has the responsibility for any post-submission, 404 originator-related administrative tasks associated with message 405 transmission and delivery. Notably this pertains to error and 406 delivery notices. Hence, Source is best held accountable for the 407 message content, even when they did not create any or most of it. 409 2.2.2 Notices Handler 411 Transfer efforts might result in the generation of service reporting 412 information about failures or completions. These Transfer or 413 Delivery notification messages are sent to an address that is 414 specified by the Source. A Notices handling address (also known as 415 Bounce or Return address) might have no characteristics in common the 416 with address of the Originator or Source. 418 2.2.3 Relay 420 A mail relay performs email transfer-service routing and 421 store-and-forward. It adds envelope-related handling information and 422 then (re-)transmits the message on towards its recipient(s). A Relay 423 does not modify the message contents. 425 A basic transfer operation is between a client and a server Relay. A 426 set of Relays composes a Mail Handling Service network. This is 427 above any underlying packet-switching network that they might be 428 using. 430 Aborting 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 Bounce address. 435 2.2.4 Gateway 437 A Gateway is a special form of Relay that interconnects heterogeneous 438 mail services. Differences between the services can be as small as 439 minor syntax variations, but usually encompass much more basic, 440 semantic distinctions. For example, the concept of an email address 441 might be as different as a hierarchical, machine-specific address 442 versus a flat, global name space. Or between text-only and 443 multi-media. Hence, the Relay function of a gateway is the minor 444 component. The significant challenge is in the user-to-user 445 functionality that matches syntax and semantics of independent email 446 standards suites. 448 The basic test of a gateway's adequacy is, of course, whether an 449 originator can send a message to a recipient, without requiring any 450 changes to the components in the originator's mail service or the 451 recipient's mail service, other than adding the gateway. To each of 452 these otherwise independent services, the gateway will appear to be a 453 "native" participant. However the ultimate test of a gateway's 454 adequacy is whether the originator and recipient can sustain a 455 dialogue. In particular, can a recipient formulate a Reply? 457 2.3 Administrative Actors 459 Operation of Internet mail services is apportioned to different 460 providers (or operators) each is composed of an independent 461 Administrative Domain. Examples include an end-user operating their 462 desktop client, a department operating a local relay, an IT 463 department operating an enterprise relay, and an ISP operating a 464 public, shared email service. These can be configured into many 465 combinations of administrative and operational relationships, with 466 each Administrative Domain potentially having a complex arrangement 467 of functional components. 469 The interactions between functional components within an 470 Administrative Domain are subject to the policies of that domain. 471 Policies can cover such things as reliability, access control, 472 accountability and content evaluation and may be implemented in 473 different functional components, according to the needs of the 474 Administrative Domain. 476 2.3.1 Provider 478 Providers operate component services or sets of services. It is 479 possible for Providers to host services for other Providers. Common 480 examples are: 482 Enterprise Service Providers: Operating an organization's internal 483 data and/or mail operations. 485 Internet Service Providers: Operating underlying data communication 486 services that, in turn, are used by one or more Relays and Users. 487 It is not their job to perform email functions, but to provide an 488 environment in which those functions can be performed. 490 Mail Service Providers: Operate email services, such as for 491 end-users, or mailing lists. 493 Operational pragmatics often dictate that Providers be involved in 494 detailed administration and enforcement issues, to help insure the 495 health of the overall Internet Mail Service. 497 3. Email Identities 499 Internet mail uses three forms of identity. The most common is the 500 mailbox address [RFC2822]. The other two forms are the 501 [RFC1034] and message identifier [RFC2822]. 503 3.1 Mailbox Addresses 505 An addr-spec has two distinct parts, divided by an at-sign ("@"). 506 The right-hand side contains a globally interpreted name for an 507 administrative domain. This domain name might refer to an entire 508 organization, or to a collection of machines integrated into a 509 homogeneous service, or to a single machine. Domain names are 510 defined and operated through the DNS [RFC1034], [RFC1035]. 512 The left-hand side of the at-sign contains a string that is globally 513 opaque and is called the . It is to be interpreted only 514 by the entity specified in the address's right-hand side. All other 515 entities must treat the local-part as a uninterpreted, literal string 516 and must preserve all of its original details. As such, its 517 distribution is equivalent to sending a "cookie" that is only 518 interpreted upon being returned to its originator. 520 3.1.1 Global Standards for Local-Part 522 It is common for sites to have local structuring conventions for the 523 left-hand side (local-part) of an addr-spec. This permits 524 sub-addressing, such as for distinguishing different discussion 525 groups by the same participant. However it must be stressed that 526 these conventions are strictly private to the user's organization and 527 must not be interpreted by any domain except the one listed in the 528 right-hand side of the add-spec. 530 A small class of addresses have an elaboration on basic email 531 addressing, with a standardized, global schema for the local-part. 532 These are conventions between originating end-systems and recipient 533 gateways, and they are invisible to the public email transfer 534 infrastructure. When an originator is explicitly sending via a 535 gateway out of the Internet, there are coding conventions for the 536 local-part, so that the originator can formulate instructions for the 537 gateway. Standardized examples of this are the telephone numbering 538 formats for VPIM [RFC2421], such as "+16137637582@vpim.example.com", 539 and iFax [RFC2304], such as "FAX=+12027653000/ 540 T33S=1387@ifax.example.com". 542 3.1.2 Scope of Email Address Use 544 Email addresses are being used far beyond their original email 545 transfer and delivery role. In practical terms, email strings have 546 become a common form of user identity on the Internet. What is 547 essential, then, is to be clear about the nature and role of an 548 identity string in a particular context and to be clear about the 549 entity responsible for setting that string. 551 3.2 Domain Names 553 A domain name is a global reference to an Internet resource, such as 554 a host, a service or a network. A name usually maps to one or more 555 IP Addresses. A domain name can be administered to refer to 556 individual users, but this is not common practice. The name is 557 structure as a hierarchical sequence of sub-names, separated by dots 558 ("."). 560 When not part of a mailbox address, a domain name is used in Internet 561 mail to refer to a node that took action upon the message, such as 562 providing the administrative scope for a message identifier, or 563 performing transfer processing. 565 3.3 Message Identifers 567 Message identifiers have two distinct parts, divided by an at-sign 568 ("@"). The right-hand side contains a globally interpreted name for 569 the administrative domain assigning the identifier. The left-hand 570 side of the at-sign contains a string that is globally opaque and 571 serves to uniquely identify the message within the domain referenced 572 on the right-hand side. The duration of uniqueness for the message 573 identifier is undefined. 575 The identifier may be assigned by the user or by any component of the 576 system along the path. Although Internet mail standards provide for 577 a single identifier, more than one is sometimes assigned. 579 3.4 Identity Referencing Convention 581 In this document, fields references to identities are labeled in a 582 two-part, dotted notation. The first part cites the document 583 defining the identity and the second defines the name of the 584 identity. Hence, is the From field in an email 585 content header, and is the address in the SMTP 586 "Mail From" command. 588 4. Protocols and Services 590 NOTE: A discussion about any interesting system architecture is 591 often complicated by confusion between architecture versus 592 implementation. An architecture defines the conceptual functions 593 of a service, divided into discrete conceptual modules. An 594 implementation of that architecture may combine or separate 595 architectural components, as needed for a particular operational 596 environment. It is important not to confuse the engineering 597 decisions that are made to implement a product, with the 598 architectural abstractions used to define conceptual functions. 600 Modern Internet email architecture distinguishes four types of 601 functional components, arranged to support a store-and-forward 602 service architecture: 604 +------+ 605 .............+ oMUA |<------------------------------+ 606 . +--+---+ | 607 . | { smtp,submission | 608 . V | 609 . +------+ | 610 . | MSA |<--------------------+ | 611 . +--+---+ | | 612 . | { smtp | | 613 . V | | 614 . +------+ +====+====+ | 615 . | MTA | || dsn || | 616 +============+ +--+---+ +=========+ | 617 || MESSAGE || . { smtp ^ ^ | 618 || || . | | | 619 ||(envelope)|| . | | | 620 || || V | | | 621 || RFC2822 || +------+ | | +===+===+ 622 || || | MTA +-------------------+ | || mdn || 623 || MIME || +--+---+ | +=======+ 624 +============+ | { local, smtp, lmtp | | 625 . V | | 626 . +------+ | | 627 . | +-----------------------+ | 628 . | MDA | | 629 . | |<--------------------+ | 630 . +-+--+-+ | | 631 . local } | | | | 632 . V | | | 633 . +------+ | +====+====+ | 634 . | MS-1 | | || sieve || | 635 . +-+--+-+ | +=========+ | 636 . | | | { pop, imap ^ | 637 . | V V | | 638 . | +------+ | | 639 . | | MS-2 | | | 640 . | +--+---+ | | 641 . | | { pop, imap, local | | 642 . V V | | 643 . +------+ | | 644 .........>| rMUA +------------------------+---------+ 645 +------+ 647 Software implementations of these architectural components often 648 compress them, such as having the same software do MSA, MTA and MDA 649 functions. However the requirements for each of these components of 650 the service are becoming more extensive. So, their separation is 651 increasingly common. 653 4.1 Service Components 655 4.1.1 Mail User Agent (MUA) 657 A Mail User Agent (MUA) works on behalf of end-users and end-user 658 applications. It is their "representative" within the email service. 660 At the origination side of the service, the oMUA is used to create a 661 message and perform initial "submission" into the transfer 662 infrastructure, via a Mail Submission Agent (MSA). It may also 663 perform any creation- and posting-time archival. An MUA outbox is 664 part of the origination-side MUA. 666 The recipient-side rMUA works on behalf of the end-user recipient to 667 process received mail. This includes generating user-level return 668 control messages, display and disposition of the received message, 669 and closing or expanding the user communication loop, by initiating 670 replies and forwarding new messages. 672 An MUA may, itself, have a distributed architecture, such as 673 implementing a "thin" user interface module on a limited end-user 674 device, with the bulk of the MUA functionality operated remotely on a 675 more capable server. An example of such an architecture might use 676 IMAP [RFC3501] for most of the interactions between an MUA client and 677 an MUA server. 679 A special class of MUA performs message re-posting, as discussed in 680 the section. 682 Identity fields set by the MUA include: 684 RFC2822.From 686 Actor: Originator 688 Names and addresses for author(s) of the message content are 689 listed in the From header field 691 RFC2822.Reply-To 693 Actor: Originator 695 If a message recipient sends a reply message that would otherwise 696 use RFC2822.From field address(es) contained in the original 697 message, then they are instead to use the address(es) in the 698 RFC2822.Reply-To field. In other words, this field is a direct 699 override of the From field, for responses from recipients. 701 RFC2822.Sender 703 Actor: Source 705 This specifies the address responsible for submission into the 706 transfer service. For efficiency, this field should be omitted if 707 it contains the same address as RFC2822.From. However this does 708 not mean there is no Sender specified. Rather, it means that that 709 header field is virtual and that the address in the From field 710 must be used. Specification of the error return addresses -- the 711 "notifications" (or "bounces") address, contained in 712 RFC2821.MailFrom -- is made by the RFC2822.Sender. Typically the 713 notifications address is the same as the Sender address. However 714 some usage scenarios require it to be different. 716 RFC2822.To, RFC2822.CC 718 Actor: Recipient 720 These specify MUA recipient addresses. The distinction between To 721 and CC is subjective. Generally, a To addressee is considered 722 primary and is expected to take action on the message. A CC 723 addressee typically receives a copy only for their information. 725 RFC2822.BCC 727 Actor: Recipient 729 A message might be copied to an addressee whose participation is 730 not to be disclosed to the RFC2822.To or RFC2822.CC recipients. 731 The BCC header field indicates a message copy to such a recipient. 732 Typically, the field lists no addresses or only lists the address 733 of the single recipient receiving the copy. This usually ensures 734 that even other BCC recipients do not know of each other. An MUA 735 will typically make separate postings for TO and CC recipients, 736 versus BCC recipients. The former will see no indication that any 737 BCCs were sent, whereas the latter have a BCC field present. It 738 might be empty, contain a comment, or contain one or more BCC 739 addresses, depending upon the preferences or the Originator. 741 4.1.2 Mail Submission Agent (MSA) 743 A Mail Submission Agent (MSA) accepts the message submission from the 744 oMUA and enforces the policies of the hosting network and the 745 requirements of Internet standards. Enforcement might be passive, 746 involving review and approval or rejection, or it might be active, 747 involving direct modification of the message. An MSA implements a 748 server function to MUAs and a client function to MTAs (or MDAs). 750 Examples of MSA-styled functions, in the world of paper mail, might 751 range across the very different capabilities of administrative 752 assistants, postal drop boxes, and post office front-counter 753 employees. 755 The MUA/MSA interface can be implemented within single host and use 756 private conventions for their interactions. Historically, 757 standards-based MUA/MSA interactions have used SMTP [RFC2821]. 758 However a recent alternative is SUBMISSION [RFC2476]. Although 759 SUBMISSION derives from SMTP, it operates on a separate TCP port, and 760 will typically impose distinct requirements, such as access 761 authorization. 763 Identities set by the MSA include: 765 RFC2821.HELO or RFC2821.EHLO 767 Actor: Source 769 The MSA may specify its hosting domain identity for the SMTP HELO 770 or EHLO command operation. 772 RFC2821.MailFrom 774 Actor: Source 776 This is an end-to-end string that specifies an email address for 777 receiving return control information, such as "bounces". The name 778 of this field is misleading, because it is not required to specify 779 either the author or the agent responsible for submitting the 780 message. Rather, the agent responsible for submission specifies 781 the RFC2821.MailFrom address. Ultimately the simple basis for 782 deciding what address needs to be in the RFC2821.MailFrom is to 783 determine what address needs to be informed about 784 transmission-level problems (and, possibly, successes. 786 RFC2821.Rcpt-To 788 Actor: Recipient 790 This specifies the MUA inbox address of a recipient. The string 791 might not be visible in the message content header. For example, 792 the message destination address header fields, such as RFC2822.To, 793 might specify a mailing list address, while the RFC2821.Rcpt-To 794 address specifies a member of that list. 796 RFC2821.Received 798 Actor: Source 800 An MSA may record a Received header field, to indicate initial 801 submission trace information, including originating host and MSA 802 host domain names and/or IP Addresses. 804 4.1.3 Mail Transfer Agent (MTA) 806 An relays a message to another other MTA or to an , in a 807 point-to-point exchange. Relaying is performed by a sequence of 808 MTAs, until the message reaches its destination MDA. Hence an MTA 809 implements both client and server MTA functionality. 811 The basic functionality of an MTA is similar to that of a packet 812 switch or IP router. That is, it does email store-and-forward email, 813 with a routing decision determining where the next-hop destination 814 shall be. The primary "routing" mechanism for Internet mail is the 815 DNS MX record [RFC1035]. As with most "link layer" mechanisms 816 Internet mail's SMTP supports a basic level of reliability, by virtue 817 of providing for retransmission after al transfer failure. However 818 the degree of persistence by an MTA can be highly variable. 820 However email objects are typically much larger than the payload of a 821 packet or datagram, and the end-to-end latencies are typically much 822 higher. Contrary to typical packet switches (and Instant Messaging 823 services) Internet mail MTAs typically store messages in a manner 824 that allows recovery across services interruptions, such as host 825 system shutdown. 827 Internet mail primarily uses SMTP [RFC2821], [RFC0821] to effect 828 point-to-point transfers between peer MTAs. Other transfer 829 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645] 831 An important characteristic of MTA-MTA communications, over the open 832 Internet, is that they do not require prior arrangement between the 833 independent administrations operating the different MTAs. Given the 834 importance of spontaneity and serendipity in the world of human 835 communications, this lack of prearrangement, between the 836 participants, is a core benefit of Internet mail and remains a core 837 requirement for it. 839 Identities set by the MTA include: 841 RFC2821.HELO 843 Actor: Relay 845 The MTA may specify its hosting domain identity for the SMTP HELO 846 or EHLO command operation. 848 RFC2821.Return-Path 850 Actor: Source 852 The MDA records the RFC2821.MailFrom address into an RFC2822 853 header field named Return-Path. 855 RFC2822.Received 857 Actor: Relay 859 An MTA must record a Received header field, to indicate trace 860 information, including source host and receiving host domain names 861 and/or IP Addresses. 863 4.1.4 Mail Delivery Agent (MDA) 865 The delivers email to the recipient's inbox. 867 A Mail Delivery Agent (MDA) can provide distinctive, address-based 868 functionality, made possible by its detailed knowledge of the 869 properties of the destination address. This knowledge might also be 870 present elsewhere in the recipient's Administrative Domain, such as 871 at an organizational border gateway. However it is required for the 872 MDA, if only because the MDA must know where to store the message. 873 This knowledge is used to achieve differential handling of messages. 875 Using Internet protocols, delivery is effected with POP [RFC1939] or 876 IMAP [RFC3501]. When coupled with an internal, local mechanism, SMTP 877 permits "push" delivery to the recipient system, at the initative of 878 the upstream email service. POP is used for "pull" delivery at the 879 initiative of the recipient system. Notably, SMTP and POP effect a 880 transfer of message control from the email service to the recipient 881 host. In contrast, IMAP provides on-going, interactive access to a 882 message store, and does not effect a transfer of message control to 883 the end-user host. Instead, control stays with the message store 884 host that is being access by the user. 886 Identities set by the MDA include: 888 RFC2821.HELO or RFC2821.EHLO 890 Actor: Relay 892 The MDA may specify its hosting domain identity for the SMTP HELO 893 or EHLO command operation. 895 RFC2822.Received 897 Actors: Source, Relay, Dest 899 An MTA must record a Received header field, to indicate trace 900 information, including source host and receiving host domain names 901 and/or IP Addresses. 903 4.1.5 Message Store 905 An MUA's uses a long-term Message Store (MS). A rich set of choices 906 for the use of that store derives from permitting more than one to be 907 associated with a single user, demonstrated as MS-1 and MS-2 in the 908 Figure. MS-1 is shown as being remote from the MUA and MS-2 as being 909 local. Further the relationship between two message store may vary. 910 Between the MDA and the MUA, these choices are supported by a wide 911 variety of protocol options. 913 The operational relationship among two MSs can be: 915 Online: Only a remote MS is used, with messages being accessible 916 only when the MUA is attached to the MS, and the MUA repeatedly 917 fetches all or part of a message, from one session to the next. 919 Offline: The MS is local to the user, and messages are moved from 920 any remote store, rather than (also) being retained there. 922 Disconnected: A remote MS and a local MS synchronize all or parts of 923 their contents, while connected. The user may make changes while 924 disconnected, and the two stores are re-synchronized upon 925 reconnection. 927 4.2 Operational Configuration 929 Mail service components can be arranged into numerous organizational 930 structures, each with independent software and administration. One 931 common arrangement is to distinguish: 933 1. an open, core, global email transfer infrastructure 935 2. independent transfer services in networks at the edge of the core 937 3. end-user services 939 Edge networks may use proprietary email standards. However the 940 distinction between "public" network and edge network transfer 941 services is primarily significant because it highlights the need for 942 concern over interaction and protection between independent 943 administrations. In particular, this distinctions calls for 944 additional care in assessing transitions of responsibility, as well 945 as the accountability and authorization relationships among 946 participants in email transfer. 948 On the other hand, real-world operations of Internet mail 949 environments do impose boundaries such as access control at 950 organizational firewalls to the Internet. It should be noted that 951 the current Internet Mail architecture offers no special constructs 952 for these configuration choices. The current design of Internet mail 953 is for a seamless, end-to-end store-and-forward sequence. It is 954 possible that the architectural enhancement will not require new 955 protocols, but rather will require clarification of best practises, 956 as exemplified by a recent effort [ID-spamops] 958 4.3 Layers of Identity References 960 For a message in transit, the core identity fields combine into: 962 +-----------------------+-------------+---------------------+ 963 | Layer | Field | Set By | 964 +-----------------------+-------------+---------------------+ 965 | Message Content | MIME Header | Originator | 966 | Message header fields | From | Originator | 967 | | Sender | Source | 968 | | Reply-To | Originator | 969 | | To, CC, BCC | Originator | 970 | | Received | Source, Relay, Dest | 971 | | Return-Path | MDA, from MailFrom | 972 | SMTP | HELO | Latest Relay Client | 973 | | MailFrom | Source | 974 | | RCPT-TO | Originator | 975 | IP | IP Address | Latest Relay Client | 976 +-----------------------+-------------+---------------------+ 978 5. Message Data 980 5.1 Envelope 982 Information that is directly used or produced by the email transfer 983 service is called the "envelope". It controls and records handling 984 activities by the transfer service. Internet mail has a fragmented 985 framework for handling this "handling" information. The envelope 986 exists partly in the transfer protocol SMTP [RFC2821] and partly in 987 the message object [RFC2822]. 989 Direct envelope addressing information, as well as optional transfer 990 directives, are carried in-band by MTAs. All other envelope 991 information, such as trace records, is carried within the content 992 header fields. Upon delivery, SMTP-level envelope information is 993 typically encoded within additional content header fields, such as 994 Return-Path and Received (From and For). 996 5.2 Message Header Fields 998 Header fields are attribute/value pairs covering an extensible range 999 of email service, user content and user transaction meta-information. 1000 The core set of header fields is defined in [RFC2822], [RFC0822]. It 1001 is common to extend this set, for different applications. A complete 1002 set of registered header fields is being developed through 1003 [ID-hdr-reg]. 1005 One danger with placing additional information in header fields is 1006 that gateways often alter or delete them. 1008 5.3 Body 1010 The body of a message might simply be lines of ASCII text or it might 1011 be structured into a composition of multi-media, body-part 1012 attachments, using MIME [RFC2045], [RFC2046], [RFC2047], [RFC2048], 1013 and [RFC2049]. It should be noted that MIME structures each 1014 body-part into a recursive set of MIME header field meta-data and 1015 MIME Content sections. 1017 6. Two Levels of Store-And-Forward 1019 Basic email transfer is accomplished with an asynchronous 1020 store-and-forward communication infrastructure. This means that 1021 moving a message from an originator to a recipient involves a 1022 sequence of independent transmissions through some number of 1023 intermediaries, called MTAs. A very different task is the user-level 1024 process of re-posting a message through a new submission process, 1025 after final delivery for an earlier transfer sequence. Such 1026 MUA-based re-posting shares some functionality with basic MTA 1027 relaying, but it enjoys a degree of freedom with both addressing and 1028 content that is not available to MTAs. 1030 The primary "routing" mechanism for Internet mail is the DNS MX 1031 record [RFC1035]. It is an advertisement, by a recipient domain, of 1032 hosts that are able to relay mail to it, within the portion of the 1033 Internet served by this instance of the DNS. 1035 6.1 MTA Relaying 1037 MTAs relay mail. They are like packet-switches and IP routers. 1038 Their job is to make routing assessments and to move the message 1039 payload data closer to the recipient. It is not their job to 1040 reformulate the payload or to change addresses in the envelope or the 1041 content. 1043 6.2 MUA Forwarding 1045 As discussed in section, forwarding is performed by MUAs 1046 that take a received message and submit it back to the transfer 1047 service, for delivery to one or more different addresses. A 1048 forwarded message may appear identical to a relayed message, such as 1049 for Alias forwarders, or it may have minimal similarity, as with a 1050 Reply. 1052 6.2.1 MUA Basic Forwarding 1054 The simplest type of forwarding involves creating an entirely new 1055 message, with new content, that includes the original message between 1056 Originator-1 and Recipient-1. However this forwarded communication 1057 is between Recipient-1 (who could also be called Originator-2) and a 1058 new recipient, Recipient-2. The forwarded message is therefore 1059 independent of the original message exchange and creates a new 1060 message dialogue. 1062 6.2.2 MUA Re-Sending 1064 A recipient may wish to declare that an alternate addressee should 1065 take on responsibility for a message, or otherwise become involved in 1066 the original communication. They do this through a user-level 1067 forwarding function, called re-sending. The act of re-sending, or 1068 re-directing, splices a communication between Originator-1 and 1069 Recipient-1, to become a communication between Originator-1 and new 1070 Recipient-2. In this case, the content of the new message is the old 1071 message, including preservation of the essential aspects of the 1072 original message's origination information. 1074 Identities specified in a resent message include 1076 RFC2822.From 1078 Actor: Originator 1080 Names and email addresses for the original author(s) of the 1081 message content are retained. The free-form (display-name) 1082 portion of the address might be modified to provide informal 1083 reference to the agent responsible for the redirection. 1085 RFC2822.Reply-To 1087 Actor: Originator 1089 If this field is present in the original message, it should be 1090 retained in the Re-sent message. 1092 RFC2822.Sender 1094 Actor: Source 1096 This field is expected to contain the original Sender value. 1098 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1100 Actor: Recipient 1101 These specify the original message recipients. 1103 RFC2822.Resent-From 1105 Actor: Mediating Originator 1107 The address of the original recipient who is redirecting the 1108 message. Otherwise, the same rules apply for the Resent-From 1109 field as for an original RFC2822.From field 1111 RFC2822.Resent-Sender 1113 Actor: Mediating Source 1115 The address of the agent responsible for re-submitting the 1116 message. For efficiency, this field should be omitted if it 1117 contains the same address as RFC2822.Resent-From. However this 1118 does not mean there is no Resend-Sender specified. Rather, it 1119 means that that header field is virtual and that the address in 1120 the Resent-From field must be used. Specification of the error 1121 return addresses (the "bounces" address, contained in 1122 RFC2821.MailFrom) is made by the Resent-Sender. Typically the 1123 bounce address is the same as the Resent-Sender address. However 1124 some usage scenarios require it to be different. 1126 RFC2822.Resent-To, RFC2822.Resent-cc, RFC2822.Resent-bcc: Actor: 1127 Recipient 1129 The addresses of the new recipients who will now be able to reply 1130 to the original author. 1132 RFC2821.MailFrom 1134 Actor: Mediating Source 1136 The agent responsible for re-submission (RFC2822.Resent-Sender) is 1137 also responsible for specifying the new RFC2821.MailFrom address. 1139 RFC2821.Rcpt-to 1141 Actor: Recipient 1143 This will contain the address of a new recipient 1145 RFC2822.Received 1146 Actor: Mediating Source 1148 When re-sending a message, the submission agent may record a 1149 Received header field, to indicate the transition from original 1150 posting to resubmission. 1152 6.2.3 MUA Reply 1154 When a recipient formulates a response to a message, the new message 1155 is not typically viewed as being a "forwarding" of the original. 1157 6.2.4 MUA Gateways 1159 Gateways perform the basic routing and transfer work of message 1160 relaying, but they also make any message or address modifications 1161 that are needed to send the message into the next messaging 1162 environment. When a gateway connects two differing messaging 1163 services, its role is easy to identify and understand. When it 1164 connects environments that have technical similarity, but may have 1165 significant administrative differences, it is easy to think that a 1166 gateway is merely an MTA. The critical distinguish between an MTA 1167 and a gateway is that the latter modifies addresses and/or message 1168 content. 1170 A gateway may set any identity field available to a regular MUA. 1171 Identities typically set by gateways include: 1173 RFC2822.From 1175 Actor: Originator 1177 Names and email addresses for the original author(s) of the 1178 message content are retained. As for all original addressing 1179 information in the message, the gateway may translate addresses in 1180 whatever way will allow them continue to be useful in the target 1181 environment. 1183 RFC2822.Reply-To 1185 Actor: Originator 1187 The gateway should retain this information, if it is originally 1188 present. The ability to perform a successful reply by a gatewayed 1189 recipient is a typical test of gateway functionality. 1191 RFC2822.Sender 1193 Actor: Source 1195 This may retain the original value or may be set to a new address 1197 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1199 Actor: Recipient 1201 These usually retain their original addresses. 1203 RFC2821.MailFrom 1205 Actor: Source 1207 The agent responsible for gatewaying the message may choose to 1208 specify a new address to receive handling notices. 1210 RFC2822.Receive 1212 Actors - Source, Relay, Dest 1214 The gateway may record a Received header field, to indicate the 1215 transition from original posting to the new messaging environment. 1217 6.2.5 MUA Alias Handling 1219 A simple re-addressing facility that is available in most MDA 1220 implementations is called Aliasing. It is performed just before 1221 placing a message into the specified recipient's inbox. Instead, the 1222 message is submitted back to the transfer service, for delivery to 1223 one or more alternate addresses. Although implemented as part of the 1224 message delivery service, this facility is strictly a recipient user 1225 function. In effect it resubmits the message to a new address, on 1226 behalf of the listed recipient. 1228 What is most distinctive about this forwarding mechanism is how 1229 closely it compares to normal MTA store-and-forward. In reality its 1230 only interesting difference is that it changes the RFC2821.RCPT-TO 1231 value. Notably it does not typically change the RFC2821.Mailfrom 1233 An MDA that is re-posting a message to an alias typically changes 1234 only envelope information: 1236 RFC2822.TO, RFC2822.CC, RFC2822.BCC 1238 Actor: Recipient 1240 These retain their original addresses. 1242 RFC2821.Rcpt-To 1244 Actor: Recipient 1246 This field contains an alias address. 1248 RFC2821.MailFrom 1250 Actor: Mediating Source 1252 The agent responsible for submission to an alias address will 1253 usually retain the original address to receive handling 1254 notifications. The benefit of retaining the original MailFrom 1255 value is to ensure that the origination-side agent knows of that 1256 there has been a delivery problem. On the other hand, the 1257 responsibility for the problem usually lies with the recipient, 1258 since the Alias mechanism is strictly under the recipient's 1259 control. 1261 RFC2821.Received 1263 Actor: Mediating Recipient 1265 The agent should record Received information, to indicate the 1266 delivery to the original address and submission to the alias 1267 address. The trace of Received header fields should include 1268 everything from original posting through final delivery to the 1269 alias. 1271 6.2.6 MUA Mailing Lists 1273 Mailing lists have explicit email addresses and they forward messages 1274 to a list of subscribed members. Mailing list processing is a 1275 user-level activity, outside of the core email transfer service. The 1276 mailing list address is, therefore, associated with a distinct 1277 user-level entity that can perform arbitrary actions upon the 1278 original message, before submitting it to the mailing list 1279 membership. Hence, mailing lists are similar to gateways. 1281 Identities set by a mailing list processor, when submitting a 1282 message, include: 1284 RFC2919.List-id 1286 Actor: Mediating Originator 1288 This provides a global mailing list naming framework that is 1289 independent of particular hosts. Although [RFC2919] is a 1290 standards-track specification, it has not gained significant 1291 adoption. 1293 RFC2369.List-* 1295 Actor: Mediating Recipient 1297 [RFC2369] defines a collection of message header fields for use by 1298 mailing lists. In effect, they supply list-specific parameters 1299 for common mailing list user operations. The identifiers for 1300 these operations are for the list, itself, and the 1301 user-as-subscriber. 1303 RFC2822.From 1305 Actor: Originator 1307 Names and email addresses for the original author(s) of the 1308 message content are specified. 1310 RFC2822.Reply-To 1312 Actor: Originator 1314 Mailing lists have introduced an ambiguity for the Reply-To field. 1315 Some List operations choose to force all replies to go to all list 1316 members. They achieve this by placing the list address into the 1317 RFC2822.Reply-To field. Hence, direct, "private" replies only to 1318 the original author cannot be achieved by using the MUA's typical 1319 "reply to author" function. If the author created a Reply-To 1320 field, its information is lost. 1322 RFC2822.Sender 1324 Actor: Source 1326 This will usually specify the address of the agent responsible for 1327 mailing list operations. However, some mailing lists operate in a 1328 manner very similar to a simple MTA relay, so that they preserve 1329 as much of the original handling information as possible, 1330 including the original RFC2822.Sender field. 1332 RFC2822.TO, RFC2822.CC 1334 Actor: Mediating Recipient 1336 These will usually contain the original list of recipient 1337 addresses. 1339 RFC2821.MailFrom 1341 Actor: Mediating Source 1343 This may contain the original address to be notified of 1344 transmission issues, or the mailing list agent may set it to 1345 contain a new notification address. Typically, the value is set 1346 to a new address, so that mailing list members and posters are not 1347 burdened with transmission-related notifications. 1349 RFC2821.Rcpt-To 1351 Actor: Recipient 1353 This contains the address of a mailing list member. 1355 RFC2821.Received 1357 Actor: Mediating Recipient 1359 An Mailing List Agent should record a Received header field, to 1360 indicate the transition from original posting to mailing list 1361 forwarding. The Agent may choose to have the message retain the 1362 original set of Received header fields or may choose to remove 1363 them. In the latter case, it should ensure that the original 1364 Received header fields are otherwise available, to ensure later 1365 accountability and diagnostic access to it. 1367 7. Security Considerations 1369 This document does not specify any new Internet mail functionality. 1370 Consequently it should introduce no new security considerations. 1372 However its discussion of the roles and responsibilities for 1373 different mail service modules, and the information they create, 1374 highlights the considerable security considerations that must be 1375 present when implementing any component of the Internet mail service. 1377 8 References 1379 [ID-hdr-reg] 1380 "Registration of mail and MIME header fields", 1381 draft-klyne-hdrreg-mail-04.txt (work in progress), Apr 1382 2004. 1384 [ID-spamops] 1385 Hutzler, C., Crocker, D., Resnick, P., Sanderson, R. and 1386 E. Allman, "Email Submission Between Independent 1387 Networks", draft-spamops-00 (work in progress), March 1388 2004. 1390 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 1391 821, August 1982. 1393 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1394 text messages", STD 11, RFC 822, August 1982. 1396 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1397 STD 13, RFC 1034, November 1987. 1399 [RFC1035] Mockapetris, P., "Domain names - implementation and 1400 specification", STD 13, RFC 1035, November 1987. 1402 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1403 STD 53, RFC 1939, May 1996. 1405 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1406 October 1996. 1408 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1409 Extensions (MIME) Part One: Format of Internet Message 1410 Bodies", RFC 2045, November 1996. 1412 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1413 Extensions (MIME) Part Two: Media Types", RFC 2046, 1414 November 1996. 1416 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1417 Part Three: Message Header Extensions for Non-ASCII Text", 1418 RFC 2047, November 1996. 1420 [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 1421 Internet Mail Extensions (MIME) Part Four: Registration 1422 Procedures", BCP 13, RFC 2048, November 1996. 1424 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1425 Extensions (MIME) Part Five: Conformance Criteria and 1426 Examples", RFC 2049, November 1996. 1428 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1429 Specification", RFC 2181, July 1997. 1431 [RFC2298] Fajman, R., "An Extensible Message Format for Message 1432 Disposition Notifications", RFC 2298, March 1998. 1434 [RFC2304] Allocchio, C., "Minimal FAX address format in Internet 1435 Mail", RFC 2304, March 1998. 1437 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1438 for Core Mail List Commands and their Transport through 1439 Message Header Fields", RFC 2369, July 1998. 1441 [RFC2421] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 1442 Mail - version 2", RFC 2421, September 1998. 1444 [RFC2423] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME 1445 Sub-type Registration", RFC 2423, September 1998. 1447 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1449 [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 1450 2476, December 1998. 1452 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1453 Addresses", RFC 2465, August 1999. 1455 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1456 specifying the location of services (DNS SRV)", RFC 2782, 1457 February 2000. 1459 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1460 April 2001. 1462 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1463 2001. 1465 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1466 and Namespace for the Identification of Mailing Lists", 1467 RFC 2919, March 2001. 1469 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 1470 3028, January 2001. 1472 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1473 Extension for Delivery Status Notifications (DSNs)", RFC 1474 3461, January 2003. 1476 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1477 4rev1", RFC 3501, March 2003. 1479 Author's Address 1481 Dave Crocker 1482 Brandenburg InternetWorking 1483 675 Spruce Drive 1484 Sunnyvale, CA 94086 1485 USA 1487 Phone: +1.408.246.8253 1488 EMail: dcrocker@bbiw.net 1490 Appendix A. Acknowledgements 1492 The Email Architecture section derives from draft-hutzler-spamops 1493 [ID-spamops]. The text has been further elaborated. 1495 Discussion of the Source actor role was greatly clarified during 1496 discussions in the IETF's Marid working group. 1498 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1499 insight on the framework and details of early drafts. Additional 1500 review and suggestions were provided by Nathaniel Borenstein, Ed 1501 Bradford, Cyrus Daboo, Tony Finch, Ned Freed, Eric Hall, Bruce Lilly, 1502 Eric Hall, Chris Newman, Jochen Topf. 1504 Intellectual Property Statement 1506 The IETF takes no position regarding the validity or scope of any 1507 Intellectual Property Rights or other rights that might be claimed to 1508 pertain to the implementation or use of the technology described in 1509 this document or the extent to which any license under such rights 1510 might or might not be available; nor does it represent that it has 1511 made any independent effort to identify any such rights. Information 1512 on the procedures with respect to rights in RFC documents can be 1513 found in BCP 78 and BCP 79. 1515 Copies of IPR disclosures made to the IETF Secretariat and any 1516 assurances of licenses to be made available, or the result of an 1517 attempt made to obtain a general license or permission for the use of 1518 such proprietary rights by implementers or users of this 1519 specification can be obtained from the IETF on-line IPR repository at 1520 http://www.ietf.org/ipr. 1522 The IETF invites any interested party to bring to its attention any 1523 copyrights, patents or patent applications, or other proprietary 1524 rights that may cover technology that may be required to implement 1525 this standard. Please address the information to the IETF at 1526 ietf-ipr@ietf.org. 1528 Disclaimer of Validity 1530 This document and the information contained herein are provided on an 1531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1533 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1534 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1535 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1538 Copyright Statement 1540 Copyright (C) The Internet Society (2005). This document is subject 1541 to the rights, licenses and restrictions contained in BCP 78, and 1542 except as set forth therein, the authors retain all their rights. 1544 Acknowledgment 1546 Funding for the RFC Editor function is currently provided by the 1547 Internet Society.