idnits 2.17.00 (12 Aug 2021) /tmp/idnits60546/draft-crocker-email-arch-01.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1580. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1596), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (July 3, 2004) is 6530 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 1456, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 1479, but no explicit reference was found in the text == Unused Reference: 'RFC2298' is defined on line 1482, but no explicit reference was found in the text == Unused Reference: 'RFC2423' is defined on line 1495, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 1506, but no explicit reference was found in the text == Unused Reference: 'RFC3028' is defined on line 1520, but no explicit reference was found in the text == Unused Reference: 'RFC3461' is defined on line 1523, but no explicit reference was found in the text == Outdated reference: draft-klyne-hdrreg-mail has been published as RFC 4021 == Outdated reference: A later version (-03) exists of draft-ietf-marid-core-01 -- Possible downref: Normative reference to a draft: ref. 'ID-marid-core' -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 23 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MARID / SMTP D. Crocker 2 Internet-Draft Brandenburg InternetWorking 3 Expires: January 1, 2005 July 3, 2004 5 Internet Mail Architecture 6 draft-crocker-email-arch-01 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 1, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 Over its thirty year history, Internet mail has undergone significant 40 changes in scale and complexity. The first standardized architecture 41 for email specified a simple split between the user world and the 42 transmission world, in the form of Mail User Agents (MUA) and Mail 43 Transfer Agents (MTA). Over time each of these has divided into 44 multiple, specialized modules. Public discussion and agreement about 45 the nature of the changes to Internet mail has not kept pace, and 46 abuses of the Internet mail service have brought these issues into 47 stark relief. This draft offers clarifications and enhancements, to 48 provide a more consistent base for community discussion of email 49 service problems and proposed email service enhancements. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Service Overview . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2 Document Changes . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3 Discussion venue . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Email Actor Roles . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.2 Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 2.3 Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3. Email Identities . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1 Mailbox Addresses . . . . . . . . . . . . . . . . . . . . . . 8 63 3.2 Domain Names . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.3 Message Identifers . . . . . . . . . . . . . . . . . . . . . . 10 65 3.4 Identity Reference Convention . . . . . . . . . . . . . . . . 10 66 4. Email System Architecture . . . . . . . . . . . . . . . . . . 10 67 4.1 Architectural Components . . . . . . . . . . . . . . . . . . . 11 68 4.2 Operational Configuration . . . . . . . . . . . . . . . . . . 19 69 4.3 Layers of Identity References . . . . . . . . . . . . . . . . 20 70 5. Message Data . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 5.1 Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 5.2 Message Headers . . . . . . . . . . . . . . . . . . . . . . . 21 73 5.3 Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 6. Two Levels of Store-And-Forward . . . . . . . . . . . . . . . 21 75 6.1 MTA Relaying . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 6.2 MUA Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 22 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 34 80 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 81 Intellectual Property and Copyright Statements . . . . . . . . 35 83 1. Introduction 85 Over its thirty year history, Internet mail has undergone significant 86 changes in scale and complexity. The first standardized architecture 87 for email specified a simple split between the user world and the 88 transmission world, in the form of Mail User Agents (MUA) and Mail 89 Transfer Agents (MTA). Over time each of these has sub-divided into 90 more specialized modules. 92 The basic style and use of names, addresses and message structure 93 have remained remarkably constant. However each has benefited from 94 significant elaborations. Public discussion and agreement about the 95 nature of these changes has not kept pace, and abuses of the Internet 96 mail service have brought these issues into stark relief. 98 The current draft seeks to: 100 1. Document changes that have taken place in refining the email 101 model 103 2. Clarify functional roles for the architectural components 105 3. Clarify identity-related issues, across the email service 107 4. Provide a common venue for further defining and citing modern 108 Internet mail architecture 110 1.1 Service Overview 112 End-to-end Internet mail exchange is accomplished by using a 113 standardized infrastructure comprising: 115 1. An email object 117 2. Global addressing 119 3. A connected sequence of point-to-point transfer mechanisms 121 4. No prior arrangement between originator and recipient 123 5. No prior arrangement between point-to-point transfer services, 124 over the open Internet 126 The end-to-end portion of the service is the message. Broadly the 127 message, itself, is divided between handling control information and 128 user message payload. 130 A precept to the design of Internet mail is to permit 131 interoperability with no prior, direct administrative arrangement 132 between the participants. That is, all participants rely on having 133 the core services be universally supported, either directly or 134 through gateways that translate between Internet mail standards and 135 other email conventions. 137 For localized environments (edge networks) prior, administrative 138 arrangement can include access control, routing and lookup service 139 configuration. In recent years one change to local environments is 140 an increased requirement for authentication or, at least, 141 accountability. In these cases, the server performs explicit 142 validation of the client's identity. 144 1.2 Document Changes 146 The major changes from the previous version of this document are: 148 Actors: Addition of the User/Relay/Provider construct of actors. 149 Labeling of these roles has also been added to the tables showing 150 architectural function. The distinction of Actors, versus 151 architectural system components, is not typical for discussions of 152 email. Therefore it is likely that the construct needs 153 refinement. In particular, please review the table assignments. 155 MDA/MS/MUA: The construct of the Message Store has been added. This 156 change is intended to reflect the consensus view from online 157 discussion, rather than being the editor's view, which has in any 158 event changed... However it is likely that it will need 159 significant revision or replacement. Please review it carefully! 161 Message Identifiers: Discussion of message identifiers has been added 162 to the section on Email Identities. 164 1.3 Discussion venue 166 NOTE: This document is the work of a single person, about a topic 167 with considerable diversity of views. It is certain to be 168 incomplete and inaccurate. Some errors simply need to be 169 reported; they will get fixed. Others need to be discussed by the 170 community, because the real requirement is to develop common 171 community views. To this end, please treat the draft as a 172 touchstone for public discussion. 174 Discussion about this document should be directed to the: 176 177 mailing list. The is the 178 most active, long-standing venue for discussing email architecture. 179 Although this list is primarily for discussing only the SMTP 180 protocol, it is recommended that discussion of this draft take place 181 on that mailing list. This list tends to attend to end-to-end 182 infrastructure and architecture issues more than other email-related 183 mailing lists. 185 o The list also is pertinent 186 . However it's focus is 187 on the message, itself, so that transfer issues are typically 188 excluded. In addition, this list has not be very active recently. 190 o A currently active mailing list, likely to impact Internet mail 191 architecture, is . This list is 192 devoted to matters of spam control, so that underlying matters of 193 Internet mail architecture are probably best deferred to a more 194 general list, such as ietf-smtp. 196 o Also currently active is the , which is 197 considering enhancements for interaction between thin MUAs and 198 MSAs. 200 2. Email Actor Roles 202 Discussion of email architecture requires distinguishing different 203 actors within the service, and being clear about the job each 204 performs in the overall handling of mail. For this level of 205 discussion "the service" has the task of performing a single, 206 end-to-end transfer. Protracted, iterative exchanges, such as those 207 used for collaboration over time, are beyond the scope of (this 208 version of) this document. Actors often will be associated with 209 entirely independent organizations from other actors participating in 210 an end-to-end email transfer. 212 The following depicts the relationships among participants in 213 Internet Mail. Although related to a technical architecture, its 214 focus is on participant responsibilities, rather than functional 215 modules. Hence the labels used are different than for classic email 216 architecture. This figure depicts the relationships among the 217 actors. It shows the Submitter as distinct from the Originator, 218 although it is common for them to be the same actor. The figure also 219 shows multiple Relays in the sequence. It is legal to have only one, 220 and for intra-organization mail services, this is common. 222 User (Originator, Author) 223 | -+ 224 Submitter | Provider 225 | -+ 226 | -+ 227 Relay | 228 | | | Provider 229 | Relay | 230 | | -+ 231 | | -+ 232 | | -+ | 233 | User (Forwarder) | | 234 | [ Intermediate ] | |Provider 235 | [ Recipient ] | | 236 | [ Originator ] | Provider | 237 | [ Submitter ] | | 238 | | -+ | 239 | Relay | 240 | | -+ 241 | | -+ 242 Relay | 243 | | Provider 244 User (Recipient) | 245 -+ 247 2.1 User 249 Users are customers of the email relaying service. They represent 250 the sources and sinks of that service. 252 Three types of users are distinguished: 254 2.1.1 Originator 256 Also called "Author", this is a user-level participant responsible 257 for creating original content and requesting its transmission. The 258 email service operates to send and deliver mail among Originators and 259 Recipients. 261 2.1.2 Submitter 263 The Submitter is responsible for ensuring that a message is valid for 264 posting and then submitting it into the mail transfer service. It 265 primarily serves the Originator and often it is the same entity. 267 The Submitter has the responsibility for any additional 268 originator-related administrative tasks associated with message 269 transmission and delivery. Notably this pertains to error and 270 delivery notices. 272 It may be helpful to think of the Submitter as more like the editor 273 or publisher of a periodical, rather than simply the administrative 274 assistant for the Originator. Hence, the Submitter is best held 275 accountable for the message content, even when they did not create 276 any or most of it. 278 2.1.3 Recipient 280 The Recipient is a consumer of delivered content. The recipient is 281 specified as an addressee, in the envelope. 283 2.1.4 Forwarder 285 Email often transits intermediate, user-level points, called 286 Forwarders. The task of a Forwarder is to perform additional 287 processing, such as replacing one target address for one or more 288 others, and then submitting the message for further transmission. 289 Examples are recipient-controlled aliasing and, of course, mailing 290 list redistribution services. A Forwarder performs a natural 291 sequence of email steps: 293 o Service the mailbox specified in the envelope and accept arriving 294 messages. 296 o Reformulate message content and addressing, according to the 297 policies of the administrator of the Forwarder. Request (further) 298 message transmission. Note that an Intermediate Originator 299 operates with dual allegiance, notably its operating authority, 300 such as the mailing list administrator, as well as the "original" 301 originator. 303 o Perform the usual Submitter tasks. 305 2.2 Relay 307 A mail relay performs email transfer-service routing and 308 store-and-forward. It (re-)transmits the message on towards it 309 recipient(s). A basic transfer operation is between a client and a 310 server Relay. A set of Relays composes a mail handling service 311 network. This is above any underlying packet-switching network that 312 they might be using. 314 2.3 Provider 316 Providers operate component services. As shown in the Figure, it is 317 possible for Providers to host services for other Providers. Common 318 examples are: 320 Enterprise Service Providers: Operating an organization's internal 321 data and/or mail operations. 323 Internet Service Providers: Operating underlying data communication 324 services that, in turn, are used by one or more Relays and Users. 325 It is not their job to perform email functions, but to provide an 326 environment in which those functions can be performed. 328 Mail Service Providers: Operate email services, such as for 329 end-users, or mailing lists. 331 Operational pragmatics often dictate that Providers be involved in 332 detailed administration and enforcement issues, to help insure the 333 health of the overall Internet Mail service. 335 3. Email Identities 337 Internet mail uses two forms of identity. The most common is the 338 mailbox address [RFC2822]. The other form is the [RFC1034]. 341 3.1 Mailbox Addresses 343 An addr-spec has two distinct parts, divided by an at-sign ("@"). 344 The right-hand side contains a globally interpreted name for an 345 administrative domain. This domain name might refer to an entire 346 organization, or to a collection of machines integrated into a 347 homogeneous service, or to a single machine. Domain names are 348 defined and operated through the DNS [RFC1034], [RFC1035]. 350 The left-hand side of the at-sign contains a string that is globally 351 opaque and is called the . It is to be interpreted only 352 by the entity specified in the address's right-hand side. All other 353 entities must treat the local-part as a uninterpreted, literal string 354 and must preserve all of its original details. As such, its 355 distribution is equivalent to sending a "cookie" that is only 356 interpreted upon being returned to its originator. 358 3.1.1 Global Standards for Local-Part 360 It is common for sites to have local conventions for sub-structure to 361 the left-hand side of an addr-spec. This permits sub-addressing, 362 such as for distinguishing different discussion groups by the same 363 participant. However it must be stressed that these conventions are 364 strictly private to the user's organization and must not be 365 interpreted by any domain except the one listed in the right-hand 366 side of the add-spec. 368 A small class of addresses have an elaboration on basic email 369 addressing, with a standardized, global schema for the local-part. 370 These are conventions between originating end-systems and recipient 371 gateways, and they are invisible to the public email transfer 372 infrastructure. When an originator is explicitly sending via a 373 gateway out of the Internet, there are coding conventions for the 374 local-part, so that the originator can formulate instructions for the 375 gateway. Standardized examples of this are the telephone numbering 376 formats for VPIM [RFC2421], such as "+16137637582@vpim.example.com", 377 and iFax [RFC2304], such as "FAX=+12027653000/ 378 T33S=1387@ifax.example.com". 380 3.1.2 Scope of Email Address Use 382 Email addresses are being used far beyond their original email 383 transfer and delivery role. In practical terms, email strings have 384 become a common form of user identity on the Internet. What is 385 essential, then, is to be clear about the nature and role of an 386 identity string in a particular context and to be clear about the 387 entity responsible for setting that string. 389 3.2 Domain Names 391 A domain name is a global reference to an Internet resource, such as 392 a host, a service or a network. A name usually maps to one or more 393 IP Addresses. A domain name can be administered to refer to 394 individual users, but this is not common practice. The name is 395 structure as a hierarchical sequence of sub-names, separated by dots 396 ("."). 398 When not part of a mailbox address, a domain name is used in Internet 399 mail to refer to a node that took action upon the message, such as 400 providing the administrative scope for a message identifier, or 401 performing transfer processing. 403 3.3 Message Identifers 405 Message identifiers have two distinct parts, divided by an at-sign 406 ("@"). The right-hand side contains a globally interpreted name for 407 the administrative domain assigning the identifier. The left-hand 408 side of the at-sign contains a string that is globally opaque and 409 serves to uniquely identify the message within the domain referenced 410 on the right-hand side. The duration of uniqueness for the message 411 identifier is undefined. 413 The identifier may be assigned by the user or by any component of the 414 system along the path. Although Internet mail standards provide for 415 a single identifier, more than one is sometimes assigned. 417 3.4 Identity Reference Convention 419 In this document, fields references to identities are labeled in a 420 two-part, dotted notation. The first part cites the document 421 defining the identity and the second defines the name of the 422 identity. Hence, is the From field in an email 423 content header, and is the address in the SMTP 424 "Mail From" command. 426 4. Email System Architecture 428 NOTE: A discussion about any interesting system architecture is often 429 complicated by confusion between architecture versus 430 implementation. An architecture defines the conceptual functions 431 of a service, divided into discrete conceptual modules. An 432 implementation of that architecture may combine or separate 433 architectural components, as needed for a particular operational 434 environment. It is important not to confuse the engineering 435 decisions that are made to implement a product, with the 436 architectural abstractions used to define conceptual functions. 438 Modern Internet email architecture distinguishes four types of 439 components, arranged to support a store-and-forward service 440 architecture: 442 +-----------<-oMUA <-------------------------------+ 443 | | < smtp, | 444 (envelope) V submission | 445 RFC2822 MSA <-------------------------+ | 446 MIME | < smtp | | 447 | MTA dsn | 448 | | < smtp | | 449 | MTA ->----------------------->+ | 450 | | < smtp | 451 | . | 452 | . | 453 | . | 454 | V | 455 | MTA | 456 | | < local, smtp, lmtp | 457 | MDA <-------------------------+ | 458 | | | | | 459 | MS-1 | < local, | | 460 | | | | < pop, sieve | 461 | | | | < imap, | | 462 | | MS-2 < smtp, or | mdn 463 | | | < web | | 464 V | V | | 465 +---------> rMUA ->--------------------------+-----+ 467 Software implementations of these architectural components often 468 compress them, such as having the same software do MSA, MTA and MDA 469 functions. However the requirements for each of these components of 470 the architecture are becoming more extensive. So, their separation 471 is increasingly common. 473 4.1 Architectural Components 475 4.1.1 Mail User Agent (MUA) 477 An works on behalf of end-users and end-user applications. It 478 is their "representative" within the email service. 480 At the origination side of the service, the is used to create 481 a message and perform initial "submission" into the transfer 482 infrastructure, via an . It may also perform any creation- and 483 posting-time archival. An MUA outbox is part of the origination-side 484 MUA. 486 The recipient-side works on behalf of the end-user to process 487 received mail. This includes generating user-level return control 488 messages, display and disposition of the received message, and 489 closing or expanding the user communication loop, by initiating 490 replies and forwarding new messages. 492 An MUA may, itself, have a distributed architecture, such as 493 implementing a "thin" user interface module on a limited end-user 494 device, with the bulk of the MUA functionality operated remotely on a 495 more capable server. An example of such an architecture might use 496 IMAP [RFC3501] for most of the interactions between an MUA client and 497 an MUA server. 499 A special class of MUA functions perform message forwarding, as 500 discussed in the [2] section. 502 Identity fields set by the MUA include: 504 +----------------------+----------------------+---------------------+ 505 | Identity | Actor | Description | 506 +----------------------+----------------------+---------------------+ 507 | RFC2822.From | Originator | Names and addresses | 508 | | | for author(s) of | 509 | | | the message content | 510 | | | are listed in the | 511 | | | From header | 512 | RFC2822.Reply-To | Originator | If a message | 513 | | | recipient sends a | 514 | | | message that would | 515 | | | otherwise use the | 516 | | | RFC2822.From field | 517 | | | information in the | 518 | | | original message, | 519 | | | they are to use the | 520 | | | contents of the | 521 | | | RFC2822.Reply-To | 522 | | | field instead. In | 523 | | | other words, this | 524 | | | field is a direct | 525 | | | override of the | 526 | | | From field, for | 527 | | | responses from | 528 | | | recipients. | 529 | RFC2822.Sender | Submitter | This specifies the | 530 | | | address responsible | 531 | | | for submission into | 532 | | | the transfer | 533 | | | service. For | 534 | | | efficiency, this | 535 | | | field should be | 536 | | | omitted if it | 537 | | | contains the same | 538 | | | address as | 539 | | | RFC2822.From. | 540 | | | However this does | 541 | | | not mean there is | 542 | | | no Sender | 543 | | | specified. Rather, | 544 | | | it means that that | 545 | | | header is virtual | 546 | | | and that the | 547 | | | address in the From | 548 | | | field must be used. | 549 | | | Specification of | 550 | | | the error return | 551 | | | addresses (the | 552 | | | "bounces" address, | 553 | | | contained in | 554 | | | RFC2821.MailFrom) | 555 | | | is made by the | 556 | | | Sender. Typically | 557 | | | the bounce address | 558 | | | is the same as the | 559 | | | Sender address. | 560 | | | However some usage | 561 | | | scenarios require | 562 | | | it to be different. | 563 | RFC2822.To, | Recipient | These specify MUA | 564 | RFC2822.CC | | recipient | 565 | | | addresses. The | 566 | | | distinction between | 567 | | | To and CC is | 568 | | | subjective. | 569 | | | Generally, a To | 570 | | | addressee is | 571 | | | considered primary | 572 | | | and is expected to | 573 | | | take action on the | 574 | | | message. A CC | 575 | | | addressee typically | 576 | | | receives a copy | 577 | | | only for their | 578 | | | information. | 579 | RFC2822.BCC | Recipient | A message might be | 580 | | | copied to an | 581 | | | addressee who is | 582 | | | not to be disclosed | 583 | | | to the RFC2822.TO | 584 | | | or RFC2822.CC | 585 | | | recipients. The BCC | 586 | | | header indicates a | 587 | | | message copy to | 588 | | | such a recipient. | 589 | | | Typically, the | 590 | | | field lists no | 591 | | | addresses or only | 592 | | | lists the address | 593 | | | of the single | 594 | | | recipient receiving | 595 | | | the copy. This | 596 | | | ensures that even | 597 | | | other BCC | 598 | | | recipients do not | 599 | | | know of each other. | 600 | | | An MUA will | 601 | | | typically make | 602 | | | separate postings | 603 | | | for TO and CC | 604 | | | recipients, versus | 605 | | | BCC recipients. The | 606 | | | former will see no | 607 | | | indication that any | 608 | | | BCCs were sent, | 609 | | | whereas the latter | 610 | | | have a BCC field | 611 | | | present. It might | 612 | | | be empty, contain a | 613 | | | comment, or contain | 614 | | | one or more BCC | 615 | | | addresses, | 616 | | | depending upon the | 617 | | | preferences or the | 618 | | | Originator. | 619 +----------------------+----------------------+---------------------+ 621 Table 1: Message Identities 623 4.1.2 Mail Submission Agent (MSA) 625 An accepts the message submission from the oMUA and conditions 626 it for insertion into the global email transfer network, according to 627 the policies of the hosting network and the requirements of Internet 628 standards. It implements a server function to MUAs and a client 629 function to MTAs (or MDAs). 631 Examples of MSA-styled functions, in the world of paper mail, might 632 range across the very different capabilities of administrative 633 assistants, postal drop boxes, and post office front-counter 634 employees. 636 The MUA/MSA interface can be implemented within single host and use 637 private conventions for their interactions. Historically, 638 standards-based MUA/MSA interactions have used SMTP [RFC2821]. 639 However a recent alternative is SUBMISSION [RFC2476]. Although 640 SUBMISSION derives from SMTP, it operates on a separate TCP port, and 641 will typically impose distinct requirements, such as access 642 authorization. 644 Identities set by the MSA include: 646 +----------------------+----------------------+---------------------+ 647 | Identity | Actor | Description | 648 +----------------------+----------------------+---------------------+ 649 | RFC2821.HELO or | Submitter | The MSA may specify | 650 | RFC2821.EHLO | | its hosting domain | 651 | | | identity for the | 652 | | | SMTP HELO or EHLO | 653 | | | command operation. | 654 | RFC2821.MailFrom | Submitter | This is an | 655 | | | end-to-end string | 656 | | | that specifies an | 657 | | | email address for | 658 | | | receiving return | 659 | | | control | 660 | | | information, such | 661 | | | as "bounces". The | 662 | | | name of this field | 663 | | | is misleading, | 664 | | | because it is not | 665 | | | required to specify | 666 | | | either the author | 667 | | | or the agent | 668 | | | responsible for | 669 | | | submitting the | 670 | | | message. Rather, | 671 | | | the agent | 672 | | | responsible for | 673 | | | submission | 674 | | | specifies the | 675 | | | RFC2821.MailFrom | 676 | | | address. Ultimately | 677 | | | the simple basis | 678 | | | for deciding what | 679 | | | address needs to be | 680 | | | in the | 681 | | | RFC2821.MailFrom is | 682 | | | to determine what | 683 | | | address needs to be | 684 | | | informed about | 685 | | | transmission-level | 686 | | | problems (and, | 687 | | | possibly, | 688 | | | successes.) | 689 | RFC2821.Rcpt-To | Recipient | This specifies the | 690 | | | MUA inbox address | 691 | | | of a recipient. The | 692 | | | string might not be | 693 | | | visible in the | 694 | | | message content | 695 | | | headers. For | 696 | | | example, the | 697 | | | message destination | 698 | | | address headers, | 699 | | | such as RFC2822.To, | 700 | | | might specify a | 701 | | | mailing list | 702 | | | address, while the | 703 | | | RFC2821.Rcpt-To | 704 | | | address specifies a | 705 | | | member of that | 706 | | | list. | 707 | RFC2821.Received | Submitter | An MSA may record a | 708 | | | Received header, to | 709 | | | indicate initial | 710 | | | submission trace | 711 | | | information, | 712 | | | including | 713 | | | originating host | 714 | | | and MSA host domain | 715 | | | names and/or IP | 716 | | | Addresses. | 717 +----------------------+----------------------+---------------------+ 719 Table 2: MSA Identities 721 4.1.3 Mail Transfer Agent (MTA) 723 An relays a message to another other MTA or to an , in a 724 point-to-point exchange. Relaying is performed by a sequence of 725 MTAs, until the message reaches its destination MDA. Hence an MTA 726 implements both client and server MTA functionality. 728 The basic functionality of an MTA is similar to that of a packet 729 switch or IP router. That is, it does email store-and-forward email, 730 with a routing decision determining where the next-hop destination 731 shall be. The primary "routing" mechanism for Internet mail is the 732 DNS MX record [RFC1035]. As with most "link layer" mechanisms 733 Internet mail's SMTP supports a basic level of reliability, by virtue 734 of providing for retransmission after al transfer failure. However 735 the degree of persistence by an MTA can be highly variable. 737 However email objects are typically much larger than the payload of a 738 packet or datagram, and the end-to-end latencies are typically much 739 higher. Contrary to typical packet switches (and Instant Messaging 740 services) Internet mail MTAs typically store messages in a manner 741 that allows recovery across services interruptions, such as host 742 system shutdown. 744 Internet mail primarily uses SMTP [RFC2821], [RFC0821] to effect 745 point-to-point transfers between peer MTAs. Other transfer 746 mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645] 748 An important characteristic of MTA-MTA communications, over the open 749 Internet, is that they do not require prior arrangement between the 750 independent administrations operating the different MTAs. Given the 751 importance of spontaneity and serendipity in the world of human 752 communications, this lack of prearrangement, between the 753 participants, is a core benefit of Internet mail and remains a core 754 requirement for it. 756 Identities set by the MTA include: 758 +----------------------+----------------------+---------------------+ 759 | Identity | Actor | Description | 760 +----------------------+----------------------+---------------------+ 761 | RFC2821.HELO | Relay | The MTA may specify | 762 | | | its hosting domain | 763 | | | identity for the | 764 | | | SMTP HELO or EHLO | 765 | | | command operation. | 766 | RFC2821.Return-Path | Originator | The MDA records the | 767 | | | RFC2821.MailFrom | 768 | | | address into an | 769 | | | RFC2822 header | 770 | | | named Return-Path. | 771 | RFC2822.Received | Relay | An MTA must record | 772 | | | a Received header, | 773 | | | to indicate trace | 774 | | | information, | 775 | | | including source | 776 | | | host and receiving | 777 | | | host domain names | 778 | | | and/or IP | 779 | | | Addresses. | 780 +----------------------+----------------------+---------------------+ 782 Table 3: MTA Identities 784 4.1.4 Mail Delivery Agent (MDA) 786 The delivers email to the recipient's inbox. 788 An MDA can provide distinctive, address-based functionality, made 789 possible by its detailed knowledge of the properties of the 790 destination address. This knowledge might also be present earlier in 791 an MTA relaying sequence that ends with the MDA, such as at an 792 organizational gateway. However it is required for the MDA, if only 793 because the MDA must know where to store the message. This knowledge 794 is used to achieve differential handling of messages. 796 Using Internet protocols, delivery is effected with POP [RFC1939], 797 IMAP [RFC3501]. SMTP permits "push" delivery to the recipient 798 system, at the imitative of the upstream email service. POP is used 799 for "pull" delivery at the initiative of the recipient system. 800 Notably, SMTP and POP effect a transfer of message control from the 801 email service to the recipient host. In contrast, IMAP provides 802 on-going, interactive access to a message store, and does not effect 803 a transfer of message control to the end-user host. Instead, control 804 stays with the message store host that is being access by the user. 806 Identities set by the MDA include: 808 +----------------------+----------------------+---------------------+ 809 | Identity | Actor | Description | 810 +----------------------+----------------------+---------------------+ 811 | RFC2821.HELO or | Relay | The MDA may specify | 812 | RFC2821.EHLO | | its hosting domain | 813 | | | identity for the | 814 | | | SMTP HELO or EHLO | 815 | | | command operation. | 816 | RFC2822.Received | h | An MTA must record | 817 | | | a Received header, | 818 | | | to indicate trace | 819 | | | information, | 820 | | | including source | 821 | | | host and receiving | 822 | | | host domain names | 823 | | | and/or IP | 824 | | | Addresses. | 825 +----------------------+----------------------+---------------------+ 827 Table 4: MDA Identities 829 4.1.5 Message Store 831 An MUA's uses a long-term Message Store (MS). A rich set of choices 832 for the use of that store derives from permitting more than one to be 833 associated with a single user, demonstrated as MS-1 and MS-2 in the 834 Figure. MS-1 is shown as being remote from the MUA and MS-2 as being 835 local. Further the relationship between two message store may vary. 836 Between the MDA and the MUA, these choices are supported by a wide 837 variety of protocol options. 839 The operational relationship among two MSs can be: 841 Online: Only a remote MS is used, with messages being accessible only 842 when the MUA is attached to the MS, and the MUA repeatedly fetches 843 all or part of a message, from one session to the next. 845 Offline: The MS is local to the user, and messages are moved from any 846 remote store, rather than (also) being retained there. 848 Disconnected: A remote MS and a local MS synchronize all or parts of 849 their contents, while connected. The user may make changes while 850 disconnected, and the two stores are re-synchronized upon 851 reconnection. 853 4.2 Operational Configuration 855 Mail service components can be arranged into numerous organizational 856 structures, each with independent software and administration. One 857 common arrangement is to distinguish: 859 1. an open, core, global email transfer infrastructure 861 2. independent transfer services in networks at the edge of the core 863 3. end-user services 865 Edge networks may use proprietary email standards. However the 866 distinction between "public" network and edge network transfer 867 services is primarily significant because it highlights the need for 868 concern over interaction and protection between independent 869 administrations. In particular, this distinctions calls for 870 additional care in assessing transitions of responsibility, as well 871 as the accountability and authorization relationships among 872 participants in email transfer. 874 On the other hand, real-world operations of Internet mail 875 environments do impose boundaries such as access control at 876 organizational firewalls to the Internet. It should be noted that 877 the current Internet Mail architecture offers no special constructs 878 for these configuration choices. The current design of Internet mail 879 is for a seamless, end-to-end store-and-forward sequence. It is 880 possible that the architectural enhancement will not require new 881 protocols, but rather will require clarification of best practises, 882 as exemplified by a recent effort [ID-spamops] 884 4.3 Layers of Identity References 886 For a message in transit, the core identity fields combine into 888 +-----------------+--------------+-----------------------------+ 889 | Layer | Field | Set By | 890 +-----------------+--------------+-----------------------------+ 891 | Message Content | MIME Headers | Originator | 892 | Message Headers | From | Originator | 893 | | Sender | Submitter | 894 | | Reply-To | Originator | 895 | | To, CC, BCC | Originator | 896 | | Received | Submitter, Relay, Recipient | 897 | | Return-Path | MDA from MailFrom | 898 | SMTP | HELO | Latest Relay Client | 899 | | MailFrom | Submitter | 900 | | RCPT-TO | Submitter | 901 | IP | IP Address | Latest Relay Client | 902 +-----------------+--------------+-----------------------------+ 904 5. Message Data 906 5.1 Envelope 908 Information that is directly used or produced by the email transfer 909 service is called the "envelope". It controls and records handling 910 activities by the transfer service. Internet mail has a fragmented 911 framework for handling this "handling" information. The envelope 912 exists partly in the transfer protocol SMTP [RFC2821] and partly in 913 the message object [RFC2822]. 915 Direct envelope addressing information, as well as optional transfer 916 directives, are carried in-band by MTAs. All other envelope 917 information, such as trace records, is carried within the content 918 headers. Upon delivery, SMTP-level envelope information is typically 919 encoded within additional content headers, such as Return-Path and 920 Received (From and For). 922 5.2 Message Headers 924 Headers are attribute/value pairs covering an extensible range of 925 email service, user content and user transaction meta-information. 926 The core set of headers is defined in [RFC2822], [RFC0822]. It is 927 common to extend this set, for different applications. A complete 928 set of registered headers is being developed through [ID-hdr-reg]. 930 One danger with placing additional information in headers is that 931 gateways often alter or delete them. 933 5.3 Body 935 The body of a message might simply be lines of ASCII text or it might 936 be structured into a composition of multi-media, body-part 937 attachments, using MIME [RFC2045], [RFC2046], [RFC2047], [RFC2048], 938 and [RFC2049]. It should be noted that MIME structures each 939 body-part into a recursive set of MIME Header meta-data and MIME 940 Content sections. 942 6. Two Levels of Store-And-Forward 944 Basic email transfer is accomplished with an asynchronous 945 store-and-forward communication infrastructure. This means that 946 moving a message from an originator to a recipient involves a 947 sequence of independent transmissions through some number of 948 intermediaries, called MTAs. A very different task is the user-level 949 process of re-posting a message through a new submission process, 950 after final delivery for an earlier transfer sequence. Such 951 MUA-based re-posting shares some functionality with basic MTA 952 relaying, but it enjoys a degree of freedom with both addressing and 953 content that is not available to MTAs. 955 The primary "routing" mechanism for Internet mail is the DNS MX 956 record [RFC1035]. It is an advertisement, by a recipient domain, of 957 hosts that are able to relay mail to it, within the portion of the 958 Internet served by this instance of the DNS. 960 6.1 MTA Relaying 962 MTAs relay mail. They are like packet-switches and IP routers. 963 Their job is to make routing assessments and to move the message 964 payload data closer to the recipient. It is not their job to 965 reformulate the payload or to change addresses in the envelope or the 966 content. 968 6.2 MUA Forwarding 970 As discussed in section, forwarding is performed by MUAs 971 that take a received message and submit it back to the transfer 972 service, for delivery to one or more different addresses. A 973 forwarded message may appear identical to a relayed message, such as 974 for Alias forwarders, or it may have minimal similarity, as with a 975 Reply. 977 6.2.1 MUA Basic Forwarding 979 The simplest type of forwarding involves creating an entirely new 980 message, with new content, that includes the original message between 981 Originator-1 and Recipient-1. However this forwarded communication 982 is between Recipient-1 (who could also be called Originator-2) and a 983 new recipient, Recipient-2. The forwarded message is therefore 984 independent of the original message exchange and creates a new 985 message dialogue. 987 6.2.2 MUA Re-Sending 989 A recipient may wish to declare that an alternate addressee should 990 take on responsibility for a message, or otherwise become involved in 991 the original communication. They do this through a user-level 992 forwarding function, called re-sending. The act of re-sending, or 993 re-directing, splices a communication between Originator-1 and 994 Recipient-1, to become a communication between Originator-1 and new 995 Recipient-2. In this case, the content of the new message is the old 996 message, including preservation of the essential aspects of the 997 original message's origination information. 999 Identities specified in a resent message include 1001 +----------------------+----------------------+---------------------+ 1002 | Identity | Actor | Description | 1003 +----------------------+----------------------+---------------------+ 1004 | RFC2822.From | Originator | Names and email | 1005 | | | addresses for the | 1006 | | | original author(s) | 1007 | | | of the message | 1008 | | | content are | 1009 | | | retained. The | 1010 | | | free-form | 1011 | | | (display-name) | 1012 | | | portion of the | 1013 | | | address might be | 1014 | | | modified to provide | 1015 | | | informal reference | 1016 | | | to the agent | 1017 | | | responsible for the | 1018 | | | redirection. | 1019 | RFC2822.Reply-To | Originator | If this field is | 1020 | | | present in the | 1021 | | | original message, | 1022 | | | it should be | 1023 | | | retained in the | 1024 | | | Re-sent message. | 1025 | RFC2822.Sender | Submitter | This field is | 1026 | | | expected to contain | 1027 | | | the original Sender | 1028 | | | value. | 1029 | RFC2822.TO, | Recipient | These specify the | 1030 | RFC2822.CC, | | original message | 1031 | RFC2822.BCC | | recipients. | 1032 | RFC2822.Resent-From | Intermediate | The address of the | 1033 | | Originator | original recipient | 1034 | | | who is redirecting | 1035 | | | the message. | 1036 | | | Otherwise, the same | 1037 | | | rules apply for the | 1038 | | | Resent-From field | 1039 | | | as for an original | 1040 | | | RFC2822.From field | 1041 | RFC2822.Resent-Sende | Intermediate | The address of the | 1042 | r | Submitter | agent responsible | 1043 | | | for re-submitting | 1044 | | | the message. For | 1045 | | | efficiency, this | 1046 | | | field should be | 1047 | | | omitted if it | 1048 | | | contains the same | 1049 | | | address as | 1050 | | | RFC2822.Resent-From | 1051 | | | . However this does | 1052 | | | not mean there is | 1053 | | | no Resend-Sender | 1054 | | | specified. Rather, | 1055 | | | it means that that | 1056 | | | header is virtual | 1057 | | | and that the | 1058 | | | address in the | 1059 | | | Resent-From field | 1060 | | | must be used. | 1061 | | | Specification of | 1062 | | | the error return | 1063 | | | addresses (the | 1064 | | | "bounces" address, | 1065 | | | contained in | 1066 | | | RFC2821.MailFrom) | 1067 | | | is made by the | 1068 | | | Resent-Sender. | 1069 | | | Typically the | 1070 | | | bounce address is | 1071 | | | the same as the | 1072 | | | Resent-Sender | 1073 | | | address. However | 1074 | | | some usage | 1075 | | | scenarios require | 1076 | | | it to be different. | 1077 | RFC2822.Resent-To, | Recipient | The addresses of | 1078 | RFC2822.Resent-cc, | | the new recipients | 1079 | RFC2822.Resent-bcc | | who will now be | 1080 | | | able to reply to | 1081 | | | the original | 1082 | | | author. | 1083 | RFC2821.MailFrom | Intermediate | The agent | 1084 | | Submitter | responsible for | 1085 | | | re-submission | 1086 | | | (RFC2822.Resent-Sen | 1087 | | | der) is also | 1088 | | | responsible for | 1089 | | | specifying the new | 1090 | | | RFC2821.MailFrom | 1091 | | | address. | 1092 | RFC2821.Rcpt-to | Recipient | This will contain | 1093 | | | the address of a | 1094 | | | new recipient | 1095 | RFC2822.Received | Intermediate | When re-sending a | 1096 | | Submitter | message, the | 1097 | | | submission agent | 1098 | | | may record a | 1099 | | | Received header, to | 1100 | | | indicate the | 1101 | | | transition from | 1102 | | | original posting to | 1103 | | | resubmission. | 1104 +----------------------+----------------------+---------------------+ 1106 Table 6: ReSent Identities 1108 6.2.3 MUA Reply 1110 When a recipient formulates a response to a message, the new message 1111 is not typically viewed as being a "forwarding" of the original. 1113 6.2.4 MUA Gateways 1115 Gateways perform the basic routing and transfer work of message 1116 relaying, but they also make any message or address modifications 1117 that are needed to send the message into the next messaging 1118 environment. When a gateway connects two differing messaging 1119 services, its role is easy to identify and understand. When it 1120 connects environments that have technical similarity, but may have 1121 significant administrative differences, it is easy to think that a 1122 gateway is merely an MTA. The critical distinguish between an MTA 1123 and a gateway is that the latter modifies addresses and/or message 1124 content. 1126 A gateway may set any identity field available to a regular MUA. 1127 Identities typically set by gateways include 1129 +----------------------+----------------------+---------------------+ 1130 | Identity | Actor | Description | 1131 +----------------------+----------------------+---------------------+ 1132 | RFC2822.From | Originator | Names and email | 1133 | | | addresses for the | 1134 | | | original author(s) | 1135 | | | of the message | 1136 | | | content are | 1137 | | | retained. As for | 1138 | | | all original | 1139 | | | addressing | 1140 | | | information in the | 1141 | | | message, the | 1142 | | | gateway may | 1143 | | | translate addresses | 1144 | | | in whatever way | 1145 | | | will allow them | 1146 | | | continue to be | 1147 | | | useful in the | 1148 | | | target environment. | 1149 | RFC2822.Reply-To | Originator | The gateway should | 1150 | | | retain this | 1151 | | | information, if it | 1152 | | | is originally | 1153 | | | present. The | 1154 | | | ability to perform | 1155 | | | a successful reply | 1156 | | | by a gatewayed | 1157 | | | recipient is a | 1158 | | | typical test of | 1159 | | | gateway | 1160 | | | functionality. | 1161 | RFC2822.Sender | Submitter | This may retain the | 1162 | | | original value or | 1163 | | | may be set to a new | 1164 | | | address | 1165 | RFC2822.TO, | Recipient | These usually | 1166 | RFC2822.CC, | | retain their | 1167 | RFC2822.BCC | | original addresses. | 1168 | RFC2821.MailFrom | Submitter | The agent | 1169 | | | responsible for | 1170 | | | gatewaying the | 1171 | | | message may choose | 1172 | | | to specify a new | 1173 | | | address to receive | 1174 | | | handling notices. | 1175 | RFC2822.Received | Forwarder | The gateway may | 1176 | | | record a Received | 1177 | | | header, to indicate | 1178 | | | the transition from | 1179 | | | original posting to | 1180 | | | the new messaging | 1181 | | | environment. | 1182 +----------------------+----------------------+---------------------+ 1184 Table 7: Gateway Identities 1186 6.2.5 MUA Alias Handling 1188 A simple re-addressing facility that is available in most MDA 1189 implementations is called Aliasing. It is performed just before 1190 placing a message into the specified recipient's inbox. Instead, the 1191 message is submitted back to the transfer service, for delivery to 1192 one or more alternate addresses. Although implemented as part of the 1193 message delivery service, this facility is strictly a recipient user 1194 function. In effect it resubmits the message to a new address, on 1195 behalf of the listed recipient. 1197 What is most distinctive about this forwarding mechanism is how 1198 closely it compares to normal MTA store-and-forward. In reality its 1199 only interesting difference is that it changes the RFC2821.RCPT-TO 1200 value. Notably it does not typically change the RFC2821.Mailfrom 1202 An MDA that is re-posting a message to an alias typically changes 1203 only envelope information: 1205 +----------------------+----------------------+---------------------+ 1206 | Identity | Actor | Description | 1207 +----------------------+----------------------+---------------------+ 1208 | RFC2822.TO, | Recipient | These retain their | 1209 | RFC2822.CC, | | original addresses. | 1210 | RFC2822.BCC | | | 1211 | RFC2821.Rcpt-To | Recipient | This field contains | 1212 | | | an alias address. | 1213 | RFC2821.MailFrom | Intermediate | The agent | 1214 | | Submitter | responsible for | 1215 | | | submission to an | 1216 | | | alias address will | 1217 | | | usually retain the | 1218 | | | original address to | 1219 | | | receive handling | 1220 | | | notifications. The | 1221 | | | benefit of | 1222 | | | retaining the | 1223 | | | original MailFrom | 1224 | | | value is to ensure | 1225 | | | that the | 1226 | | | origination-side | 1227 | | | agent knows of that | 1228 | | | there has been a | 1229 | | | delivery problem. | 1230 | | | On the other hand, | 1231 | | | the responsibility | 1232 | | | for the problem | 1233 | | | usually lies with | 1234 | | | the recipient, | 1235 | | | since the Alias | 1236 | | | mechanism is | 1237 | | | strictly under the | 1238 | | | recipient's | 1239 | | | control. | 1240 | RFC2821.Received | Intermediate | The agent should | 1241 | | Recipient | record Received | 1242 | | | information, to | 1243 | | | indicate the | 1244 | | | delivery to the | 1245 | | | original address | 1246 | | | and submission to | 1247 | | | the alias address. | 1248 | | | The trace of | 1249 | | | Received headers | 1250 | | | should include | 1251 | | | everything from | 1252 | | | original posting | 1253 | | | through final | 1254 | | | delivery to the | 1255 | | | alias. | 1256 +----------------------+----------------------+---------------------+ 1258 Table 8: Alias Identities 1260 6.2.6 MUA Mailing Lists 1262 Mailing lists have explicit email addresses and forward messages to a 1263 list of subscribed members. Mailing list processing is a user-level 1264 activity, outside of the core email transfer service. The mailing 1265 list address is, therefore, associated with a distinct user-level 1266 entity that can perform arbitrary actions upon the original message, 1267 before submitting it to the mailing list membership. Hence, mailing 1268 lists are similar to gateways. 1270 Identities set by a mailing list processor, when submitting a 1271 message, include: 1273 +----------------------+----------------------+---------------------+ 1274 | Identity | Actor | Description | 1275 +----------------------+----------------------+---------------------+ 1276 | RFC2919.List-id | -- | This provides a | 1277 | | | global mailing list | 1278 | | | naming framework | 1279 | | | that is independent | 1280 | | | of particular | 1281 | | | hosts. Although | 1282 | | | [RFC2919] is a | 1283 | | | standards-track | 1284 | | | specification, it | 1285 | | | has not gained | 1286 | | | significant | 1287 | | | adoption. | 1288 | RFC2369.List-* | Recipient | [RFC2369] defines a | 1289 | | | collection of | 1290 | | | message headers for | 1291 | | | use by mailing | 1292 | | | lists. In effect, | 1293 | | | they supply | 1294 | | | list-specific | 1295 | | | parameters for | 1296 | | | common mailing list | 1297 | | | user operations. | 1298 | | | The identifiers for | 1299 | | | these operations | 1300 | | | are for the list, | 1301 | | | itself, and the | 1302 | | | user-as-subscriber. | 1303 | | | | 1304 | RFC2822.From | Originator | Names and email | 1305 | | | addresses for the | 1306 | | | original author(s) | 1307 | | | of the message | 1308 | | | content are | 1309 | | | specified. | 1310 | RFC2822.Reply-To | Originator | Mailing lists have | 1311 | | | introduced an | 1312 | | | ambiguity for the | 1313 | | | Reply-To field. | 1314 | | | Some List | 1315 | | | operations choose | 1316 | | | to force all | 1317 | | | replies to go to | 1318 | | | all list members. | 1319 | | | They achieve this | 1320 | | | by placing the list | 1321 | | | address into the | 1322 | | | RFC2822.Reply-To | 1323 | | | field. Hence, | 1324 | | | direct, "private" | 1325 | | | replies only to the | 1326 | | | original author | 1327 | | | cannot be achieved | 1328 | | | by using the MUA's | 1329 | | | typical "reply to | 1330 | | | author" function. | 1331 | | | If the author | 1332 | | | created a Reply-To | 1333 | | | field, its | 1334 | | | information is | 1335 | | | lost. | 1336 | RFC2822.Sender | Submitter | This will usually | 1337 | | | specify the address | 1338 | | | of the agent | 1339 | | | responsible for | 1340 | | | mailing list | 1341 | | | operations. | 1342 | | | However, some | 1343 | | | mailing lists | 1344 | | | operate in a manner | 1345 | | | very similar to a | 1346 | | | simple MTA relay, | 1347 | | | so that they | 1348 | | | preserve as much of | 1349 | | | the original | 1350 | | | handling | 1351 | | | information as | 1352 | | | possible, including | 1353 | | | the original | 1354 | | | RFC2822.Sender | 1355 | | | field. | 1356 | RFC2822.TO, | Intermediate | These will usually | 1357 | RFC2822.CC | Recipient | contain the | 1358 | | | original list of | 1359 | | | recipient | 1360 | | | addresses. | 1361 | RFC2821.MailFrom | Intermediate | This may contain | 1362 | | Submitter | the original | 1363 | | | address to be | 1364 | | | notified of | 1365 | | | transmission | 1366 | | | issues, or the | 1367 | | | mailing list agent | 1368 | | | may set it to | 1369 | | | contain a new | 1370 | | | notification | 1371 | | | address. Typically, | 1372 | | | the value is set to | 1373 | | | a new address, so | 1374 | | | that mailing list | 1375 | | | members and posters | 1376 | | | are not burdened | 1377 | | | with | 1378 | | | transmission-relate | 1379 | | | d notifications. | 1380 | RFC2821.Rcpt-To | Recipient | This contain the | 1381 | | | address of a | 1382 | | | mailing list | 1383 | | | member. | 1384 | RFC2821.Received | Intermediate | An Mailing List | 1385 | | Recipient | Agent should record | 1386 | | | a Received header, | 1387 | | | to indicate the | 1388 | | | transition from | 1389 | | | original posting to | 1390 | | | mailing list | 1391 | | | forwarding. The | 1392 | | | Agent may choose to | 1393 | | | have the message | 1394 | | | retain the original | 1395 | | | set of Received | 1396 | | | headers or may | 1397 | | | choose to remove | 1398 | | | them. In the latter | 1399 | | | case, it should | 1400 | | | ensure that the | 1401 | | | original Received | 1402 | | | headers are | 1403 | | | otherwise | 1404 | | | available, to | 1405 | | | ensure later | 1406 | | | accountability and | 1407 | | | diagnostic access | 1408 | | | to it. | 1409 +----------------------+----------------------+---------------------+ 1411 Table 9: Mailing List Identities 1413 7. Security Considerations 1415 This document does not specify any new Internet mail functionality. 1416 Consequently it should introduce no new security considerations. 1418 However its discussion of the roles and responsibilities for 1419 different mail service modules, and the information they create, 1420 highlights the considerable security considerations that must be 1421 present when implementing any component of the Internet mail service. 1423 8 References 1425 [ID-hdr-reg] 1426 "Registration of mail and MIME header fields", 1427 draft-klyne-hdrreg-mail-04.txt (work in progress), Apr 1428 2004. 1430 [ID-marid-core] 1431 Lyon, J. and M. Wong, "MTA Authentication Records in DNS", 1432 draft-ietf-marid-core-01.txt (work in progress), June 1433 2004. 1435 [ID-spamops] 1436 Hutzler, C., Crocker, D., Resnick, P., Sanderson, R. and 1437 E. Allman, "Email Submission Between Independent 1438 Networks", draft-spamops-00 (work in progress), March 1439 2004. 1441 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 1442 821, August 1982. 1444 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1445 text messages", STD 11, RFC 822, August 1982. 1447 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1448 STD 13, RFC 1034, November 1987. 1450 [RFC1035] Mockapetris, P., "Domain names - implementation and 1451 specification", STD 13, RFC 1035, November 1987. 1453 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1454 STD 53, RFC 1939, May 1996. 1456 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 1457 October 1996. 1459 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1460 Extensions (MIME) Part One: Format of Internet Message 1461 Bodies", RFC 2045, November 1996. 1463 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1464 Extensions (MIME) Part Two: Media Types", RFC 2046, 1465 November 1996. 1467 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1468 Part Three: Message Header Extensions for Non-ASCII Text", 1469 RFC 2047, November 1996. 1471 [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 1472 Internet Mail Extensions (MIME) Part Four: Registration 1473 Procedures", BCP 13, RFC 2048, November 1996. 1475 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1476 Extensions (MIME) Part Five: Conformance Criteria and 1477 Examples", RFC 2049, November 1996. 1479 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1480 Specification", RFC 2181, July 1997. 1482 [RFC2298] Fajman, R., "An Extensible Message Format for Message 1483 Disposition Notifications", RFC 2298, March 1998. 1485 [RFC2304] Allocchio, C., "Minimal FAX address format in Internet 1486 Mail", RFC 2304, March 1998. 1488 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1489 for Core Mail List Commands and their Transport through 1490 Message Header Fields", RFC 2369, July 1998. 1492 [RFC2421] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet 1493 Mail - version 2", RFC 2421, September 1998. 1495 [RFC2423] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME 1496 Sub-type Registration", RFC 2423, September 1998. 1498 [RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998. 1500 [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 1501 2476, December 1998. 1503 [RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP 1504 Addresses", RFC 2465, August 1999. 1506 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1507 specifying the location of services (DNS SRV)", RFC 2782, 1508 February 2000. 1510 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1511 April 2001. 1513 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1514 2001. 1516 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1517 and Namespace for the Identification of Mailing Lists", 1518 RFC 2919, March 2001. 1520 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 1521 3028, January 2001. 1523 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1524 Extension for Delivery Status Notifications (DSNs)", RFC 1525 3461, January 2003. 1527 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 1528 4rev1", RFC 3501, March 2003. 1530 [2] 1532 Author's Address 1534 Dave Crocker 1535 Brandenburg InternetWorking 1536 675 Spruce Drive 1537 Sunnyvale, CA 94086 1538 USA 1540 Phone: +1.408.246.8253 1541 EMail: dcrocker@brandenburg.com 1543 Appendix A. Acknowledgements 1545 The Email Architecture section derives from draft-hutzler-spamops 1546 [ID-spamops]. The text has been further elaborated. 1548 Discussion of the Submitter actor role was greatly clarified by 1549 [ID-marid-core]. Reference to this role has been written to align 1550 with that document's label and discussion. 1552 Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful 1553 insight on the framework and details of early drafts. Additional 1554 review and suggestions have been provided by Nathaniel Borenstein, 1555 Chris Newman, Eric Hall, Tony Finch, Ed Bradford, Cyrus Daboo, Ned 1556 Freed. 1558 Intellectual Property Statement 1560 The IETF takes no position regarding the validity or scope of any 1561 Intellectual Property Rights or other rights that might be claimed to 1562 pertain to the implementation or use of the technology described in 1563 this document or the extent to which any license under such rights 1564 might or might not be available; nor does it represent that it has 1565 made any independent effort to identify any such rights. Information 1566 on the procedures with respect to rights in RFC documents can be 1567 found in BCP 78 and BCP 79. 1569 Copies of IPR disclosures made to the IETF Secretariat and any 1570 assurances of licenses to be made available, or the result of an 1571 attempt made to obtain a general license or permission for the use of 1572 such proprietary rights by implementers or users of this 1573 specification can be obtained from the IETF on-line IPR repository at 1574 http://www.ietf.org/ipr. 1576 The IETF invites any interested party to bring to its attention any 1577 copyrights, patents or patent applications, or other proprietary 1578 rights that may cover technology that may be required to implement 1579 this standard. Please address the information to the IETF at 1580 ietf-ipr@ietf.org. 1582 Disclaimer of Validity 1584 This document and the information contained herein are provided on an 1585 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1586 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1587 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1588 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1589 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1590 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1592 Copyright Statement 1594 Copyright (C) The Internet Society (2004). This document is subject 1595 to the rights, licenses and restrictions contained in BCP 78, and 1596 except as set forth therein, the authors retain all their rights. 1598 Acknowledgment 1600 Funding for the RFC Editor function is currently provided by the 1601 Internet Society.