| < draft-crocker-email-arch-13.txt | draft-crocker-email-arch-14.txt > | |||
|---|---|---|---|---|
| SMTP D. Crocker | SMTP D. Crocker | |||
| Internet-Draft Brandenburg InternetWorking | Internet-Draft Brandenburg InternetWorking | |||
| Intended status: Standards Track May 15, 2009 | Intended status: Informational June 8, 2009 | |||
| Expires: November 16, 2009 | Expires: December 10, 2009 | |||
| Internet Mail Architecture | Internet Mail Architecture | |||
| draft-crocker-email-arch-13 | draft-crocker-email-arch-14 | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. This document may contain material | provisions of BCP 78 and BCP 79. This document may contain material | |||
| from IETF Documents or IETF Contributions published or made publicly | from IETF Documents or IETF Contributions published or made publicly | |||
| available before November 10, 2008. The person(s) controlling the | available before November 10, 2008. The person(s) controlling the | |||
| copyright in some of this material may not have granted the IETF | copyright in some of this material may not have granted the IETF | |||
| Trust the right to allow modifications of such material outside the | Trust the right to allow modifications of such material outside the | |||
| IETF Standards Process. Without obtaining an adequate license from | IETF Standards Process. Without obtaining an adequate license from | |||
| skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on November 16, 2009. | This Internet-Draft will expire on December 10, 2009. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents in effect on the date of | |||
| publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. | and restrictions with respect to this document. | |||
| Abstract | Abstract | |||
| Over its thirty-five year history, Internet Mail has changed | Over its thirty-five year history, Internet Mail has changed | |||
| significantly in scale and complexity, as it has become a global | significantly in scale and complexity, as it has become a global | |||
| infrastructure service. These changes have been evolutionary, rather | infrastructure service. These changes have been evolutionary, rather | |||
| than revolutionary, reflecting a strong desire to preserve both its | than revolutionary, reflecting a strong desire to preserve both its | |||
| installed base and its usefulness. To collaborate productively on | installed base and its usefulness. To collaborate productively on | |||
| this large and complex system, all participants must work from a | this large and complex system, all participants need to work from a | |||
| common view of it and use a common language to describe its | common view of it and use a common language to describe its | |||
| components and the interactions among them. But the many differences | components and the interactions among them. But the many differences | |||
| in perspective currently make it difficult to know exactly what | in perspective currently make it difficult to know exactly what | |||
| another participant means. To serve as the necessary common frame of | another participant means. To serve as the necessary common frame of | |||
| reference, this document describes the enhanced Internet Mail | reference, this document describes the enhanced Internet Mail | |||
| architecture, reflecting the current service. | architecture, reflecting the current service. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 1.2. The Role of This Architecture . . . . . . . . . . . . . . 7 | 1.2. The Role of This Architecture . . . . . . . . . . . . . . 7 | |||
| 1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 8 | 1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 8 | |||
| 2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 9 | 2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 8 | |||
| 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 9 | 2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 2.2. Message Handling Service (MHS) Actors . . . . . . . . . . 12 | 2.2. Message Handling Service (MHS) Actors . . . . . . . . . . 12 | |||
| 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 15 | 2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 15 | |||
| 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 3.2. Scope of Email Address Use . . . . . . . . . . . . . . . . 19 | 3.2. Scope of Email Address Use . . . . . . . . . . . . . . . . 19 | |||
| 3.3. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 20 | 3.3. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 3.4. Message Identifier . . . . . . . . . . . . . . . . . . . . 20 | 3.4. Message Identifier . . . . . . . . . . . . . . . . . . . . 20 | |||
| 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 22 | 4. Services and Standards . . . . . . . . . . . . . . . . . . . . 22 | |||
| 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 25 | 4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| skipping to change at page 4, line 34 ¶ | skipping to change at page 4, line 34 ¶ | |||
| [RFC5322] defines a message object. | [RFC5322] defines a message object. | |||
| * Multipurpose Internet Mail Extensions (MIME) [RFC2045] defines | * Multipurpose Internet Mail Extensions (MIME) [RFC2045] defines | |||
| an enhancement to the message object that permits using multi- | an enhancement to the message object that permits using multi- | |||
| media attachments. | media attachments. | |||
| Public collaboration on technical, operations, and policy activities | Public collaboration on technical, operations, and policy activities | |||
| of email, including those that respond to the challenges of email | of email, including those that respond to the challenges of email | |||
| abuse, has brought a much wider range of participants into the | abuse, has brought a much wider range of participants into the | |||
| technical community. To collaborate productively on this large and | technical community. To collaborate productively on this large and | |||
| complex system, all participants must work from a common view of it | complex system, all participants need to work from a common view of | |||
| and use a common language to describe its components and the | it and use a common language to describe its components and the | |||
| interactions among them. But the many differences in perspective | interactions among them. But the many differences in perspective | |||
| currently make it difficult to know exactly what another participant | currently make it difficult to know exactly what another participant | |||
| means. | means. | |||
| It is the need to resolve these differences that motivates this | It is the need to resolve these differences that motivates this | |||
| document, which describes the realities of the current system. | document, which describes the realities of the current system. | |||
| Internet Mail is the subject of ongoing technical, operations, and | Internet Mail is the subject of ongoing technical, operations, and | |||
| policy work, and the discussions often are hindered by different | policy work, and the discussions often are hindered by different | |||
| models of email service design and different meanings for the same | models of email service design and different meanings for the same | |||
| terms. | terms. | |||
| skipping to change at page 5, line 46 ¶ | skipping to change at page 5, line 46 ¶ | |||
| transfer components and services. | transfer components and services. | |||
| For Internet Mail, the term "end-to-end" usually refers to a single | For Internet Mail, the term "end-to-end" usually refers to a single | |||
| posting and the set of deliveries that result from a single transit | posting and the set of deliveries that result from a single transit | |||
| of the MHS. A common exception is group dialogue that is mediated, | of the MHS. A common exception is group dialogue that is mediated, | |||
| through a Mailing List; in this case, two postings occur before | through a Mailing List; in this case, two postings occur before | |||
| intended Recipients receive an Author's message, as discussed in | intended Recipients receive an Author's message, as discussed in | |||
| Section 2.1.4. In fact, some uses of email consider the entire email | Section 2.1.4. In fact, some uses of email consider the entire email | |||
| service, including Author and Recipient, as a subordinate component. | service, including Author and Recipient, as a subordinate component. | |||
| For these services, "end-to-end" refers to points outside the email | For these services, "end-to-end" refers to points outside the email | |||
| service. Examples are voicemail over email "[RFC3801], EDI over | service. Examples are voicemail over email [RFC3801], EDI over email | |||
| email [RFC1767] and facsimile over email [RFC4142]. | [RFC1767] and facsimile over email [RFC4142]. | |||
| +--------+ | +--------+ | |||
| ++================>| User | | ++================>| User | | |||
| || +--------+ | || +--------+ | |||
| || ^ | || ^ | |||
| +--------+ || +--------+ . | +--------+ || +--------+ . | |||
| | User +==++=========>| User | . | | User +==++=========>| User | . | |||
| +---+----+ || +--------+ . | +---+----+ || +--------+ . | |||
| . || ^ . | . || ^ . | |||
| . || +--------+ . . | . || +--------+ . . | |||
| . ++==>| User | . . | . ++==>| User | . . | |||
| . +--------+ . . | . +--------+ . . | |||
| . ^ . . | . ^ . . | |||
| . . . . | . . . . | |||
| V . . . | V . . . | |||
| +---+-----------------+------+------+---+ | +---+-----------------+------+------+---+ | |||
| | . . . . | | | . . . . | | |||
| | .................>. . . | | | .................>. . . | | |||
| | . . . | | | . . . | | |||
| | ........................>. . | | | ........................>. . | | |||
| | . . | | | . . | | |||
| | ...............................>. | | | ...............................>. | | |||
| | | | | | | |||
| | Message Handling Service (MHS) | | | Message Handling Service (MHS) | | |||
| +---------------------------------------+ | +---------------------------------------+ | |||
| Legend: == lines indicate primary (possibly indirect) transfers or roles | Legend: === lines indicate primary (possibly indirect) | |||
| ... lines indicate supporting transfers or roles | transfers or roles | |||
| ... lines indicate supporting transfers or roles | ||||
| Figure 1: Basic Internet Mail Service Model | Figure 1: Basic Internet Mail Service Model | |||
| End-to-end Internet Mail exchange is accomplished by using a | End-to-end Internet Mail exchange is accomplished by using a | |||
| standardized infrastructure with these components and | standardized infrastructure with these components and | |||
| characteristics: | characteristics: | |||
| * An email object | * An email object | |||
| * Global addressing | * Global addressing | |||
| * An asynchronous sequence of point-to-point transfer mechanisms | * An asynchronous sequence of point-to-point transfer mechanisms | |||
| * No prior arrangement between MTAs or between Authors and | * No requirement for prior arrangement between MTAs or between | |||
| Recipients | Authors and Recipients | |||
| * No prior arrangement between point-to-point transfer services | * No requirement for prior arrangement between point-to-point | |||
| over the open Internet | transfer services over the open Internet | |||
| * No requirement for Author, Originator, or Recipients to be | * No requirement for Author, Originator, or Recipients to be | |||
| online at the same time | online at the same time | |||
| The end-to-end portion of the service is the email object, called a | The end-to-end portion of the service is the email object, called a | |||
| "message." Broadly, the message itself distinguishes control | "message." Broadly, the message itself distinguishes control | |||
| information, for handling, from the Author's content. | information, for handling, from the Author's content. | |||
| A precept to the design of mail over the open Internet is permitting | A precept to the design of mail over the open Internet is permitting | |||
| user-to-user and MTA-to-MTA interoperability without prior, direct | user-to-user and MTA-to-MTA interoperability without prior, direct | |||
| skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 5 ¶ | |||
| protocol defines how particular capabilities are performed. | protocol defines how particular capabilities are performed. | |||
| As such, an architecture will more formally describe a service at a | As such, an architecture will more formally describe a service at a | |||
| relatively high level. A protocol which implements some portion of a | relatively high level. A protocol which implements some portion of a | |||
| service will conform to the architecture to a greater or lesser | service will conform to the architecture to a greater or lesser | |||
| extent, depending on the pragmatic tradeoffs they make when trying to | extent, depending on the pragmatic tradeoffs they make when trying to | |||
| implement the architecture in the context of real-world constraints. | implement the architecture in the context of real-world constraints. | |||
| Failure to precisely follow an architecture is not a failure of the | Failure to precisely follow an architecture is not a failure of the | |||
| protocol, nor is failure to precisely cast a protocol a failure of | protocol, nor is failure to precisely cast a protocol a failure of | |||
| the architecture. Where a protocol varies from the architecture, it | the architecture. Where a protocol varies from the architecture, it | |||
| should of course explain the reason for the variance. However, such | will of course be appropriate for it to explain the reason for the | |||
| variance is not a mark against a protocol: Happily, the IETF prefers | variance. However, such variance is not a mark against a protocol: | |||
| running code to architectural purity. | Happily, the IETF prefers running code to architectural purity. | |||
| In this particular case, this architecture attempts to define the | In this particular case, this architecture attempts to define the | |||
| logical components of Internet email and does so post hoc, trying to | logical components of Internet email and does so post hoc, trying to | |||
| capture the architectural principles that the current email protocols | capture the architectural principles that the current email protocols | |||
| embody. To different extents, email protocols will conform to this | embody. To different extents, email protocols will conform to this | |||
| architecture more or less well. Insofar as this architecture differs | architecture more or less well. Insofar as this architecture differs | |||
| from those protocols, the reasons are generally well understood and | from those protocols, the reasons are generally well understood and | |||
| are required for interoperation. The differences are not a sign that | are required for interoperation. The differences are not a sign that | |||
| protocols need to be fixed. However, this architecture is a best | protocols need to be fixed. However, this architecture is a best | |||
| attempt at a logical model of Internet email, and insofar as new | attempt at a logical model of Internet email, and insofar as new | |||
| skipping to change at page 8, line 37 ¶ | skipping to change at page 8, line 37 ¶ | |||
| Hence <RFC5322.From> is the IMF From: header field in an email | Hence <RFC5322.From> is the IMF From: header field in an email | |||
| content header and <RFC5321.MailFrom> is the address in the SMTP | content header and <RFC5321.MailFrom> is the address in the SMTP | |||
| "Mail From" command. | "Mail From" command. | |||
| When occurring without the IMF (RFC 5322) qualifier, header field | When occurring without the IMF (RFC 5322) qualifier, header field | |||
| names are shown with a colon suffix. For example, From:. | names are shown with a colon suffix. For example, From:. | |||
| References to labels for actors, functions or components have the | References to labels for actors, functions or components have the | |||
| first letter capitalized. | first letter capitalized. | |||
| Also, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | ||||
| NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | ||||
| this document are to be interpreted as described in RFC 2119 | ||||
| [RFC2119] [RFC2119]. | ||||
| RFC EDITOR: Remove the following paragraph before publication. | RFC EDITOR: Remove the following paragraph before publication. | |||
| Discussion venue: Please direct discussion about this document | Discussion venue: Please direct discussion about this document | |||
| to the IETF-SMTP mailing list <http://www.imc.org/ietf-smtp>. | to the IETF-SMTP mailing list <http://www.imc.org/ietf-smtp>. | |||
| 2. Responsible Actor Roles | 2. Responsible Actor Roles | |||
| Internet Mail is a highly distributed service, with a variety of | Internet Mail is a highly distributed service, with a variety of | |||
| actors playing different roles. These actors fall into three basic | actors playing different roles. These actors fall into three basic | |||
| types: | types: | |||
| skipping to change at page 9, line 39 ¶ | skipping to change at page 9, line 33 ¶ | |||
| * Authors | * Authors | |||
| * Recipients | * Recipients | |||
| * Return Handlers | * Return Handlers | |||
| * Mediators | * Mediators | |||
| Figure 2 shows the primary and secondary flows of messages among | Figure 2 shows the primary and secondary flows of messages among | |||
| them. | them. As a pragmatic heuristic: User Actors can generate, modify or | |||
| look at the whole message. | ||||
| ++==========++ | ++==========++ | |||
| || Author ||<..................................<.. | || Author ||<..................................<.. | |||
| ++=++=++=++=++ . | ++=++=++=++=++ . | |||
| || || || ++===========++ . | || || || ++===========++ . | |||
| || || ++====>|| Recipient || . | || || ++====>|| Recipient || . | |||
| || || ++=====+=====++ . | || || ++=====+=====++ . | |||
| || || . . | || || . . | |||
| || || ..........................>.+ | || || ..........................>.+ | |||
| || || . | || || . | |||
| || || ................... . | || || ................... . | |||
| || || . . . | || || . . . | |||
| || || V . . | || || V . . | |||
| || || +-----------+ ++=====+=====++ . | || || +-----------+ ++=====+=====++ . | |||
| || ++========>| Mediator +===>|| Recipient || . | || ++========>| Mediator +===>|| Recipient || . | |||
| || +-----+-----+ ++=====+=====++ . | || +-----+-----+ ++=====+=====++ . | |||
| || . . . | || . . . | |||
| || ..................+.......>.+ | || ..................+.......>.+ | |||
| || . | || . | |||
| || ..............+.................. . | || ..............+.................. . | |||
| || . . . . | || . . . . | |||
| \/ V V ' . | \/ V V ' . | |||
| +-----------+ +-----------+ ++=====+=====++ . | +-----------+ +-----------+ ++=====+=====++ . | |||
| | Mediator +===>| Mediator +===>|| Recipient || . | | Mediator +===>| Mediator +===>|| Recipient || . | |||
| +-----+-----+ +-----+-----+ ++=====+=====++ . | +-----+-----+ +-----+-----+ ++=====+=====++ . | |||
| . . . . | . . . . | |||
| .................+.................+.......>.. | .................+.................+.......>.. | |||
| Legend: == lines indicate primary (possibly indirect) transfers or roles | Legend: === lines indicate primary (possibly indirect) | |||
| ... lines indicate supporting transfers or roles | transfers or roles | |||
| ... lines indicate supporting transfers or roles | ||||
| Figure 2: Relationships Among User Actors | Figure 2: Relationships Among User Actors | |||
| From the user perspective, all message transfer activities are | From the user perspective, all message transfer activities are | |||
| performed by a monolithic Message Handling Service (MHS), even though | performed by a monolithic Message Handling Service (MHS), even though | |||
| the actual service can be provided by many independent organizations. | the actual service can be provided by many independent organizations. | |||
| Users are customers of this unified service. | Users are customers of this unified service. | |||
| Whenever any MHS actor sends information to back to an Author or | Whenever any MHS actor sends information to back to an Author or | |||
| Originator in the sequence of handling a message, that actor is a | Originator in the sequence of handling a message, that actor is a | |||
| skipping to change at page 11, line 21 ¶ | skipping to change at page 11, line 21 ¶ | |||
| Any Recipient can close the user communication loop by creating and | Any Recipient can close the user communication loop by creating and | |||
| submitting a new message that replies to the Author. An example of | submitting a new message that replies to the Author. An example of | |||
| an automated form of reply is the Message Disposition Notification | an automated form of reply is the Message Disposition Notification | |||
| (MDN), which informs the Author about the Recipient's handling of the | (MDN), which informs the Author about the Recipient's handling of the | |||
| message. (See Section 4.1.) | message. (See Section 4.1.) | |||
| 2.1.3. Return Handler | 2.1.3. Return Handler | |||
| Also called "Bounce Handler", the Return Handler is a special form of | Also called "Bounce Handler", the Return Handler is a special form of | |||
| Recipient tasked with servicing notifications that the MHS generates, | Recipient tasked with servicing notifications that the MHS generates, | |||
| as it transfers or delivers the message. These notices can be about | as it transfers or delivers the message. (See Figure 3.) These | |||
| failures or completions and are sent to an address that is specified | notices can be about failures or completions and are sent to an | |||
| by the Originator. This Return Handling address (also known as a | address that is specified by the Originator. This Return Handling | |||
| Return address) might have no visible characteristics in common with | address (also known as a Return address) might have no visible | |||
| the address of the Author or Originator. | characteristics in common with the address of the Author or | |||
| Originator. | ||||
| 2.1.4. Mediator | 2.1.4. Mediator | |||
| A Mediator receives, aggregates, reformulates, and redistributes | A Mediator receives, aggregates, reformulates, and redistributes | |||
| messages among Authors and Recipients who are the principals in | messages among Authors and Recipients who are the principals in | |||
| (potentially) protracted exchanges. This activity is easily confused | (potentially) protracted exchanges. This activity is easily confused | |||
| with the underlying MHS transfer exchanges. However, each serves | with the underlying MHS transfer exchanges. However, each serves | |||
| very different purposes and operates in very different ways. | very different purposes and operates in very different ways. | |||
| When mail is delivered to the Mediator specified in the | When mail is delivered to the Mediator specified in the | |||
| skipping to change at page 12, line 24 ¶ | skipping to change at page 12, line 25 ¶ | |||
| Its purpose is to emulate a Relay. For a detailed discussion, see | Its purpose is to emulate a Relay. For a detailed discussion, see | |||
| Section 2.2.3. | Section 2.2.3. | |||
| 2.2. Message Handling Service (MHS) Actors | 2.2. Message Handling Service (MHS) Actors | |||
| The Message Handling Service (MHS) performs a single end-to-end | The Message Handling Service (MHS) performs a single end-to-end | |||
| transfer on behalf of the Author to reach the Recipient addresses | transfer on behalf of the Author to reach the Recipient addresses | |||
| specified in the original RFC5321.RcptTo commands. Exchanges that | specified in the original RFC5321.RcptTo commands. Exchanges that | |||
| are either mediated or iterative and protracted, such as those used | are either mediated or iterative and protracted, such as those used | |||
| for collaboration over time are handled by the User actors, not by | for collaboration over time are handled by the User actors, not by | |||
| the MHS actors. | the MHS actors. As a pragmatic heuristic MHS actors actors generate, | |||
| modify or look at only transfer data, rather than the entire message. | ||||
| Figure 3 shows the relationships among transfer participants in | Figure 3 shows the relationships among transfer participants in | |||
| Internet Mail. Although it shows the Originator (labeled Origin) as | Internet Mail. Although it shows the Originator (labeled Origin) as | |||
| distinct from the Author and Receiver (labeled Recv) as distinct from | distinct from the Author and Receiver (labeled Recv) as distinct from | |||
| Recipient, each pair of roles usually has the same actor. | Recipient, each pair of roles usually has the same actor. Transfers | |||
| Transfers typically entail one or more Relays. However direct | typically entail one or more Relays. However direct delivery from | |||
| delivery from the Originator to Receiver is possible. Intra- | the Originator to Receiver is possible. Intra-organization mail | |||
| organization mail services usually have only one Relay. | services usually have only one Relay. | |||
| ++==========++ ++===========++ | ||||
| || Author || || Recipient || | ||||
| ++====++====++ +--------+ ++===========++ | ||||
| || | Return | /\ | ||||
| || +-+------+ || | ||||
| \/ . ^ || | ||||
| +---------+ . . +---++---+ | ||||
| | | . . | | | ||||
| /--+---------+----------------------------+--------+----\ | ||||
| | | | . . MHS | | | | ||||
| | | Origin +<...... .................+ Recv | | | ||||
| | | | ^ | | | | ||||
| | +---++----+ . +--------+ | | ||||
| | || . /\ | | ||||
| | || ..............+.................. || | | ||||
| | \/ . . . || | | ||||
| | +-------+-+ +--+------+ +-+--++---+ | | ||||
| | | Relay +=======>| Relay +=======>| Relay | | | ||||
| | +---------+ +----++---+ +---------+ | | ||||
| | || | | ||||
| | || | | ||||
| | \/ | | ||||
| | +---------+ | | ||||
| | | Gateway +-->... | | ||||
| | +---------+ | | ||||
| \-------------------------------------------------------/ | ||||
| Legend: == lines indicate primary (possibly indirect) transfers or roles | ++==========++ ++===========++ | |||
| ... lines indicate supporting transfers or roles | || Author || || Recipient || | |||
| ++====++====++ +--------+ ++===========++ | ||||
| || | Return | /\ | ||||
| || +-+------+ || | ||||
| \/ . ^ || | ||||
| +---------+ . . +---++---+ | ||||
| | | . . | | | ||||
| /--+---------+----------------------------+--------+----\ | ||||
| | | | . . MHS | | | | ||||
| | | Origin +<...... .................+ Recv | | | ||||
| | | | ^ | | | | ||||
| | +---++----+ . +--------+ | | ||||
| | || . /\ | | ||||
| | || ..............+.................. || | | ||||
| | \/ . . . || | | ||||
| | +-------+-+ +--+------+ +-+--++---+ | | ||||
| | | Relay +=======>| Relay +=======>| Relay | | | ||||
| | +---------+ +----++---+ +---------+ | | ||||
| | || | | ||||
| | || | | ||||
| | \/ | | ||||
| | +---------+ | | ||||
| | | Gateway +-->... | | ||||
| | +---------+ | | ||||
| \-------------------------------------------------------/ | ||||
| Legend: === and || lines indicate primary (possibly | ||||
| indirect) transfers or roles | ||||
| ... lines indicate supporting transfers or roles | ||||
| Figure 3: Relationships Among MHS Actors | Figure 3: Relationships Among MHS Actors | |||
| 2.2.1. Originator | 2.2.1. Originator | |||
| The Originator ensures that a message is valid for posting and then | The Originator ensures that a message is valid for posting and then | |||
| submits it to a Relay. A message is valid if it conforms to both | submits it to a Relay. A message is valid if it conforms to both | |||
| Internet Mail standards and local operational policies. The | Internet Mail standards and local operational policies. The | |||
| Originator can simply review the message for conformance and reject | Originator can simply review the message for conformance and reject | |||
| it if it finds errors, or it can create some or all of the necessary | it if it finds errors, or it can create some or all of the necessary | |||
| information. In effect, the Originator is responsible for the | information. In effect, the Originator is responsible for the | |||
| functions of the Mail Submission Agent. | functions of the Mail Submission Agent. | |||
| The Originator operates with dual allegiance. It serves the Author | The Originator operates with dual allegiance. It serves the Author | |||
| and can be the same entity. But its role in assuring validity means | and can be the same entity. But its role in assuring validity means | |||
| that it MUST also represent the local operator of the MHS, that is, | that it also represents the local operator of the MHS, that is, the | |||
| the local ADministrative Management Domain (ADMD). | local ADministrative Management Domain (ADMD). | |||
| The Originator also performs any post-submission, Author-related | The Originator also performs any post-submission, Author-related | |||
| administrative tasks associated with message transfer and delivery. | administrative tasks associated with message transfer and delivery. | |||
| Notably, these tasks pertain to sending error and delivery notices, | Notably, these tasks pertain to sending error and delivery notices, | |||
| enforcing local policies, and dealing with messages from the Author | enforcing local policies, and dealing with messages from the Author | |||
| that prove to be problematic for the Internet. The Originator is | that prove to be problematic for the Internet. The Originator is | |||
| accountable for the message content, even when it is not responsible | accountable for the message content, even when it is not responsible | |||
| for it. The Author creates the message, but the Originator handles | for it. The Author creates the message, but the Originator handles | |||
| any transmission issues with it. | any transmission issues with it. | |||
| skipping to change at page 14, line 47 ¶ | skipping to change at page 14, line 42 ¶ | |||
| * User Mediators | * User Mediators | |||
| * MHS Relays | * MHS Relays | |||
| * Packet Switches | * Packet Switches | |||
| The bottom layer is the Internet's IP service. The most basic email | The bottom layer is the Internet's IP service. The most basic email | |||
| scenarios involve Relays and Switches. | scenarios involve Relays and Switches. | |||
| When a Relay stops attempting to transfer a message, it becomes an | When a Relay stops attempting to transfer a message, it becomes an | |||
| Author because it must send an error message to the Return address. | Author because it sends an error message to the Return address. The | |||
| The potential for looping is avoided by omitting a Return address | potential for looping is avoided by omitting a Return address from | |||
| from this message. | this message. | |||
| 2.2.3. Gateway | 2.2.3. Gateway | |||
| A Gateway is a hybrid of User and Relay that connects heterogeneous | A Gateway is a hybrid of User and Relay that connects heterogeneous | |||
| mail services. Its purpose is to emulate a Relay and the closer it | mail services. Its purpose is to emulate a Relay and the closer it | |||
| comes to this, the better. A Gateway operates as a User when it | comes to this, the better. A Gateway operates as a User when it | |||
| needs the ability to modify message content. | needs the ability to modify message content. | |||
| Differences between mail services can be as small as minor syntax | Differences between mail services can be as small as minor syntax | |||
| variations, but they usually encompass significant, semantic | variations, but they usually encompass significant, semantic | |||
| skipping to change at page 16, line 22 ¶ | skipping to change at page 16, line 16 ¶ | |||
| administrative and operational relationships. Each is a distinct | administrative and operational relationships. Each is a distinct | |||
| ADMD, potentially having a complex arrangement of functional | ADMD, potentially having a complex arrangement of functional | |||
| components. Figure 4 depicts relationships among ADMDs. The | components. Figure 4 depicts relationships among ADMDs. The | |||
| benefit of the ADMD construct is to facilitate discussion about | benefit of the ADMD construct is to facilitate discussion about | |||
| designs, policies and operations that need to distinguish between | designs, policies and operations that need to distinguish between | |||
| internal issues and external ones. | internal issues and external ones. | |||
| The architectural impact of the need for boundaries between ADMDs is | The architectural impact of the need for boundaries between ADMDs is | |||
| discussed in [Tussle]. Most significant is that the entities | discussed in [Tussle]. Most significant is that the entities | |||
| communicating across ADMD boundaries typically have the added burden | communicating across ADMD boundaries typically have the added burden | |||
| of enforcing organizational policies concerning external | of enforcing organizational policies concerning external | |||
| communications. At a more mundane level, routing mail between ADMDs | communications. At a more mundane level, routing mail between ADMDs | |||
| can be an issue, such as needing to route mail between organizational | can be an issue, such as needing to route mail between organizational | |||
| partners over specially trusted paths. | partners over specially trusted paths. | |||
| These are three basic types of ADMDs: | These are three basic types of ADMDs: | |||
| Edge: Independent transfer services in networks at the edge of | Edge: Independent transfer services in networks at the edge of | |||
| the open Internet Mail service. | the open Internet Mail service. | |||
| Consumer: This might be a type of Edge service, as is common | Consumer: This might be a type of Edge service, as is common | |||
| for web-based email access. | for web-based email access. | |||
| Transit: Mail Service Providers (MSP) that offer value-added | Transit: Mail Service Providers (MSP) that offer value-added | |||
| capabilities for Edge ADMDs, such as aggregation and filtering. | capabilities for Edge ADMDs, such as aggregation and filtering. | |||
| The mail-level transit service is different from packet-level | The mail-level transit service is different from packet-level | |||
| switching. End-to-end packet transfers usually go through | switching. End-to-end packet transfers usually go through | |||
| intermediate routers; email exchange across the open Internet can be | intermediate routers; email exchange across the open Internet can be | |||
| directly between the Boundary MTAs of Edge ADMDs. This distinction | directly between the Boundary MTAs of Edge ADMDs. This distinction | |||
| between direct and indirect interaction highlights the differences | between direct and indirect interaction highlights the differences | |||
| discussed in Section 2.2.2 | discussed in Section 2.2.2 | |||
| +--------+ +---------+ +-------+ +-----------+ | +--------+ +---------+ +-------+ +-----------+ | |||
| | ADMD1 |<===>| ADMD2 |<===>| ADMD3 |<===>| ADMD4 | | | ADMD1 |<===>| ADMD2 |<===>| ADMD3 |<===>| ADMD4 | | |||
| | ----- | | ----- | | ----- | | ----- | | | ----- | | ----- | | ----- | | ----- | | |||
| | | | | | | | | | | | | | | | | | | |||
| | Author | | | | | | Recipient | | | Author | | | | | | Recipient | | |||
| | . | | | | | | ^ | | | . | | | | | | ^ | | |||
| | V | | | | | | . | | | V | | | | | | . | | |||
| | Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer | | | Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer | | |||
| | | | | | | | | | | | | | | | | | | |||
| +--------+ +---------+ +-------+ +-----------+ | +--------+ +---------+ +-------+ +-----------+ | |||
| Legend: == lines indicate primary (possibly indirect) transfers or roles | Legend: === lines indicate primary (possibly indirect) | |||
| ... lines indicate supporting transfers or roles | transfers or roles | |||
| ... lines indicate supporting transfers or roles | ||||
| Figure 4: Administrative Domain (ADMD) Example | Figure 4: Administrative Domain (ADMD) Example | |||
| Edge networks can use proprietary email standards internally. | Edge networks can use proprietary email standards internally. | |||
| However the distinction between Transit network and Edge network | However the distinction between Transit network and Edge network | |||
| transfer services is significant because it highlights the need for | transfer services is significant because it highlights the need for | |||
| concern over interaction and protection between independent | concern over interaction and protection between independent | |||
| administrations. In particular, this distinction calls for | administrations. In particular, this distinction calls for | |||
| additional care in assessing the transitions of responsibility and | additional care in assessing the transitions of responsibility and | |||
| the accountability and authorization relationships among participants | the accountability and authorization relationships among participants | |||
| skipping to change at page 18, line 30 ¶ | skipping to change at page 18, line 30 ¶ | |||
| These ADMDs operate email services, such as for consumers or | These ADMDs operate email services, such as for consumers or | |||
| client companies. | client companies. | |||
| Practical operational concerns demand that providers be involved in | Practical operational concerns demand that providers be involved in | |||
| administration and enforcement issues. This involvement can extend | administration and enforcement issues. This involvement can extend | |||
| to operators of lower-level packet services. | to operators of lower-level packet services. | |||
| 3. Identities | 3. Identities | |||
| The forms of identity used by Internet Mail are: mailbox, domain | The forms of identity used by Internet Mail are: mailbox, domain | |||
| name, message-ID and ENVID. Each must be globally unique. | name, message-ID and ENVID. Each is globally unique. | |||
| 3.1. Mailbox | 3.1. Mailbox | |||
| "A mailbox receives mail. It is a conceptual entity that does not | "A mailbox receives mail. It is a conceptual entity that does not | |||
| necessarily pertain to file storage." [RFC5322] | necessarily pertain to file storage." [RFC5322] | |||
| A mailbox is specified as an Internet Mail address <addr-spec>. It | A mailbox is specified as an Internet Mail address <addr-spec>. It | |||
| has two distinct parts, separated by an at-sign (@). The right side | has two distinct parts, separated by an at-sign (@). The right side | |||
| is a globally interpreted domain name associated with an ADMD. | is a globally interpreted domain name associated with an ADMD. | |||
| Domain names are discussed in Section 3.3. Formal Internet Mail | Domain names are discussed in Section 3.3. Formal Internet Mail | |||
| addressing syntax can support source routes, to indicate the path | addressing syntax can support source routes, to indicate the path | |||
| through which a message ought to be sent. The use of source routes | through which a message ought to be sent. The use of source routes | |||
| is not common and has been deprecated in [RFC5321]. | is not common and has been deprecated in [RFC5321]. | |||
| The portion to the left of the at-sign contains a string that is | The portion to the left of the at-sign contains a string that is | |||
| globally opaque and is called the <local-part>. It is to be | globally opaque and is called the <local-part>. It is interpreted | |||
| interpreted only by the entity specified by the address's domain | only by the entity specified by the address's domain name. Except as | |||
| name. Except as noted later in this section all other entities MUST | noted later in this section all other entities treat the <local-part> | |||
| treat the <local-part> as an uninterpreted literal string and MUST | as an uninterpreted literal string and preserve all of its original | |||
| preserve all of its original details. As such its public | details. As such its public distribution is equivalent to sending a | |||
| distribution is equivalent to sending a Web browser "cookie" that is | Web browser "cookie" that is only interpreted upon being returned to | |||
| only interpreted upon being returned to its creator. | its creator. | |||
| Some local-part values have been standardized, for contacting | Some local-part values have been standardized, for contacting | |||
| personnel at an organization. These names cover common operations | personnel at an organization. These names cover common operations | |||
| and business functions. [RFC2142] | and business functions. [RFC2142] | |||
| It is common for sites to have local structuring conventions for the | It is common for sites to have local structuring conventions for the | |||
| left-hand side <local-part> of an <addr-spec>. This permits sub- | left-hand side <local-part> of an <addr-spec>. This permits sub- | |||
| addressing, such as for distinguishing different discussion groups | addressing, such as for distinguishing different discussion groups | |||
| used by the same participant. However it is worth stressing that | used by the same participant. However it is worth stressing that | |||
| these conventions are strictly private to the user's organization and | these conventions are strictly private to the user's organization and | |||
| MUST NOT be interpreted by any domain except the one listed in the | are not interpreted by any domain except the one listed in the right | |||
| right side of the <addr-spec>. The exceptions are those specialized | side of the <addr-spec>. The exceptions are those specialized | |||
| services that conform to public, standardized conventions, as noted | services that conform to public, standardized conventions, as noted | |||
| below. | below. | |||
| Basic email addressing defines the <local-part> as being globally | Basic email addressing defines the <local-part> as being globally | |||
| opaque. However there are some uses of email that add a | opaque. However there are some uses of email that add a | |||
| standardized, global schema to the value, such as between an author | standardized, global schema to the value, such as between an author | |||
| and a Gateway. The <local-part> details remain invisible to the | and a Gateway. The <local-part> details remain invisible to the | |||
| public email transfer infrastructure, but provide addressing and | public email transfer infrastructure, but provide addressing and | |||
| handling instructions for further processing by the Gateway. | handling instructions for further processing by the Gateway. | |||
| Standardized examples of these conventions are the telephone | Standardized examples of these conventions are the telephone | |||
| skipping to change at page 20, line 40 ¶ | skipping to change at page 20, line 40 ¶ | |||
| 3.4.1. Message-ID | 3.4.1. Message-ID | |||
| IMF provides for, at most, a single Message-ID:. The Message-ID: for | IMF provides for, at most, a single Message-ID:. The Message-ID: for | |||
| a single message, which is a user-level IMF tag, has a variety of | a single message, which is a user-level IMF tag, has a variety of | |||
| uses including threading, aiding identification of duplicates, and | uses including threading, aiding identification of duplicates, and | |||
| DSN tracking. The Originator assigns the Message-ID:. The | DSN tracking. The Originator assigns the Message-ID:. The | |||
| Recipient's ADMD is the intended consumer of the Message-ID:, | Recipient's ADMD is the intended consumer of the Message-ID:, | |||
| although any actor along the transfer path can use it. | although any actor along the transfer path can use it. | |||
| Message-ID: MUST be globally unique. Its format is similar to that | Message-ID: is be globally unique. Its format is similar to that of | |||
| of a mailbox, with two distinct parts, separated by an at-sign (@). | a mailbox, with two distinct parts, separated by an at-sign (@). | |||
| Typically, the right side specifies the ADMD or host that assigns the | Typically, the right side specifies the ADMD or host that assigns the | |||
| identifier, and the left side contains a string that is globally | identifier, and the left side contains a string that is globally | |||
| opaque and serves to uniquely identify the message within the domain | opaque and serves to uniquely identify the message within the domain | |||
| referenced on the right side. The duration of uniqueness for the | referenced on the right side. The duration of uniqueness for the | |||
| message identifier is undefined. | message identifier is undefined. | |||
| When a message is revised in any way, the decision whether to assign | When a message is revised in any way, the decision whether to assign | |||
| a new Message-ID: requires a subjective assessment to determine | a new Message-ID: requires a subjective assessment to determine | |||
| whether the editorial content has been changed enough to constitute a | whether the editorial content has been changed enough to constitute a | |||
| new message. [RFC5322] states that "a message identifier pertains to | new message. [RFC5322] states that "a message identifier pertains to | |||
| skipping to change at page 21, line 49 ¶ | skipping to change at page 21, line 49 ¶ | |||
| * If a message is "redirected", such as using IMF "Resent-*" | * If a message is "redirected", such as using IMF "Resent-*" | |||
| header fields, some recipients will consider it the same | header fields, some recipients will consider it the same | |||
| message, but some will not. | message, but some will not. | |||
| The absence of both objective, precise criteria for regenerating a | The absence of both objective, precise criteria for regenerating a | |||
| Message-ID: and strong protection associated with the string means | Message-ID: and strong protection associated with the string means | |||
| that the presence of an ID can permit an assessment that is | that the presence of an ID can permit an assessment that is | |||
| marginally better than a heuristic, but the ID certainly has no value | marginally better than a heuristic, but the ID certainly has no value | |||
| on its own for strict formal reference or comparison. For that | on its own for strict formal reference or comparison. For that | |||
| reason, the Message-ID: SHOULD NOT be used for any function that has | reason, the Message-ID: is not intended to be used for any function | |||
| security implications. | that has security implications. | |||
| 3.4.2. ENVID | 3.4.2. ENVID | |||
| The ENVID (envelope identifier) can be used for message-tracking | The ENVID (envelope identifier) can be used for message-tracking | |||
| purposes ([RFC3885], [RFC3464]) concerning a single posting/delivery | purposes ([RFC3885], [RFC3464]) concerning a single posting/delivery | |||
| transfer. The ENVID labels a single transit of the MHS by a specific | transfer. The ENVID labels a single transit of the MHS by a specific | |||
| message. So, the ENVID is used for one message posting, until that | message. So, the ENVID is used for one message posting, until that | |||
| message is delivered. A re-posting of the message, such as by a | message is delivered. A re-posting of the message, such as by a | |||
| Mediator, does not reuse that ENVID, but can use a new one, even | Mediator, does not reuse that ENVID, but can use a new one, even | |||
| though the message might legitimately retain its original | though the message might legitimately retain its original | |||
| skipping to change at page 24, line 5 ¶ | skipping to change at page 24, line 5 ¶ | |||
| Message Store (MS) | Message Store (MS) | |||
| Author MS (aMS) | Author MS (aMS) | |||
| Recipient MS (rMS) | Recipient MS (rMS) | |||
| This figure shows function modules and the standardized protocols | This figure shows function modules and the standardized protocols | |||
| used between them. | used between them. | |||
| ++========++ | ++========++ | |||
| || || +-------+ | || || +-------+ | |||
| ...........++ aMUA ||<............................+ Disp | | ...........++ aMUA ||<............................+ Disp | | |||
| . || || +-------+ | . || || +-------+ | |||
| . ++=+==+===++ ^ | . ++=+==+===++ ^ | |||
| . local,imap}| |{smtp,submission . | . local,imap}| |{smtp,submission . | |||
| . +-----+ | | +--------+ . | . +-----+ | | +--------+ . | |||
| . | aMS |<---+ | ........................>| Return | . | . | aMS |<---+ | ........................>| Return | . | |||
| . +-----+ | . +--------+ . | . +-----+ | . +--------+ . | |||
| . | . ***************** ^ . | . | . ***************** ^ . | |||
| . +-----V-.----*------------+ * . . | . +-----V-.----*------------+ * . . | |||
| . MSA | +-------+ * +------+ | * . . | . MSA | +-------+ * +------+ | * . . | |||
| . | | aMSA +-(S)->| hMSA | | * . . | . | | aMSA +-(S)->| hMSA | | * . . | |||
| . | +-------+ * +--+---+ | * . . | . | +-------+ * +--+---+ | * . . | |||
| V +------------*------+-----+ * . . | V +------------*------+-----+ * . . | |||
| //==========\\ * V {smtp * . . | //==========\\ * V {smtp * . . | |||
| || MESSAGE || * +------+ * //===+===\\ . | || MESSAGE || * +------+ * //===+===\\ . | |||
| ||----------|| MHS * | MTA | * || dsn || . | ||----------|| MHS * | MTA | * || dsn || . | |||
| || ENVELOPE || * +--+---+ * \\=======// . | || ENVELOPE || * +--+---+ * \\=======// . | |||
| || smtp || * V {smtp * ^ ^ . | || smtp || * V {smtp * ^ ^ . | |||
| || CONTENT || * +------+ * . . //==+==\\ | || CONTENT || * +------+ * . . //==+==\\ | |||
| || imf || * | MTA +....*...... . || mdn || | || imf || * | MTA +....*...... . || mdn || | |||
| || mime || * +--+---+ * . \\=====// | || mime || * +--+---+ * . \\=====// | |||
| \\==========// * smtp}| {local * . ^ | \\==========// * smtp}| {local * . ^ | |||
| . MDA * | {lmtp * . . | . MDA * | {lmtp * . . | |||
| . +----------------+------V-----+ * . . | . +----------------+------V-----+ * . . | |||
| . | +----------+ * +------+ | * . . | . | +----------+ * +------+ | * . . | |||
| . | | | * | | +..*.......... . | . | | | * | | +..*.......... . | |||
| . | | rMDA |<-(D)--+ hMDA | | * . | . | | rMDA |<-(D)--+ hMDA | | * . | |||
| . | | | * | | |<.*........ . | . | | | * | | |<.*........ . | |||
| . | +-+------+-+ * +------+ | * . . | . | +-+------+-+ * +------+ | * . . | |||
| . +------+---------*------------+ * . . | . +------+---------*------------+ * . . | |||
| . smtp,local}| ***************** . . | . smtp,local}| ***************** . . | |||
| . V . . | . V . . | |||
| . +-----+ //===+===\\ . | . +-----+ //===+===\\ . | |||
| . | rMS | || sieve || . | . | rMS | || sieve || . | |||
| . +--+--+ \\=======// . | . +--+--+ \\=======// . | |||
| . |{imap,pop,local ^ . | . |{imap,pop,local ^ . | |||
| . V . . | . V . . | |||
| . ++==========++ . . | . ++==========++ . . | |||
| . || || . . | . || || . . | |||
| .......>|| rMUA ++........................... . | .......>|| rMUA ++........................... . | |||
| || ++................................... | || ++................................... | |||
| ++==========++ | ++==========++ | |||
| Legend: == lines indicate primary (possibly indirect) transfers or roles | Legend: --- lines indicate primary (possibly indirect) | |||
| == boxes indicate data objects | transfers or roles | |||
| ... lines indicate supporting transfers or roles | === boxes indicate data objects | |||
| *** lines indicate aggregated service | ... lines indicate supporting transfers or roles | |||
| *** lines indicate aggregated service | ||||
| Figure 5: Protocols and Services | Figure 5: Protocols and Services | |||
| 4.1. Message Data | 4.1. Message Data | |||
| The purpose of the Message Handling System (MHS) is to exchange an | The purpose of the Message Handling System (MHS) is to exchange an | |||
| IMF message object among participants [RFC5322]. All of its | IMF message object among participants [RFC5322]. All of its | |||
| underlying mechanisms serve to deliver that message from its Author | underlying mechanisms serve to deliver that message from its Author | |||
| to its Recipients. A message can be explicitly labeled as to its | to its Recipients. A message can be explicitly labeled as to its | |||
| nature [RFC3458]. | nature [RFC3458]. | |||
| skipping to change at page 26, line 11 ¶ | skipping to change at page 26, line 11 ¶ | |||
| generated by an rMUA and is sent to the Disposition- | generated by an rMUA and is sent to the Disposition- | |||
| Notification-To addresses. The mailbox for this is shown as | Notification-To addresses. The mailbox for this is shown as | |||
| Disp in Figure 5. | Disp in Figure 5. | |||
| Message Filtering (SIEVE): | Message Filtering (SIEVE): | |||
| Sieve is a scripting language used to specify conditions for | Sieve is a scripting language used to specify conditions for | |||
| differential handling of mail, typically at the time of | differential handling of mail, typically at the time of | |||
| delivery [RFC5228]. Scripts can be conveyed in a variety of | delivery [RFC5228]. Scripts can be conveyed in a variety of | |||
| ways, such as a MIME part in a message. Figure 5 shows a Sieve | ways, such as a MIME part in a message. Figure 5 shows a Sieve | |||
| script going from the rMUA to the MDA. However, filtering can | script going from the rMUA to the MDA. However, filtering can | |||
| be done at many different points along the transit path, and | be done at many different points along the transit path, and | |||
| any one or more of them might be subject to Sieve directives, | any one or more of them might be subject to Sieve directives, | |||
| especially within a single ADMD. the Figure 5 shows only one | especially within a single ADMD. the Figure 5 shows only one | |||
| relationship, for (relative) simplicity. | relationship, for (relative) simplicity. | |||
| 4.1.1. Envelope | 4.1.1. Envelope | |||
| Internet Mail has a fragmented framework for transit-related handling | Internet Mail has a fragmented framework for transit-related handling | |||
| information. Information that is used directly by the MHS is called | information. Information that is used directly by the MHS is called | |||
| the "envelope." It directs handling activities by the transfer | the "envelope." It directs handling activities by the transfer | |||
| skipping to change at page 26, line 44 ¶ | skipping to change at page 26, line 44 ¶ | |||
| different applications. Procedures for registering header fields are | different applications. Procedures for registering header fields are | |||
| defined in [RFC3864]. An extensive set of existing header field | defined in [RFC3864]. An extensive set of existing header field | |||
| registrations is provided in [RFC4021]. | registrations is provided in [RFC4021]. | |||
| One danger of placing additional information in header fields is that | One danger of placing additional information in header fields is that | |||
| Gateways often alter or delete them. | Gateways often alter or delete them. | |||
| 4.1.3. Body | 4.1.3. Body | |||
| The body of a message might be lines of ASCII text or a | The body of a message might be lines of ASCII text or a | |||
| hierarchically structured composition of multi-media body-part | hierarchically structured composition of multi-media body-part | |||
| attachments, using MIME. [RFC2045], [RFC2046], [RFC2047], [RFC4288], | attachments, using MIME. [RFC2045], [RFC2046], [RFC2047], [RFC4288], | |||
| [RFC2049] | [RFC2049] | |||
| 4.1.4. Identity References in a Message | 4.1.4. Identity References in a Message | |||
| Table 1 lists the core identifiers present in a message during | Table 1 lists the core identifiers present in a message during | |||
| transit. | transit. | |||
| +----------------------+----------------+---------------------------+ | +----------------------+----------------+---------------------------+ | |||
| | Layer | Field | Set By | | | Layer | Field | Set By | | |||
| skipping to change at page 28, line 20 ¶ | skipping to change at page 28, line 20 ¶ | |||
| other words, this field overrides the From: field for responses | other words, this field overrides the From: field for responses | |||
| from Recipients. | from Recipients. | |||
| RFC5322.Sender: Set by - Originator | RFC5322.Sender: Set by - Originator | |||
| This field specifies the address responsible for submitting the | This field specifies the address responsible for submitting the | |||
| message to the transfer service. This field can be omitted if | message to the transfer service. This field can be omitted if | |||
| it contains the same address as RFC5322.From. However, | it contains the same address as RFC5322.From. However, | |||
| omitting this field does not mean that no Sender is specified; | omitting this field does not mean that no Sender is specified; | |||
| it means that that header field is virtual and that the address | it means that that header field is virtual and that the address | |||
| in the From: field MUST be used. | in the From: field is to be used. | |||
| Specification of the notifications Return addresses, which are | Specification of the notifications Return addresses, which are | |||
| contained in RFC5321.MailFrom, is made by the RFC5322.Sender. | contained in RFC5321.MailFrom, is made by the RFC5322.Sender. | |||
| Typically the Return address is the same as the Sender address. | Typically the Return address is the same as the Sender address. | |||
| However, some usage scenarios require it to be different. | However, some usage scenarios require it to be different. | |||
| RFC5322.To/.CC: Set by - Author | RFC5322.To/.CC: Set by - Author | |||
| These fields specify MUA Recipient addresses. However, some or | These fields specify MUA Recipient addresses. However, some or | |||
| all of the addresses in these fields might not be present in | all of the addresses in these fields might not be present in | |||
| skipping to change at page 29, line 22 ¶ | skipping to change at page 29, line 22 ¶ | |||
| RFC5321.MailFrom: Set by - Originator | RFC5321.MailFrom: Set by - Originator | |||
| This field is an end-to-end string that specifies an email | This field is an end-to-end string that specifies an email | |||
| address for receiving return control information, such as | address for receiving return control information, such as | |||
| returned messages. The name of this field is misleading, | returned messages. The name of this field is misleading, | |||
| because it is not required to specify either the Author or the | because it is not required to specify either the Author or the | |||
| actor responsible for submitting the message. Rather, the | actor responsible for submitting the message. Rather, the | |||
| actor responsible for submission specifies the RFC5321.MailFrom | actor responsible for submission specifies the RFC5321.MailFrom | |||
| address. Ultimately, the simple basis for deciding which | address. Ultimately, the simple basis for deciding which | |||
| address needs to be in the RFC5321.MailFrom field is to | address needs to be in the RFC5321.MailFrom field is to | |||
| determine which address must be informed about transfer-level | determine which address is to be informed about transfer-level | |||
| problems (and possibly successes.) | problems (and possibly successes.) | |||
| RFC5321.RcptTo: Set by - Author, Final MTA, MDA. | RFC5321.RcptTo: Set by - Author, Final MTA, MDA. | |||
| This field specifies the MUA mailbox address of a Recipient. | This field specifies the MUA mailbox address of a Recipient. | |||
| The string might not be visible in the message content header. | The string might not be visible in the message content header. | |||
| For example, the IMF destination address header fields, such as | For example, the IMF destination address header fields, such as | |||
| RFC5322.To, might specify a mailing list mailbox, while the | RFC5322.To, might specify a mailing list mailbox, while the | |||
| RFC5321.RcptTo address specifies a member of that list. | RFC5321.RcptTo address specifies a member of that list. | |||
| skipping to change at page 36, line 39 ¶ | skipping to change at page 36, line 39 ¶ | |||
| message, such as by using POP [RFC1939] and IMAP [RFC3501]. | message, such as by using POP [RFC1939] and IMAP [RFC3501]. | |||
| 4.5. Implementation and Operation | 4.5. Implementation and Operation | |||
| A discussion of any interesting system architecture often bogs down | A discussion of any interesting system architecture often bogs down | |||
| when architecture and implementation are confused. An architecture | when architecture and implementation are confused. An architecture | |||
| defines the conceptual functions of a service, divided into discrete | defines the conceptual functions of a service, divided into discrete | |||
| conceptual modules. An implementation of that architecture can | conceptual modules. An implementation of that architecture can | |||
| combine or separate architectural components, as needed for a | combine or separate architectural components, as needed for a | |||
| particular operational environment. For example, a software system | particular operational environment. For example, a software system | |||
| that primarily performs message relaying is an MTA, yet it might | that primarily performs message relaying is an MTA, yet it might also | |||
| also include MDA functionality. That same MTA system might be able | include MDA functionality. That same MTA system might be able to | |||
| to interface with non-Internet email services and thus perform both | interface with non-Internet email services and thus perform both as | |||
| as an MTA and as a Gateway. | an MTA and as a Gateway. | |||
| Similarly, implemented modules might be configured to form | Similarly, implemented modules might be configured to form | |||
| elaborations of the architecture. An interesting example is a | elaborations of the architecture. An interesting example is a | |||
| distributed MS. One portion might be a remote server and another | distributed MS. One portion might be a remote server and another | |||
| might be local to the MUA. As discussed in [RFC1733], there are | might be local to the MUA. As discussed in [RFC1733], there are | |||
| three operational relationships among such MSs: | three operational relationships among such MSs: | |||
| Online: The MS is remote, and messages are accessible only when | Online: The MS is remote, and messages are accessible only when | |||
| the MUA is attached to the MS so that the MUA will re-fetch all | the MUA is attached to the MS so that the MUA will re-fetch all | |||
| or part of a message, from one session to the next. | or part of a message, from one session to the next. | |||
| skipping to change at page 40, line 15 ¶ | skipping to change at page 40, line 15 ¶ | |||
| direct exchange, using their normal MUA Reply functions, while also | direct exchange, using their normal MUA Reply functions, while also | |||
| recording full reference information about the Recipient who served | recording full reference information about the Recipient who served | |||
| as a Mediator. Hence, the new Recipient sees the message as being | as a Mediator. Hence, the new Recipient sees the message as being | |||
| from the original Author, even if the Mediator adds commentary. | from the original Author, even if the Mediator adds commentary. | |||
| Including the core set of message information listed at the beginning | Including the core set of message information listed at the beginning | |||
| of this section, these identities are relevant to a resent message: | of this section, these identities are relevant to a resent message: | |||
| RFC5322.From: Set by - original Author | RFC5322.From: Set by - original Author | |||
| Names and addresses for the original Author of the message | Names and addresses for the original Author of the message | |||
| content are retained. The free-form (display-name) portion of | content are retained. The free-form (display-name) portion of | |||
| the address might be modified to provide informal reference to | the address might be modified to provide informal reference to | |||
| the ReSender. | the ReSender. | |||
| RFC5322.Reply-To: Set by - original Author | RFC5322.Reply-To: Set by - original Author | |||
| If this field is present in the original message, it is | If this field is present in the original message, it is | |||
| retained in the resent message. | retained in the resent message. | |||
| RFC5322.Sender: Set by - Author's Originator or Mediator | RFC5322.Sender: Set by - Author's Originator or Mediator | |||
| skipping to change at page 43, line 17 ¶ | skipping to change at page 43, line 17 ¶ | |||
| RFC5322.From: Set by - original Author | RFC5322.From: Set by - original Author | |||
| Names and addresses for the original Author of the message | Names and addresses for the original Author of the message | |||
| content are retained. As for all original addressing | content are retained. As for all original addressing | |||
| information in the message, the Gateway can translate addresses | information in the message, the Gateway can translate addresses | |||
| as required to continue to be useful in the target environment. | as required to continue to be useful in the target environment. | |||
| RFC5322.Reply-To: Set by - original Author | RFC5322.Reply-To: Set by - original Author | |||
| The Gateway SHOULD retain this information, if it is present. | It is best for a Gateway to retain this information, if it is | |||
| The ability to perform a successful reply by a Recipient is a | present. The ability to perform a successful reply by a | |||
| typical test of Gateway functionality. | Recipient is a typical test of Gateway functionality. | |||
| RFC5322.Sender: Set by - Author Originator or Mediator | RFC5322.Sender: Set by - Author Originator or Mediator | |||
| Originator | Originator | |||
| This field can retain the original value or can be set to a new | This field can retain the original value or can be set to a new | |||
| address. | address. | |||
| RFC5322.To/.CC/.BCC: Set by - original Recipient | RFC5322.To/.CC/.BCC: Set by - original Recipient | |||
| These fields usually retain their original addresses. | These fields usually retain their original addresses. | |||
| skipping to change at page 45, line 50 ¶ | skipping to change at page 45, line 50 ¶ | |||
| encoding is still required for those. | encoding is still required for those. | |||
| o A series of experimental protocols on Email Address | o A series of experimental protocols on Email Address | |||
| Internationalization (EAI) have been released that extend SMTP and | Internationalization (EAI) have been released that extend SMTP and | |||
| IMF to allow for 8-bit encoded characters to appear in addresses | IMF to allow for 8-bit encoded characters to appear in addresses | |||
| and other information throughout the header fields of messages. | and other information throughout the header fields of messages. | |||
| [RFC5335] specifies the format of such message header fields | [RFC5335] specifies the format of such message header fields | |||
| (which encode the characters in UTF-8), and [RFC5336] specifies an | (which encode the characters in UTF-8), and [RFC5336] specifies an | |||
| SMTP option for the transport of these messages. | SMTP option for the transport of these messages. | |||
| o MIME's [RFC2045] and [RFC2046] allow for the transport of true | o MIME's [RFC2045] and [RFC2046] allows for the transport of true | |||
| multimedia material, which has obvious applicability to | multimedia material; such material enables internationalization | |||
| internationalization. | because it is not restricted to any particular language or locale. | |||
| o The formats for delivery status notifications (DSNs--[RFC3462], | o The formats for delivery status notifications (DSNs -- [RFC3462], | |||
| [RFC3463], [RFC3464]) and message disposition notifications | [RFC3463], [RFC3464]) and message disposition notifications (MDNs | |||
| (MDNs--[RFC3798]) include both a structured and unstructured | -- [RFC3798]) include both a structured and unstructured | |||
| representation of the notification. In the event that the | representation of the notification. In the event that the | |||
| unstructured representation is in the wrong language or is | unstructured representation is in the wrong language or is | |||
| otherwise unsuitable for use, this allows an MUA to construct its | otherwise unsuitable for use, this allows an MUA to construct its | |||
| own appropriately localized representation of notification for | own appropriately localized representation of notification for | |||
| display to the user. | display to the user. | |||
| o POP and IMAP do not introduce internationalization issues. | o POP and IMAP have no difficulties with handling MIME messages, | |||
| including ones containing 8bit, and therefore are not a source of | ||||
| of internationalization issues. | ||||
| Hence, the use of UTF-8 is fully established in existing Internet | Hence, the use of UTF-8 is fully established in existing Internet | |||
| mail. However support for long-standing encoding forms is retained | mail. However support for long-standing encoding forms is retained | |||
| and is still used. | and is still used. | |||
| 7. References | 7. References | |||
| 7.1. Normative | 7.1. Normative | |||
| [RFC0791] Postel, J., "Internet Protocol", RFC 791, 1981 September. | [RFC0791] Postel, J., "Internet Protocol", RFC 791, 1981 September. | |||
| skipping to change at page 47, line 5 ¶ | skipping to change at page 47, line 7 ¶ | |||
| November 1996. | November 1996. | |||
| [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | |||
| Part Three: Message Header Extensions for Non-ASCII Text", | Part Three: Message Header Extensions for Non-ASCII Text", | |||
| RFC 2047, November 1996. | RFC 2047, November 1996. | |||
| [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
| Extensions (MIME) Part Five: Conformance Criteria and | Extensions (MIME) Part Five: Conformance Criteria and | |||
| Examples", RFC 2049, November 1996. | Examples", RFC 2049, November 1996. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
| [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS | [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS | |||
| Specification", RFC 2181, July 1997. | Specification", RFC 2181, July 1997. | |||
| [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax | [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax | |||
| for Core Mail List Commands and their Transport through | for Core Mail List Commands and their Transport through | |||
| Message Header Fields", RFC 2369, July 1998. | Message Header Fields", RFC 2369, July 1998. | |||
| [RFC2645] Gellens, R., "On-Demand Mail Relay (ODMR) SMTP with | [RFC2645] Gellens, R., "On-Demand Mail Relay (ODMR) SMTP with | |||
| Dynamic IP Addresses", RFC 2645, August 1999. | Dynamic IP Addresses", RFC 2645, August 1999. | |||
| [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | ||||
| April 2001. | ||||
| [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | ||||
| April 2001. | ||||
| [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field | [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field | |||
| and Namespace for the Identification of Mailing Lists", | and Namespace for the Identification of Mailing Lists", | |||
| RFC 2919, March 2001. | RFC 2919, March 2001. | |||
| [RFC3192] Allocchio, C., "Minimal FAX address format in Internet | [RFC3192] Allocchio, C., "Minimal FAX address format in Internet | |||
| Mail", RFC 3192, October 2001. | Mail", RFC 3192, October 2001. | |||
| [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content | [RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content | |||
| Negotiation for Messaging Services based on Email", | Negotiation for Messaging Services based on Email", | |||
| RFC 3297, July 2002. | RFC 3297, July 2002. | |||
| skipping to change at page 48, line 43 ¶ | skipping to change at page 48, line 37 ¶ | |||
| [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced | [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced | |||
| Mail System Status Codes", RFC 5248, June 2008. | Mail System Status Codes", RFC 5248, June 2008. | |||
| [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | |||
| October 2008. | October 2008. | |||
| [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | |||
| October 2008. | October 2008. | |||
| [RFC5335] Abel, Y., Ed., "Internationalized Email Headers", | ||||
| RFC 5335, September 2008. | ||||
| 7.2. Informative | 7.2. Informative | |||
| [RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, | [RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, | |||
| "Standard for the Format of ARPA Network Text Messages", | "Standard for the Format of ARPA Network Text Messages", | |||
| RFC 733, November 1977. | RFC 733, November 1977. | |||
| [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, | [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, | |||
| RFC 821, August 1982. | RFC 821, August 1982. | |||
| [RFC0822] Crocker, D., "Standard for the format of ARPA Internet | [RFC0822] Crocker, D., "Standard for the format of ARPA Internet | |||
| skipping to change at page 49, line 42 ¶ | skipping to change at page 49, line 33 ¶ | |||
| [RFC2442] Freed, N., Newman, D., Belissen, J., and M. Hoy, "The | [RFC2442] Freed, N., Newman, D., Belissen, J., and M. Hoy, "The | |||
| Batch SMTP Media Type", RFC 2442, November 1998. | Batch SMTP Media Type", RFC 2442, November 1998. | |||
| [RFC2480] Freed, N., "Gateways and MIME Security Multiparts", | [RFC2480] Freed, N., "Gateways and MIME Security Multiparts", | |||
| RFC 2480, January 1999. | RFC 2480, January 1999. | |||
| [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", | [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", | |||
| RFC 2505, February 1999. | RFC 2505, February 1999. | |||
| [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | ||||
| April 2001. | ||||
| [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | ||||
| April 2001. | ||||
| [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | |||
| Transport Layer Security", RFC 3207, February 2002. | Transport Layer Security", RFC 3207, February 2002. | |||
| [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format | [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format | |||
| for Delivery Status Notifications", RFC 3464, | for Delivery Status Notifications", RFC 3464, | |||
| January 2003. | January 2003. | |||
| [RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest | [RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest | |||
| Extensions", RFC 3685, February 2004. | Extensions", RFC 3685, February 2004. | |||
| skipping to change at page 50, line 32 ¶ | skipping to change at page 50, line 29 ¶ | |||
| [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. | [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. | |||
| Thayer, "OpenPGP Message Format", RFC 4880, November 2007. | Thayer, "OpenPGP Message Format", RFC 4880, November 2007. | |||
| [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service | [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service | |||
| Extension for Authentication", RFC 4954, July 2007. | Extension for Authentication", RFC 4954, July 2007. | |||
| [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and | [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and | |||
| E. Allman, "Email Submission Operations: Access and | E. Allman, "Email Submission Operations: Access and | |||
| Accountability Requirements", RFC 5068, BCP 134, Nov 2007. | Accountability Requirements", RFC 5068, BCP 134, Nov 2007. | |||
| [RFC5335] Abel, Y., Ed., "Internationalized Email Headers", | ||||
| RFC 5335, September 2008. | ||||
| [RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for | [RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for | |||
| Internationalized Email Addresses", RFC 5336, | Internationalized Email Addresses", RFC 5336, | |||
| September 2008. | September 2008. | |||
| [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, | [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, | |||
| "Tussle in Cyberspace: Defining Tomorrow's Internet", | "Tussle in Cyberspace: Defining Tomorrow's Internet", | |||
| ACM SIGCOMM, 2002. | ACM SIGCOMM, 2002. | |||
| Appendix A. Acknowledgements | Appendix A. Acknowledgements | |||
| This work began in 2004 and has evolved through numerous rounds of | This work began in 2004 and has evolved through numerous rounds of | |||
| community review; it derives from a section in an early version of | community review; it derives from a section in an early version of | |||
| [RFC5068]. Over its 5 years of development, the draft has gone | [RFC5068]. Over its 5 years of development, the draft has gone | |||
| through 13 incremental versions, with vigorous community review that | through 14 incremental versions, with vigorous community review that | |||
| produced many substantive changes. Review was performed in the IETF | produced many substantive changes. Review was performed in the IETF | |||
| and other email technical venues. Although not a formal activity of | and other email technical venues. Although not a formal activity of | |||
| the IETF, issues with the document's contents were resolved using the | the IETF, issues with the document's contents were resolved using the | |||
| classic style of IETF community open, group decision-making. The | classic style of IETF community open, group decision-making. The | |||
| document is already cited in other work, such as for IMAP and Sieve | document is already cited in other work, such as for IMAP and Sieve | |||
| specifications and for academic classwork. The step of standardizing | specifications and for academic classwork. The step of standardizing | |||
| is useful to provide a solid and stable reference to the Internet's | is useful to provide a solid and stable reference to the Internet's | |||
| now-complex email service. | now-complex email service. | |||
| Details of the Originator actor role was greatly clarified during | Details of the Originator actor role was greatly clarified during | |||
| skipping to change at page 51, line 27 ¶ | skipping to change at page 51, line 27 ¶ | |||
| Later reviews and suggestions were provided by Eric Allman, Nathaniel | Later reviews and suggestions were provided by Eric Allman, Nathaniel | |||
| Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, | Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, | |||
| Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John | Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John | |||
| Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, | Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, | |||
| Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. | Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. | |||
| Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg | Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg | |||
| Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani, and Hans | Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani, and Hans | |||
| Lachman. | Lachman. | |||
| Diligent early proof-reading was performed by Bruce Lilly. Diligent | Diligent early proof-reading was performed by Bruce Lilly. Diligent | |||
| technical editing was provided by Susan Hunziker. | professional technical editing was provided by Susan Hunziker. | |||
| The final stages of development for this document were guided by a | The final stages of development for this document were guided by a | |||
| design team comprising: Alexey Melnikov, Pete Resnick, Carl S. | design team comprising: Alexey Melnikov, Pete Resnick, Carl S. | |||
| Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen and Tony | Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen and Tony | |||
| Finch. Pete Resnick developed the final version of the section on | Finch. Pete Resnick developed the final version of the section on | |||
| internationalization. | internationalization. | |||
| Index | Index | |||
| 13 | 12 | |||
| 7 | 7 | |||
| 7-bit 46 | 7-bit 46 | |||
| A | A | |||
| accountability 14 | accountability 13 | |||
| accountable 14-15 | accountable 14-15 | |||
| Actor | Actor | |||
| Administrative 15 | Administrative 15 | |||
| Author 10 | Author 11 | |||
| Consumer 16 | Consumer 16 | |||
| Edge 16 | Edge 16 | |||
| Gateway 15 | Gateway 15 | |||
| Originator 13 | Originator 13 | |||
| Recipient 11 | Recipient 11 | |||
| Return Handler 11 | Return Handler 11 | |||
| Transit 16 | Transit 16 | |||
| Actors | Actors | |||
| MHS 12 | MHS 12 | |||
| ADMD 14-16, 20, 26, 32, 39 | ADMD 13, 15-16, 20, 26, 32, 39 | |||
| Administrative Actors 15 | Administrative Actors 15 | |||
| Administrative Management Domain 14 | Administrative Management Domain 13 | |||
| aMSA 32 | aMSA 32 | |||
| Author 10, 13 | Author 11-12 | |||
| author 36 | author 36 | |||
| B | B | |||
| body-parts 25 | body-parts 25 | |||
| bounce handler 11 | bounce handler 11 | |||
| boundary 16 | boundary 16 | |||
| C | C | |||
| charset 46 | charset 46 | |||
| Consumer Actor 16 | Consumer Actor 16 | |||
| content 12, 14-15, 21, 25, 33 | content 12, 14-15, 21, 25, 33 | |||
| D | D | |||
| delivery 5, 11, 13-15, 19, 25-26, 36, 39 | delivery 5, 11-12, 14-15, 19, 25-26, 36, 39 | |||
| Discussion of document 8 | Discussion of document 8 | |||
| DSN 46 | DSN 46 | |||
| E | E | |||
| EAI 46 | EAI 46 | |||
| Edge Actor 16 | Edge Actor 16 | |||
| encoding 46 | encoding 46 | |||
| end-to-end 5 | end-to-end 5 | |||
| envelope 11, 14, 22, 25-26, 33, 39 | envelope 12, 14, 22, 25-26, 33, 39 | |||
| ETRN 36 | ETRN 36 | |||
| G | G | |||
| Gateway 12, 15 | Gateway 12, 15 | |||
| H | H | |||
| header 25 | header 25 | |||
| hMSA 32 | hMSA 32 | |||
| I | I | |||
| skipping to change at page 53, line 20 ¶ | skipping to change at page 53, line 20 ¶ | |||
| Mail Submission Agent 13 | Mail Submission Agent 13 | |||
| mailbox 39 | mailbox 39 | |||
| MDA 25, 39 | MDA 25, 39 | |||
| MDN 11, 25, 46 | MDN 11, 25, 46 | |||
| message 7, 25 | message 7, 25 | |||
| Message Disposition Notification 11 | Message Disposition Notification 11 | |||
| Message Handling Service 5 | Message Handling Service 5 | |||
| Message Handling System 12 | Message Handling System 12 | |||
| Message Transfer Agent 5 | Message Transfer Agent 5 | |||
| Message User Agent 5 | Message User Agent 5 | |||
| MHS 5, 11-12, 14, 22-23, 25-26 | MHS 5, 11-14, 22-23, 25-26 | |||
| Actors 12 | Actors 12 | |||
| MIME 25, 46 | MIME 25, 46 | |||
| MS 25 | MS 25 | |||
| MSA 13, 25, 32 | MSA 13, 25, 32 | |||
| MTA 5, 16 | MTA 5, 16 | |||
| boundary 16 | boundary 16 | |||
| MUA 5, 15, 25, 31-32 | MUA 5, 15, 25, 31-32 | |||
| O | O | |||
| ODMR 36 | ODMR 36 | |||
| Originator 11, 13 | Originator 11-13 | |||
| P | P | |||
| POP 25, 32, 35-36, 46 | POP 25, 32, 35-36, 46 | |||
| posting 5, 11, 13, 22, 31-32, 36, 39 | posting 5, 11, 13, 22, 31-32, 36, 39 | |||
| pull 36 | pull 36 | |||
| push 36 | push 36 | |||
| R | R | |||
| RcptTo 12 | RcptTo 12 | |||
| Receiver 13 | Receiver 12 | |||
| Recipient 11, 13, 39 | Recipient 11-12, 39 | |||
| recipient 36 | recipient 36 | |||
| relay 13 | relay 12 | |||
| responsibility 32 | responsibility 32 | |||
| responsible 14-15 | responsible 14-15 | |||
| Return address 39 | Return address 39 | |||
| Return Handler 11 | Return Handler 11 | |||
| role 11, 19 | role 12, 19 | |||
| Author 10 | Author 11 | |||
| Originator 13 | Originator 13 | |||
| Recipient 11 | Recipient 11 | |||
| S | S | |||
| SIEVE 25-26 | SIEVE 25-26 | |||
| SMTP 25, 36, 46 | SMTP 25, 36, 46 | |||
| T | T | |||
| transfer 13-15 | transfer 12, 14-15 | |||
| Transit Actor 16 | Transit Actor 16 | |||
| transition 32 | transition 32 | |||
| U | U | |||
| UA 5 | UA 5 | |||
| User Agent 5 | User Agent 5 | |||
| Author's Address | Author's Address | |||
| Dave Crocker | Dave Crocker | |||
| End of changes. 65 change blocks. | ||||
| 246 lines changed or deleted | 249 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||