Passa al contenuto principale

RFC 5598 - Internet Mail Architecture

  • Stato: Informational
  • Pubblicato: July 2009
  • Stream: IETF
  • Errata: Nessun errata

Status of This Memo​

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Questo memo fornisce informazioni per la comunità Internet. Non specifica alcuno standard Internet di alcun tipo. La distribuzione di questo memo è illimitata.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2009 IETF Trust e le persone identificate come autori del documento. Tutti i diritti riservati.

Abstract​

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service.

Nel corso della sua storia di trentacinque anni, la posta Internet è cambiata significativamente in scala e complessità, diventando un servizio infrastrutturale globale. Questi cambiamenti sono stati evolutivi, piuttosto che rivoluzionari, riflettendo un forte desiderio di preservare sia la sua base installata che la sua utilità. Per collaborare in modo produttivo su questo sistema ampio e complesso, tutti i partecipanti devono lavorare da una visione comune di esso e utilizzare un linguaggio comune per descrivere i suoi componenti e le interazioni tra di essi. Ma le molte differenze di prospettiva attualmente rendono difficile sapere esattamente cosa intende un altro partecipante. Per servire come necessario quadro di riferimento comune, questo documento descrive l'architettura migliorata della posta Internet, riflettendo il servizio attuale.

1. Introduction​

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. Today, Internet Mail is distinguished by many independent operators, many different components for providing service to Users, as well as many different components that transfer messages.

Nel corso della sua storia di trentacinque anni, la posta Internet è cambiata significativamente in scala e complessità, diventando un servizio infrastrutturale globale. Questi cambiamenti sono stati evolutivi, piuttosto che rivoluzionari, riflettendo un forte desiderio di preservare sia la sua base installata che la sua utilità. Oggi, la posta Internet si distingue per molti operatori indipendenti, molti componenti diversi per fornire servizi agli utenti, nonché molti componenti diversi che trasferiscono messaggi.

The underlying technical standards for Internet Mail comprise a rich array of functional capabilities. These specifications form the core:

Gli standard tecnici sottostanti per la posta Internet comprendono una ricca gamma di capacità funzionali. Queste specifiche formano il nucleo:

  • Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) moves a message through the Internet.

  • Il Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) sposta un messaggio attraverso Internet.

  • Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) defines a message object.

  • L'Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) definisce un oggetto messaggio.

  • Multipurpose Internet Mail Extensions (MIME) [RFC2045] defines an enhancement to the message object that permits using multimedia attachments.

  • Le Multipurpose Internet Mail Extensions (MIME) [RFC2045] definiscono un miglioramento all'oggetto messaggio che consente l'uso di allegati multimediali.

Public collaboration on technical, operations, and policy activities of email, including those that respond to the challenges of email abuse, has brought a much wider range of participants into the technical community. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means.

La collaborazione pubblica sulle attività tecniche, operative e politiche dell'email, comprese quelle che rispondono alle sfide dell'abuso di email, ha portato una gamma molto più ampia di partecipanti nella comunità tecnica. Per collaborare in modo produttivo su questo sistema ampio e complesso, tutti i partecipanti devono lavorare da una visione comune di esso e utilizzare un linguaggio comune per descrivere i suoi componenti e le interazioni tra di essi. Ma le molte differenze di prospettiva attualmente rendono difficile sapere esattamente cosa intende un altro partecipante.

It is the need to resolve these differences that motivates this document, which describes the realities of the current system. Internet Mail is the subject of ongoing technical, operations, and policy work, and the discussions often are hindered by different models of email-service design and different meanings for the same terms.

È la necessità di risolvere queste differenze che motiva questo documento, che descrive le realtà del sistema attuale. La posta Internet è oggetto di lavori tecnici, operativi e politici in corso, e le discussioni sono spesso ostacolate da diversi modelli di progettazione del servizio email e diversi significati per gli stessi termini.

To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. The document focuses on:

Per servire come necessario quadro di riferimento comune, questo documento descrive l'architettura migliorata della posta Internet, riflettendo il servizio attuale. Il documento si concentra su:

  • Capturing refinements to the email model

  • Catturare i perfezionamenti al modello di posta elettronica

  • Clarifying functional roles for the architectural components

  • Chiarire i ruoli funzionali per i componenti architetturali

  • Clarifying identity-related issues, across the email service

  • Chiarire le questioni relative all'identità, attraverso il servizio email

  • Defining terminology for architectural components and their interactions

  • Definire la terminologia per i componenti architetturali e le loro interazioni

1.1. History​

The first standardized architecture for networked email specified a simple split between the user world, in the form of Message User Agents (MUAs), and the transfer world, in the form of the Message Handling Service (MHS), which is composed of Message Transfer Agents (MTAs) [RFC1506]. The MHS accepts a message from one User and delivers it to one or more other Users, creating a virtual MUA-to-MUA exchange environment.

La prima architettura standardizzata per l'email in rete specificava una semplice divisione tra il mondo utente, sotto forma di Message User Agents (MUA), e il mondo del trasferimento, sotto forma di Message Handling Service (MHS), che è composto da Message Transfer Agents (MTA) [RFC1506]. L'MHS accetta un messaggio da un utente e lo consegna a uno o più altri utenti, creando un ambiente di scambio virtuale MUA-to-MUA.

As shown in Figure 1, this architecture defines two logical layers of interoperability. One is directly between Users. The other is among the components along the transfer path. In addition, there is interoperability between the layers, first when a message is posted from the User to the MHS and later when it is delivered from the MHS to the User.

Come mostrato nella Figura 1, questa architettura definisce due livelli logici di interoperabilità. Uno è direttamente tra gli utenti. L'altro è tra i componenti lungo il percorso di trasferimento. Inoltre, c'è interoperabilità tra i livelli, prima quando un messaggio viene inviato dall'utente all'MHS e successivamente quando viene consegnato dall'MHS all'utente.

The operational service has evolved, although core aspects of the service, such as mailbox addressing and message format style, remain remarkably constant. The original distinction between the user level and transfer level remains, but with elaborations in each. The term "Internet Mail" is used to refer to the entire collection of user and transfer components and services.

Il servizio operativo si è evoluto, sebbene gli aspetti fondamentali del servizio, come l'indirizzamento della casella di posta e lo stile del formato del messaggio, rimangano notevolmente costanti. La distinzione originale tra livello utente e livello di trasferimento rimane, ma con elaborazioni in ciascuno. Il termine "Internet Mail" viene utilizzato per riferirsi all'intera raccolta di componenti e servizi utente e di trasferimento.

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 of the MHS. A common exception is group dialogue that is mediated through a Mailing List; in this case, two postings occur before intended Recipients receive an Author's message, as discussed in Section 2.1.4. In fact, some uses of email consider the entire email service, including Author and Recipient, as a subordinate component. For these services, "end-to-end" refers to points outside the email service. Examples are voicemail over email [RFC3801], EDI (Electronic Data Interchange) over email [RFC1767], and facsimile over email [RFC4142].

Per la posta Internet, il termine "end-to-end" si riferisce solitamente a un singolo invio e all'insieme di consegne che risultano da un singolo transito dell'MHS. Un'eccezione comune è il dialogo di gruppo mediato attraverso una Mailing List; in questo caso, due invii si verificano prima che i destinatari previsti ricevano il messaggio di un autore, come discusso nella Sezione 2.1.4. Infatti, alcuni usi dell'email considerano l'intero servizio email, inclusi Autore e Destinatario, come un componente subordinato. Per questi servizi, "end-to-end" si riferisce a punti al di fuori del servizio email. Esempi sono la segreteria telefonica via email [RFC3801], EDI (Electronic Data Interchange) via email [RFC1767] e fax via email [RFC4142].

                                         +--------+
                      ++================>|  User  |
                      ||                 +--------+
                      ||                      ^
          +--------+  ||          +--------+  .
          |  User  +==++=========>|  User  |  .
          +---+----+  ||          +--------+  .
              .       ||               ^      .
              .       ||   +--------+  .      .
              .       ++==>|  User  |  .      .
              .            +--------+  .      .
              .                 ^      .      .
              .                 .      .      .
              V                 .      .      .
          +---+-----------------+------+------+---+
          |   .                 .      .      .   |
          |   .................>.      .      .   |
          |   .                        .      .   |
          |   ........................>.      .   |
          |   .                               .   |
          |   ...............................>.   |
          |                                       |
          |     Message Handling Service (MHS)    |
          +---------------------------------------+
          
          Legend: === lines indicate primary (possibly indirect)
                      transfers or roles
                  ... lines indicate supporting transfers or roles

                Figure 1: Basic Internet Mail Service Model

End-to-end Internet Mail exchange is accomplished by using a standardized infrastructure with these components and characteristics:

Lo scambio di posta Internet end-to-end è realizzato utilizzando un'infrastruttura standardizzata con questi componenti e caratteristiche:

  • An email object

  • Un oggetto email

  • Global addressing

  • Indirizzamento globale

  • An asynchronous sequence of point-to-point transfer mechanisms

  • Una sequenza asincrona di meccanismi di trasferimento punto-punto

  • No requirement for prior arrangement between MTAs or between Authors and Recipients

  • Nessun requisito per accordi preventivi tra MTA o tra Autori e Destinatari

  • No requirement for prior arrangement between point-to-point transfer services over the open Internet

  • Nessun requisito per accordi preventivi tra servizi di trasferimento punto-punto su Internet aperto

  • No requirement for Author, Originator, or Recipients to be online at the same time

  • Nessun requisito per Autore, Originatore o Destinatari di essere online contemporaneamente

The end-to-end portion of the service is the email object, called a "message". Broadly, the message itself distinguishes control information, for handling, from the Author's content.

La parte end-to-end del servizio è l'oggetto email, chiamato "messaggio". In generale, il messaggio stesso distingue le informazioni di controllo, per la gestione, dal contenuto dell'Autore.

A precept to the design of mail over the open Internet is permitting User-to-User and MTA-to-MTA interoperability without prior, direct arrangement between the independent administrative authorities responsible for handling a message. All participants rely on having the core services universally supported and accessible, either directly or through Gateways that act as translators between Internet Mail and email environments conforming to other standards. Given the importance of spontaneity and serendipity in interpersonal communications, not requiring such prearrangement between participants is a core benefit of Internet Mail and remains a core requirement for it.

Un precetto per la progettazione della posta su Internet aperto è consentire l'interoperabilità User-to-User e MTA-to-MTA senza accordi diretti preventivi tra le autorità amministrative indipendenti responsabili della gestione di un messaggio. Tutti i partecipanti fanno affidamento sull'avere i servizi principali universalmente supportati e accessibili, direttamente o attraverso Gateway che agiscono come traduttori tra Internet Mail e ambienti email conformi ad altri standard. Data l'importanza della spontaneità e della serendipità nelle comunicazioni interpersonali, non richiedere tale accordo preventivo tra i partecipanti è un vantaggio fondamentale di Internet Mail e rimane un requisito fondamentale per esso.

Within localized networks at the edge of the public Internet, prior administrative arrangement often is required and can include access control, routing constraints, and configuration of the information query service. Although Recipient authentication has usually been required for message access since the beginning of Internet Mail, in recent years it also has been required for message submission. In these cases, a server validates the client's identity, whether by explicit security protocols or by implicit infrastructure queries to identify "local" participants.

All'interno di reti localizzate ai margini di Internet pubblico, spesso è richiesto un accordo amministrativo preventivo e può includere controllo degli accessi, vincoli di routing e configurazione del servizio di interrogazione delle informazioni. Sebbene l'autenticazione del Destinatario sia stata solitamente richiesta per l'accesso ai messaggi sin dall'inizio di Internet Mail, negli ultimi anni è stata richiesta anche per l'invio di messaggi. In questi casi, un server convalida l'identità del client, sia tramite protocolli di sicurezza espliciti che tramite query infrastrutturali implicite per identificare i partecipanti "locali".

1.2. The Role of This Architecture​

An Internet service is an integration of related capabilities among two or more participating nodes. The capabilities are accomplished across the Internet by one or more protocols. What connects a protocol to a service is an architecture. An architecture specifies how the protocols implement the service by defining the logical components of a service and the relationships among them. From that logical view, a service defines what is being done, an architecture defines where the pieces are (in relation to each other), and a protocol defines how particular capabilities are performed.

Un servizio Internet è un'integrazione di capacità correlate tra due o più nodi partecipanti. Le capacità sono realizzate attraverso Internet da uno o più protocolli. Ciò che collega un protocollo a un servizio è un'architettura. Un'architettura specifica come i protocolli implementano il servizio definendo i componenti logici di un servizio e le relazioni tra di essi. Da quella visione logica, un servizio definisce cosa viene fatto, un'architettura definisce dove si trovano i pezzi (in relazione l'uno all'altro) e un protocollo definisce come vengono eseguite particolari capacità.

As such, an architecture will more formally describe a service at a relatively high level. A protocol that implements some portion of a service will conform to the architecture to a greater or lesser extent, depending on the pragmatic tradeoffs they make when trying to implement the architecture in the context of real-world constraints. Failure to precisely follow an architecture is not a failure of the protocol, nor is failure to precisely cast a protocol a failure of the architecture. Where a protocol varies from the architecture, it will of course be appropriate for it to explain the reason for the variance. However, such variance is not a mark against a protocol: Happily, the IETF prefers running code to architectural purity.

Come tale, un'architettura descriverà più formalmente un servizio a un livello relativamente alto. Un protocollo che implementa una parte di un servizio si conformerà all'architettura in misura maggiore o minore, a seconda dei compromessi pragmatici che fanno quando cercano di implementare l'architettura nel contesto dei vincoli del mondo reale. Il mancato rispetto preciso di un'architettura non è un fallimento del protocollo, né il mancato rispetto preciso di un protocollo è un fallimento dell'architettura. Laddove un protocollo varia dall'architettura, sarà ovviamente appropriato spiegarne il motivo. Tuttavia, tale varianza non è un segno contro un protocollo: fortunatamente, l'IETF preferisce il codice in esecuzione alla purezza architettonica.

In this particular case, this architecture attempts to define the logical components of Internet email and does so post hoc, trying to capture the architectural principles that the current email protocols embody. To different extents, email protocols will conform to this architecture more or less well. Insofar as this architecture differs from those protocols, the reasons are generally well understood and are required for interoperation. The differences are not a sign that protocols need to be fixed. However, this architecture is a best attempt at a logical model of Internet email, and insofar as new protocol development varies from this architecture, it is necessary for designers to understand those differences and explain them carefully.

In questo caso particolare, questa architettura tenta di definire i componenti logici dell'email Internet e lo fa post hoc, cercando di catturare i principi architettonici che i protocolli email attuali incarnano. In misura diversa, i protocolli email si conformeranno a questa architettura più o meno bene. Nella misura in cui questa architettura differisce da quei protocolli, le ragioni sono generalmente ben comprese e sono richieste per l'interoperabilità. Le differenze non sono un segno che i protocolli debbano essere corretti. Tuttavia, questa architettura è un miglior tentativo di un modello logico di email Internet e, nella misura in cui il nuovo sviluppo del protocollo varia da questa architettura, è necessario che i progettisti comprendano tali differenze e le spieghino attentamente.

1.3. Document Conventions​

References to structured fields of a message use a two-part dotted notation. The first part cites the document that contains the specification for the field, and the second part is the name of the field. Hence <RFC5322.From> is the IMF From: header field in an email content header, and <RFC5321.MailFrom> is the address in the SMTP "Mail From" command.

I riferimenti ai campi strutturati di un messaggio utilizzano una notazione punteggiata in due parti. La prima parte cita il documento che contiene la specifica per il campo e la seconda parte è il nome del campo. Quindi <RFC5322.From> è il campo dell'intestazione IMF From: in un'intestazione del contenuto dell'email e <RFC5321.MailFrom> è l'indirizzo nel comando SMTP "Mail From".

When occurring without the IMF (RFC 5322) qualifier, header field names are shown with a colon suffix. For example, From:.

Quando si verificano senza il qualificatore IMF (RFC 5322), i nomi dei campi dell'intestazione vengono mostrati con un suffisso due punti. Ad esempio, From:.

References to labels for actors, functions or components have the first letter capitalized.

I riferimenti alle etichette per attori, funzioni o componenti hanno la prima lettera maiuscola.

6. Considerations​

6. Considerazioni​

6.1. Security Considerations​

6.1. Considerazioni sulla sicurezza​

This document describes the existing Internet Mail architecture. It introduces no new capabilities. The security considerations of this deployed architecture are documented extensively in the technical specifications referenced by this document. These specifications cover classic security topics, such as authentication and privacy. For example, email-transfer protocols can use standardized mechanisms for operation over authenticated and/or encrypted links, and message content has similar protection standards available. Examples of such mechanisms include SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880], and S/MIME [RFC3851].

Questo documento descrive l'architettura esistente della posta Internet. Non introduce nuove funzionalità. Le considerazioni sulla sicurezza di questa architettura distribuita sono ampiamente documentate nelle specifiche tecniche citate in questo documento. Queste specifiche coprono argomenti classici di sicurezza, come l'autenticazione e la privacy. Ad esempio, i protocolli di trasferimento della posta elettronica possono utilizzare meccanismi standardizzati per il funzionamento su collegamenti autenticati e/o crittografati e il contenuto dei messaggi dispone di standard di protezione simili. Esempi di tali meccanismi includono SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880] e S/MIME [RFC3851].

The core of the Internet Mail architecture does not impose any security requirements or functions on the end-to-end or hop-by-hop components. For example, it does not require participant authentication and does not attempt to prevent data disclosure.

Il nucleo dell'architettura Internet Mail non impone requisiti o funzioni di sicurezza ai componenti end-to-end o hop-by-hop. Ad esempio, non richiede l'autenticazione dei partecipanti e non tenta di impedire la divulgazione dei dati.

Particular message attributes might expose specific security considerations. For example, the blind carbon copy feature of the architecture invites disclosure concerns, as discussed in Section 7.2 of [RFC5321] and Section 5 of [RFC5322]. Transport of text or non-text content in this architecture has security considerations that are discussed in [RFC5322], [RFC2045], [RFC2046], and [RFC4288]; also, security considerations are present for some of the media types registered with IANA.

Particolari attributi del messaggio potrebbero esporre specifiche considerazioni di sicurezza. Ad esempio, la funzionalità di copia per conoscenza nascosta (blind carbon copy) dell'architettura invita a preoccupazioni sulla divulgazione, come discusso nella sezione 7.2 della [RFC5321] e nella sezione 5 della [RFC5322]. Il trasporto di contenuto testuale o non testuale in questa architettura presenta considerazioni sulla sicurezza discusse in [RFC5322], [RFC2045], [RFC2046] e [RFC4288]; inoltre, sono presenti considerazioni sulla sicurezza per alcuni dei tipi di media registrati presso la IANA.

Agents that automatically respond to email raise significant security considerations, as discussed in [RFC3834]. Gateway behaviors affect end-to-end security services, as discussed in [RFC2480]. Security considerations for boundary filters are discussed in [RFC5228].

Gli agenti che rispondono automaticamente alla posta elettronica sollevano importanti considerazioni sulla sicurezza, come discusso nella [RFC3834]. I comportamenti del gateway influenzano i servizi di sicurezza end-to-end, come discusso nella [RFC2480]. Le considerazioni sulla sicurezza per i filtri di confine sono discusse nella [RFC5228].

See Section 7.1 of [RFC5321] for a discussion of the topic of origination validation. As mentioned in Section 4.1.4, it is common practice for components of this architecture to use the RFC0791.SourceAddr to make policy decisions [RFC2505], although the address can be "spoofed". It is possible to use it without authorization. SMTP and Submission authentication ([RFC4409], [RFC4954]) provide more secure alternatives.

Vedere la sezione 7.1 della [RFC5321] per una discussione sull'argomento della convalida dell'origine. Come menzionato nella Sezione 4.1.4, è pratica comune per i componenti di questa architettura utilizzare RFC0791.SourceAddr per prendere decisioni politiche [RFC2505], sebbene l'indirizzo possa essere "spoofato". È possibile utilizzarlo senza autorizzazione. L'autenticazione SMTP e di invio ([RFC4409], [RFC4954]) fornisce alternative più sicure.

The discussion of trust boundaries, ADMDs, Actors, roles, and responsibilities in this document highlights the relevance and potential complexity of security factors for operation of an Internet Mail service. The core design of Internet Mail to encourage open and casual exchange of messages has met with scaling challenges, as the population of email participants has grown to include those with problematic practices. For example, spam, as defined in [RFC2505], is a by-product of this architecture. A number of Standards Track or BCP documents on the subject have been issued (see [RFC2505], [RFC5068], and [RFC5235]).

La discussione sui confini di fiducia, ADMD, attori, ruoli e responsabilità in questo documento evidenzia la rilevanza e la potenziale complessità dei fattori di sicurezza per il funzionamento di un servizio di posta Internet. La progettazione principale di Internet Mail per incoraggiare lo scambio aperto e informale di messaggi ha incontrato sfide di scalabilità, poiché la popolazione dei partecipanti alla posta elettronica è cresciuta fino a includere coloro con pratiche problematiche. Ad esempio, lo spam, come definito nella [RFC2505], è un sottoprodotto di questa architettura. Sono stati pubblicati numerosi documenti Standards Track o BCP sull'argomento (vedere [RFC2505], [RFC5068] e [RFC5235]).

6.2. Internationalization​

6.2. Internazionalizzazione​

The core Internet email standards are based on the use of US-ASCII -- that is, SMTP [RFC5321] and IMF [RFC5322], as well as their predecessors. They describe the transport and composition of messages as composed strictly of US-ASCII 7-bit encoded characters. The standards have been incrementally enhanced to allow for characters outside of this limited set, while retaining mechanisms for backwards-compatibility. Specifically:

Gli standard principali della posta elettronica Internet si basano sull'uso di US-ASCII, ovvero SMTP [RFC5321] e IMF [RFC5322], nonché i loro predecessori. Descrivono il trasporto e la composizione dei messaggi composti rigorosamente da caratteri codificati US-ASCII a 7 bit. Gli standard sono stati incrementati in modo incrementale per consentire caratteri al di fuori di questo set limitato, pur mantenendo i meccanismi per la retrocompatibilità. Nello specifico:

  • The MIME specifications ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) allow for the use of coded character sets and character-encoding schemes ("charsets" in MIME terminology) other than US-ASCII. MIME's [RFC2046] allows the textual content of a message to have a label affixed that specifies the charset used in that content. Equally, MIME's [RFC2047] allows the textual content of certain header fields in a message to be similarly labeled. However, since messages might be transported over SMTP implementations only capable of transporting 7-bit encoded characters, MIME's [RFC2045] also provides for "content transfer encoding" so that characters of other charsets can be re-encoded as an overlay to US-ASCII.

  • Le specifiche MIME ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) consentono l'uso di set di caratteri codificati e schemi di codifica dei caratteri ("charsets" nella terminologia MIME) diversi da US-ASCII. La [RFC2046] di MIME consente al contenuto testuale di un messaggio di avere un'etichetta apposta che specifica il set di caratteri utilizzato in quel contenuto. Allo stesso modo, la [RFC2047] di MIME consente di etichettare in modo simile il contenuto testuale di alcuni campi di intestazione in un messaggio. Tuttavia, poiché i messaggi potrebbero essere trasportati su implementazioni SMTP in grado di trasportare solo caratteri codificati a 7 bit, la [RFC2045] di MIME prevede anche la "codifica di trasferimento del contenuto" in modo che i caratteri di altri set di caratteri possano essere ricodificati come sovrapposizione a US-ASCII.

  • MIME's [RFC2045] allows for the textual content of a message to be in an 8-bit character-encoding scheme. In order to transport these without re-encoding them, the SMTP specification supports an option [RFC1652] that permits the transport of such textual content. However, the [RFC1652] option does not address the use of 8-bit content in message header fields, and therefore [RFC2047] encoding is still required for those.

  • La [RFC2045] di MIME consente che il contenuto testuale di un messaggio sia in uno schema di codifica dei caratteri a 8 bit. Per trasportarli senza ricodificarli, la specifica SMTP supporta un'opzione [RFC1652] che consente il trasporto di tale contenuto testuale. Tuttavia, l'opzione [RFC1652] non affronta l'uso di contenuto a 8 bit nei campi di intestazione del messaggio e pertanto la codifica [RFC2047] è ancora richiesta per quelli.

  • A series of experimental protocols on Email Address Internationalization (EAI) have been released that extend SMTP and IMF to allow for 8-bit encoded characters to appear in addresses and other information throughout the header fields of messages. [RFC5335] specifies the format of such message header fields (which encode the characters in UTF-8), and [RFC5336] specifies an SMTP option for the transport of these messages.

  • È stata rilasciata una serie di protocolli sperimentali sull'internazionalizzazione degli indirizzi e-mail (EAI) che estendono SMTP e IMF per consentire ai caratteri codificati a 8 bit di apparire negli indirizzi e in altre informazioni in tutti i campi di intestazione dei messaggi. La [RFC5335] specifica il formato di tali campi di intestazione del messaggio (che codificano i caratteri in UTF-8) e la [RFC5336] specifica un'opzione SMTP per il trasporto di questi messaggi.

  • MIME's [RFC2045] and [RFC2046] allow for the transport of true multimedia material; such material enables internationalization because it is not restricted to any particular language or locale.

  • La [RFC2045] e la [RFC2046] di MIME consentono il trasporto di vero materiale multimediale; tale materiale consente l'internazionalizzazione perché non è limitato a nessuna lingua o locale particolare.

  • The formats for Delivery Status Notifications (DSNs -- [RFC3462], [RFC3463], [RFC3464]) and Message Disposition Notifications (MDNs -- [RFC3798]) include both a structured and unstructured representation of the notification. In the event that the unstructured representation is in the wrong language or is otherwise unsuitable for use, this allows an MUA to construct its own appropriately localized representation of notification for display to the User.

  • I formati per le notifiche sullo stato di consegna (DSN -- [RFC3462], [RFC3463], [RFC3464]) e le notifiche sulla disposizione dei messaggi (MDN -- [RFC3798]) includono sia una rappresentazione strutturata che non strutturata della notifica. Nel caso in cui la rappresentazione non strutturata sia nella lingua sbagliata o sia altrimenti inadatta all'uso, ciò consente a un MUA di costruire la propria rappresentazione localizzata in modo appropriato della notifica per la visualizzazione all'utente.

  • POP and IMAP have no difficulties with handling MIME messages, including ones containing 8bit, and therefore are not a source of internationalization issues.

  • POP e IMAP non hanno difficoltà a gestire i messaggi MIME, inclusi quelli contenenti 8 bit, e pertanto non sono una fonte di problemi di internazionalizzazione.

Hence, the use of UTF-8 is fully established in existing Internet Mail. However, support for long-standing encoding forms is retained and is still used.

Pertanto, l'uso di UTF-8 è completamente stabilito nella posta Internet esistente. Tuttavia, il supporto per le forme di codifica di lunga data viene mantenuto ed è ancora utilizzato.

7. References​

7. Riferimenti​

7.1. Normative References​

7.1. Riferimenti normativi​

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.

[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.

[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999.

[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.

[RFC3192] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.

[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.

[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.

[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

[RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.

[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.

[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, March 2005.

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.

[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.

[RFC4550] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.

[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.

[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

7.2. Informative References​

7.2. Riferimenti informativi​

[RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, November 1977.

[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.

[RFC1506] Houttuin, J., "A Tutorial on Gatewaying between X.400 and Internet Mail", RFC 1506, August 1993.

[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.

[RFC1733] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.

[RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.

[RFC1985] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.

[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.

[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.

[RFC2442] Freed, N., Newman, D., and Hoy, M., "The Batch SMTP Media Type", RFC 2442, November 1998.

[RFC2480] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.

[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, 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 Transport Layer Security", RFC 3207, February 2002.

[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

[RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.

[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.

[RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for Internet Mail (FFPIM)", RFC 4142, November 2005.

[RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail (IFAX) Service of ENUM", RFC 4143, November 2005.

[RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", RFC 4356, January 2006.

[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. Finch, "Email Submission Operations: Access and Accountability Requirements", BCP 134, RFC 5068, November 2007.

[RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008.

[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.

[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", ACM SIGCOMM, 2002.

Appendix A. Acknowledgments​

Appendice A. Riconoscimenti​

This work began in 2004 and has evolved through numerous rounds of community review; it derives from a section in an early version of [RFC5068]. Over its 5 years of development, the document has gone through 14 incremental versions, with vigorous community review that produced many substantive changes. Review was performed in the IETF and other email technical venues. Although not a formal activity of the IETF, issues with the document's contents were resolved using the classic style of IETF community open, group decision-making. The document is already cited in other work, such as in IMAP and Sieve specifications and in academic classwork. The step of standardizing is useful to provide a solid and stable reference to the Internet's now-complex email service.

Questo lavoro è iniziato nel 2004 e si è evoluto attraverso numerosi cicli di revisione della comunità; deriva da una sezione in una prima versione della [RFC5068]. Nel corso dei suoi 5 anni di sviluppo, il documento ha attraversato 14 versioni incrementali, con una vigorosa revisione della comunità che ha prodotto molti cambiamenti sostanziali. La revisione è stata eseguita nell'IETF e in altre sedi tecniche di posta elettronica. Sebbene non fosse un'attività formale dell'IETF, le questioni relative al contenuto del documento sono state risolte utilizzando lo stile classico del processo decisionale di gruppo aperto della comunità IETF. Il documento è già citato in altri lavori, come nelle specifiche IMAP e Sieve e nei lavori accademici. Il passo della standardizzazione è utile per fornire un riferimento solido e stabile al servizio di posta elettronica ormai complesso di Internet.

Details of the Originator Actor role was greatly clarified during discussions in the IETF's Marid working group.

I dettagli del ruolo dell'Attore Originator sono stati notevolmente chiariti durante le discussioni nel gruppo di lavoro Marid dell'IETF.

Graham Klyne, Pete Resnick, and Steve Atkins provided thoughtful insight on the framework and details of the original drafts, as did Chris Newman for the final versions, while also serving as cognizant Area Director for the document. Tony Hansen served as document shepherd through the IETF process.

Graham Klyne, Pete Resnick e Steve Atkins hanno fornito approfondimenti ponderati sul framework e sui dettagli delle bozze originali, così come Chris Newman per le versioni finali, servendo anche come Area Director competente per il documento. Tony Hansen ha servito come document shepherd attraverso il processo IETF.

Later reviews and suggestions were provided by Eric Allman, Nathaniel Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani, and Hans Lachman.

Recensioni e suggerimenti successivi sono stati forniti da Eric Allman, Nathaniel Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani e Hans Lachman.

Diligent early proof-reading was performed by Bruce Lilly. Diligent professional technical editing was provided by Susan Hunziker.

Un'attenta correzione di bozze iniziale è stata eseguita da Bruce Lilly. Un'attenta redazione tecnica professionale è stata fornita da Susan Hunziker.

The final stages of development for this document were guided by a design team comprising Alexey Melnikov, Pete Resnick, Carl S. Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen, and Tony Finch. Pete Resnick developed the final version of the section on internationalization.

Le fasi finali di sviluppo di questo documento sono state guidate da un team di progettazione composto da Alexey Melnikov, Pete Resnick, Carl S. Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen e Tony Finch. Pete Resnick ha sviluppato la versione finale della sezione sull'internazionalizzazione.

Author's Address​

Indirizzo dell'autore​

Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA

Phone: +1.408.246.8253 EMail: [email protected]

Ultimo aggiornamento il