Passa al contenuto principale

RFC 6531 - Estensione SMTP per la posta elettronica internazionalizzata

  • Stato: Proposed Standard
  • Pubblicato: February 2012
  • Stream: IETF
  • Sostituisce: RFC5336
  • Errata: Nessun errata

Document Information​

  • RFC Number: 6531
  • Title: SMTP Extension for Internationalized Email
  • Authors: J. Yao, W. Mao
  • Date: February 2012
  • Category: Standards Track
  • Obsoletes: RFC 5336
  • ISSN: 2070-1721

Abstract​

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Questo documento specifica un'estensione SMTP per il trasporto e la consegna di messaggi di posta elettronica con indirizzi email internazionalizzati o informazioni di intestazione.

Status of This Memo​

This is an Internet Standards Track document. Questo è un documento Internet Standards Track.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Questo documento è un prodotto della Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto una revisione pubblica ed è stato approvato per la pubblicazione dall'Internet Engineering Steering Group (IESG). Ulteriori informazioni sugli standard Internet sono disponibili nella Sezione 2 della RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6531. Informazioni sullo stato attuale di questo documento, eventuali errata e come fornire feedback su di esso possono essere ottenute all'indirizzo http://www.rfc-editor.org/info/rfc6531.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Copyright (c) 2012 IETF Trust e le persone identificate come autori del documento. Tutti i diritti riservati.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Questo documento è soggetto alla BCP 78 e alle disposizioni legali dell'IETF Trust relative ai documenti IETF (http://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i propri diritti e restrizioni rispetto a questo documento. I componenti di codice estratti da questo documento devono includere il testo della licenza BSD semplificata come descritto nella Sezione 4.e delle disposizioni legali del Trust e sono forniti senza garanzia come descritto nella licenza BSD semplificata.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Questo documento può contenere materiale proveniente da documenti IETF o contributi IETF pubblicati o resi disponibili pubblicamente prima del 10 novembre 2008. La persona o le persone che controllano il copyright in parte di questo materiale potrebbero non aver concesso all'IETF Trust il diritto di consentire modifiche di tale materiale al di fuori del processo degli standard IETF. Senza ottenere una licenza adeguata dalla persona o dalle persone che controllano il copyright in tali materiali, questo documento non può essere modificato al di fuori del processo degli standard IETF e non possono essere create opere derivate da esso al di fuori del processo degli standard IETF, tranne che per formattarlo per la pubblicazione come RFC o per tradurlo in lingue diverse dall'inglese.

Table of Contents​

  1. Introduction
  2. Overview of Operation
  3. Mail Transport-Level Protocol
  4. IANA Considerations
  5. Security Considerations
  6. Acknowledgements
  7. References

1. Introduction​

The document defines a Simple Mail Transfer Protocol [RFC5321] extension so servers can advertise the ability to accept and process internationalized email addresses (see Section 1.1) and internationalized email headers [RFC6532]. Il documento definisce un'estensione del Simple Mail Transfer Protocol [RFC5321] in modo che i server possano pubblicizzare la capacità di accettare ed elaborare indirizzi email internazionalizzati (vedere Sezione 1.1) e intestazioni email internazionalizzate [RFC6532].

An extended overview of the extension model for internationalized email addresses and the email header appears in RFC 6530 [RFC6530], referred to as "the framework document" in this specification. A thorough understanding of the information in that document and in the base Internet email specifications [RFC5321] [RFC5322] is necessary to understand and implement this specification. Una panoramica estesa del modello di estensione per gli indirizzi email internazionalizzati e l'intestazione dell'email appare nella RFC 6530 [RFC6530], indicata come "il documento quadro" in questa specifica. Una comprensione approfondita delle informazioni contenute in quel documento e nelle specifiche di base della posta elettronica Internet [RFC5321] [RFC5322] è necessaria per comprendere e implementare questa specifica.

1.1. Terminology​

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]. Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nella RFC 2119 [RFC2119].

The terms "UTF-8 string" or "UTF-8 character" are used to refer to Unicode characters, which may or may not be members of the ASCII subset, in UTF-8 [RFC3629], a standard Unicode Encoding Form. All other specialized terms used in this specification are defined in the framework document or in the base Internet email specifications. In particular, the terms "ASCII address", "internationalized email address", "non-ASCII address", "SMTPUTF8", "internationalized message", and "message" are used in this document according to the definitions in the framework document [RFC6530]. I termini "stringa UTF-8" o "carattere UTF-8" sono usati per riferirsi ai caratteri Unicode, che possono o meno essere membri del sottoinsieme ASCII, in UTF-8 [RFC3629], una forma di codifica Unicode standard. Tutti gli altri termini specializzati utilizzati in questa specifica sono definiti nel documento quadro o nelle specifiche di base della posta elettronica Internet. In particolare, i termini "indirizzo ASCII", "indirizzo email internazionalizzato", "indirizzo non ASCII", "SMTPUTF8", "messaggio internazionalizzato" e "messaggio" sono utilizzati in questo documento secondo le definizioni nel documento quadro [RFC6530].

Strings referred to in this document, including ASCII strings, MUST be expressed in UTF-8. Le stringhe menzionate in questo documento, incluse le stringhe ASCII, DEVONO essere espresse in UTF-8.

This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some basic rules in this document are identified in Section 3.3 as being defined (under the same names) in RFC 5234 [RFC5234], RFC 5321 [RFC5321], RFC 5890 [RFC5890], or RFC 6532 [RFC6532]. Questa specifica utilizza le regole Augmented BNF (ABNF) [RFC5234]. Alcune regole di base in questo documento sono identificate nella Sezione 3.3 come definite (con gli stessi nomi) nella RFC 5234 [RFC5234], RFC 5321 [RFC5321], RFC 5890 [RFC5890] o RFC 6532 [RFC6532].

1.2. Changes Made to Other Specifications​

This specification extends some syntax rules defined in RFC 5321 and permits internationalized email addresses in the envelope and in trace fields, but it does not modify RFC 5321. It permits data formats defined in RFC 6532 [RFC6532], but it does not modify RFC 5322. It does require that the 8BITMIME extension [RFC6152] be announced by the SMTPUTF8-aware SMTP server and used with "BODY=8BITMIME" by the SMTPUTF8-aware SMTP client, but it does not modify the 8BITMIME specification in any way. Questa specifica estende alcune regole di sintassi definite nella RFC 5321 e consente indirizzi email internazionalizzati nella busta e nei campi di traccia, ma non modifica la RFC 5321. Consente i formati di dati definiti nella RFC 6532 [RFC6532], ma non modifica la RFC 5322. Richiede che l'estensione 8BITMIME [RFC6152] sia annunciata dal server SMTP compatibile con SMTPUTF8 e utilizzata con "BODY=8BITMIME" dal client SMTP compatibile con SMTPUTF8, ma non modifica in alcun modo la specifica 8BITMIME.

This specification replaces an earlier, experimental, approach to the same problem [RFC5336]. Section 6 of RFC 6530 [RFC6530] describes the changes in approach between RFC 5336 [RFC5336] and this specification. Anyone trying to convert an implementation from the experimental specification to the specification in this document will need to review those changes carefully. Questa specifica sostituisce un precedente approccio sperimentale allo stesso problema [RFC5336]. La Sezione 6 della RFC 6530 [RFC6530] descrive i cambiamenti di approccio tra la RFC 5336 [RFC5336] e questa specifica. Chiunque cerchi di convertire un'implementazione dalla specifica sperimentale alla specifica in questo documento dovrà esaminare attentamente tali cambiamenti.

2. Overview of Operation​

This document specifies an element of the email internationalization work, specifically the definition of an SMTP extension for internationalized email. The extension is identified with the token "SMTPUTF8". Questo documento specifica un elemento del lavoro di internazionalizzazione della posta elettronica, in particolare la definizione di un'estensione SMTP per la posta elettronica internazionalizzata. L'estensione è identificata con il token "SMTPUTF8".

The internationalized email headers specification [RFC6532] provides the details of email header features enabled by this extension. La specifica delle intestazioni email internazionalizzate [RFC6532] fornisce i dettagli delle funzionalità dell'intestazione email abilitate da questa estensione.

3. Mail Transport-Level Protocol​

3.1. Framework for the Internationalization Extension​

The following service extension is defined: È definita la seguente estensione del servizio:

  1. The name of the SMTP service extension is "Internationalized Email".

  2. Il nome dell'estensione del servizio SMTP è "Internationalized Email".

  3. The EHLO keyword value associated with this extension is "SMTPUTF8".

  4. Il valore della parola chiave EHLO associato a questa estensione è "SMTPUTF8".

  5. No parameter values are defined for this EHLO keyword value. In order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters for this keyword. The SMTPUTF8-aware SMTP client MUST ignore any parameters if they appear for this keyword; that is, the SMTPUTF8-aware SMTP client MUST behave as if the parameters do not appear. If an SMTP server includes SMTPUTF8 in its EHLO response, it MUST be fully compliant with this version of this specification.

  6. Non sono definiti valori di parametro per questo valore della parola chiave EHLO. Al fine di consentire estensioni future (sebbene non previste), la risposta EHLO NON DEVE contenere alcun parametro per questa parola chiave. Il client SMTP compatibile con SMTPUTF8 DEVE ignorare qualsiasi parametro se appare per questa parola chiave; cioè, il client SMTP compatibile con SMTPUTF8 DEVE comportarsi come se i parametri non apparissero. Se un server SMTP include SMTPUTF8 nella sua risposta EHLO, DEVE essere pienamente conforme a questa versione di questa specifica.

  7. One OPTIONAL parameter, SMTPUTF8, is added to the MAIL command. The parameter does not accept a value. If this parameter is set in the MAIL command, it indicates that the SMTP client is SMTPUTF8-aware. Its presence also asserts that the envelope includes the non-ASCII address, the message being sent is an internationalized message, or the message being sent needs the SMTPUTF8 support.

  8. Un parametro OPZIONALE, SMTPUTF8, viene aggiunto al comando MAIL. Il parametro non accetta un valore. Se questo parametro è impostato nel comando MAIL, indica che il client SMTP è compatibile con SMTPUTF8. La sua presenza afferma anche che la busta include l'indirizzo non ASCII, il messaggio inviato è un messaggio internazionalizzato o il messaggio inviato necessita del supporto SMTPUTF8.

  9. The maximum length of a MAIL command line is increased by 10 characters to accommodate the possible addition of the SMTPUTF8 parameter.

  10. La lunghezza massima di una riga di comando MAIL è aumentata di 10 caratteri per accogliere la possibile aggiunta del parametro SMTPUTF8.

  11. One OPTIONAL parameter, SMTPUTF8, is added to the VERIFY (VRFY) and EXPAND (EXPN) commands. The SMTPUTF8 parameter does not accept a value. The parameter indicates that the SMTP client can accept Unicode characters in UTF-8 encoding in replies from the VRFY and EXPN commands.

  12. Un parametro OPZIONALE, SMTPUTF8, viene aggiunto ai comandi VERIFY (VRFY) ed EXPAND (EXPN). Il parametro SMTPUTF8 non accetta un valore. Il parametro indica che il client SMTP può accettare caratteri Unicode nella codifica UTF-8 nelle risposte dai comandi VRFY ed EXPN.

  13. No additional SMTP verbs are defined by this extension.

  14. Nessun verbo SMTP aggiuntivo è definito da questa estensione.

  15. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC6152].

  16. I server che offrono questa estensione DEVONO fornire supporto e annunciare l'estensione 8BITMIME [RFC6152].

  17. The reverse-path and forward-path of the SMTP MAIL and RCPT commands are extended to allow Unicode characters encoded in UTF-8 in mailbox names (addresses).

  18. Il percorso inverso e il percorso diretto dei comandi SMTP MAIL e RCPT sono estesi per consentire caratteri Unicode codificati in UTF-8 nei nomi delle caselle di posta (indirizzi).

  19. The mail message body is extended as specified in RFC 6532 [RFC6532].

  20. Il corpo del messaggio di posta è esteso come specificato nella RFC 6532 [RFC6532].

  21. The SMTPUTF8 extension is valid on the submission port [RFC6409]. It may also be used with the Local Mail Transfer Protocol (LMTP) [RFC2033]. When these protocols are used, their use should be reflected in the trace field WITH keywords as appropriate [RFC3848].

  22. L'estensione SMTPUTF8 è valida sulla porta di sottomissione [RFC6409]. Può anche essere utilizzata con il Local Mail Transfer Protocol (LMTP) [RFC2033]. Quando questi protocolli vengono utilizzati, il loro utilizzo dovrebbe riflettersi nelle parole chiave WITH del campo di traccia come appropriato [RFC3848].

3.2. The SMTPUTF8 Extension​

An SMTP server that announces the SMTPUTF8 extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 5321 specifies that a <mailbox> can appear. Although the characters in the <local-part> are permitted to contain non-ASCII characters, the actual parsing of the <local-part> and the delimiters used are unchanged from the base email specification [RFC5321]. Any domain name to be looked up in the DNS MUST conform to and be processed as specified for Internationalizing Domain Names in Applications (IDNA) [RFC5890]. When doing lookups, the SMTPUTF8-aware SMTP client or server MUST either use a Unicode-aware DNS library, or transform the internationalized domain name to A-label form (i.e., a fully-qualified domain name that contains one or more A-labels but no U-labels) as specified in RFC 5890 [RFC5890]. Un server SMTP che annuncia l'estensione SMTPUTF8 DEVE essere preparato ad accettare una stringa UTF-8 [RFC3629] in qualsiasi posizione in cui la RFC 5321 specifica che può apparire una <mailbox>. Sebbene i caratteri nella <local-part> possano contenere caratteri non ASCII, l'effettiva analisi della <local-part> e i delimitatori utilizzati rimangono invariati rispetto alla specifica di base della posta elettronica [RFC5321]. Qualsiasi nome di dominio da cercare nel DNS DEVE essere conforme e processato come specificato per l'Internationalizing Domain Names in Applications (IDNA) [RFC5890]. Quando si effettuano ricerche, il client o server SMTP compatibile con SMTPUTF8 DEVE utilizzare una libreria DNS compatibile con Unicode o trasformare il nome di dominio internazionalizzato in forma A-label (cioè, un nome di dominio completamente qualificato che contiene una o più A-label ma nessuna U-label) come specificato nella RFC 5890 [RFC5890].

An SMTP client that receives the SMTPUTF8 extension keyword in response to the EHLO command MAY transmit mailbox names within SMTP commands as internationalized strings in UTF-8 form. It MAY send a UTF-8 header [RFC6532] (which may also include mailbox names in UTF-8). It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels [RFC5890]. The presence of the SMTPUTF8 extension does not change the server-relaying behaviors described in RFC 5321. Un client SMTP che riceve la parola chiave di estensione SMTPUTF8 in risposta al comando EHLO PUÒ trasmettere nomi di caselle di posta all'interno dei comandi SMTP come stringhe internazionalizzate in forma UTF-8. PUÒ inviare un'intestazione UTF-8 [RFC6532] (che può includere anche nomi di caselle di posta in UTF-8). PUÒ trasmettere le parti di dominio dei nomi delle caselle di posta all'interno dei comandi SMTP o dell'intestazione del messaggio come A-label o U-label [RFC5890]. La presenza dell'estensione SMTPUTF8 non modifica i comportamenti di inoltro del server descritti nella RFC 5321.

If the SMTPUTF8 SMTP extension is not offered by the SMTP server, the SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized email address and MUST NOT transmit a mail message containing internationalized mail headers as described in RFC 6532 [RFC6532] at any level within its MIME structure [RFC2045]. (For this paragraph, the internationalized domain name in A-label form as specified in IDNA definitions [RFC5890] is not considered to be "internationalized".) Instead, if an SMTPUTF8-aware SMTP client (sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, the best action for it to take depends on other conditions. In particular: Se l'estensione SMTP SMTPUTF8 non è offerta dal server SMTP, il client SMTP compatibile con SMTPUTF8 NON DEVE trasmettere un indirizzo email internazionalizzato e NON DEVE trasmettere un messaggio di posta contenente intestazioni di posta internazionalizzate come descritto nella RFC 6532 [RFC6532] a qualsiasi livello all'interno della sua struttura MIME [RFC2045]. (Per questo paragrafo, il nome di dominio internazionalizzato in forma A-label come specificato nelle definizioni IDNA [RFC5890] non è considerato "internazionalizzato".) Invece, se un client SMTP compatibile con SMTPUTF8 (mittente) tenta di trasferire un messaggio internazionalizzato e incontra un server SMTP che non supporta l'estensione, la migliore azione da intraprendere dipende da altre condizioni. In particolare:

  • If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario using the wide discretion for changing addresses or otherwise fixing up and transforming messages allowed by RFC 6409. As long as the resulting message conforms to the requirements of RFC 5321 (i.e., without the SMTPUTF8 extension), the details of that transformation are outside the scope of this document.

  • Se si tratta di un Message Submission Agent (MSA) [RFC6409] [RFC5598], PUÒ scegliere il proprio modo di affrontare questo scenario utilizzando l'ampia discrezione per modificare gli indirizzi o altrimenti sistemare e trasformare i messaggi consentita dalla RFC 6409. Finché il messaggio risultante è conforme ai requisiti della RFC 5321 (cioè, senza l'estensione SMTPUTF8), i dettagli di tale trasformazione esulano dallo scopo di questo documento.

  • If it is not an MSA or is an MSA and does not choose to transform the message to one that does not require the SMTPUTF8 extension, it SHOULD reject the message. As usual, this can be done either by generating an appropriate reply during the SMTP transaction or by accepting the message and then generating and transmitting a non-delivery notification. If the latter choice is made, the notification process MUST conform to the requirements of RFC 5321, RFC 3464 [RFC3464], and RFC 6533 [RFC6533].

  • Se non è un MSA o è un MSA e non sceglie di trasformare il messaggio in uno che non richiede l'estensione SMTPUTF8, DOVREBBE rifiutare il messaggio. Come al solito, ciò può essere fatto generando una risposta appropriata durante la transazione SMTP o accettando il messaggio e quindi generando e trasmettendo una notifica di mancata consegna. Se viene fatta quest'ultima scelta, il processo di notifica DEVE essere conforme ai requisiti della RFC 5321, RFC 3464 [RFC3464] e RFC 6533 [RFC6533].

  • As specified in Section 2.2.3 of RFC 5321, an SMTP client with additional information and/or knowledge of special circumstances MAY choose to requeue the message and try later and/or try an alternate MX host as specified in that section.

  • Come specificato nella Sezione 2.2.3 della RFC 5321, un client SMTP con informazioni aggiuntive e/o conoscenza di circostanze speciali PUÒ scegliere di rimettere in coda il messaggio e riprovare più tardi e/o provare un host MX alternativo come specificato in quella sezione.

This document applies when an SMTPUTF8-aware SMTP client or server supports the SMTPUTF8 extension. For all other cases, and for addresses and messages that do not require an SMTPUTF8 extension, SMTPUTF8-aware SMTP clients and servers do not change the behavior specified in RFC 5321 [RFC5321]. Questo documento si applica quando un client o server SMTP compatibile con SMTPUTF8 supporta l'estensione SMTPUTF8. Per tutti gli altri casi, e per indirizzi e messaggi che non richiedono un'estensione SMTPUTF8, i client e server SMTP compatibili con SMTPUTF8 non modificano il comportamento specificato nella RFC 5321 [RFC5321].

If an SMTPUTF8-aware SMTP server advertises the Delivery Status Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533 [RFC6533]. Se un server SMTP compatibile con SMTPUTF8 pubblicizza l'estensione Delivery Status Notification (DSN) [RFC3461], DEVE implementare la RFC 6533 [RFC6533].

3.3. Extended Mailbox Address Syntax​

RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely in terms of ASCII characters. This document extends <Mailbox> to add support of non-ASCII characters. La RFC 5321, Sezione 4.1.2, definisce la sintassi di una <Mailbox> interamente in termini di caratteri ASCII. Questo documento estende <Mailbox> per aggiungere il supporto di caratteri non ASCII.

The key changes made by this specification include: Le principali modifiche apportate da questa specifica includono:

  • The <Mailbox> ABNF rule is imported from RFC 5321 and updated in order to support the internationalized email address. Other related rules are imported from RFC 5321, RFC 5234, RFC 5890, and RFC 6532, or are extended in this document.

  • La regola ABNF <Mailbox> è importata dalla RFC 5321 e aggiornata per supportare l'indirizzo email internazionalizzato. Altre regole correlate sono importate dalla RFC 5321, RFC 5234, RFC 5890 e RFC 6532 o sono estese in questo documento.

  • The definition of <sub-domain> is extended to permit both the RFC 5321 definition and a UTF-8 string in a DNS label that conforms with IDNA definitions [RFC5890].

  • La definizione di <sub-domain> è estesa per consentire sia la definizione della RFC 5321 che una stringa UTF-8 in un'etichetta DNS conforme alle definizioni IDNA [RFC5890].

  • The definition of <atext> is extended to permit both the RFC 5321 definition and a UTF-8 string. That string MUST NOT contain any of the ASCII graphics or control characters.

  • La definizione di <atext> è estesa per consentire sia la definizione della RFC 5321 che una stringa UTF-8. Tale stringa NON DEVE contenere alcuno dei caratteri grafici o di controllo ASCII.

The following ABNF rules imported from RFC 5321, Section 4.1.2, are updated directly or indirectly by this document: Le seguenti regole ABNF importate dalla RFC 5321, Sezione 4.1.2, sono aggiornate direttamente o indirettamente da questo documento:

  • <Mailbox>
  • <Local-part>
  • <Dot-string>
  • <Quoted-string>
  • <QcontentSMTP>
  • <Domain>
  • <Atom>

The following ABNF rule will be imported from RFC 6532, Section 3.1, directly: La seguente regola ABNF sarà importata direttamente dalla RFC 6532, Sezione 3.1:

  • <UTF8-non-ascii>

The following ABNF rule will be imported from RFC 5234, Appendix B.1, directly: La seguente regola ABNF sarà importata direttamente dalla RFC 5234, Appendice B.1:

  • <DQUOTE>

The following ABNF rule will be imported from RFC 5890, Section 2.3.2.1, directly: La seguente regola ABNF sarà importata direttamente dalla RFC 5890, Sezione 2.3.2.1:

  • <U-label>

The following rules are extended in ABNF [RFC5234] as follows. Le seguenti regole sono estese in ABNF [RFC5234] come segue.

sub-domain   =/  U-label
 ; extend the definition of sub-domain in RFC 5321, Section 4.1.2

atext   =/  UTF8-non-ascii
 ; extend the implicit definition of atext in
 ; RFC 5321, Section 4.1.2, which ultimately points to
 ; the actual definition in RFC 5322, Section 3.2.3

qtextSMTP  =/ UTF8-non-ascii
 ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2

esmtp-value  =/ UTF8-non-ascii
 ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2

3.4. MAIL Command Parameter Usage​

If the envelope or message being sent requires the capabilities of the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply the SMTPUTF8 parameter with the MAIL command. If this parameter is provided, it MUST not accept a value. If the SMTPUTF8-aware SMTP client is aware that neither the envelope nor the message being sent requires any of the SMTPUTF8 extension capabilities, it SHOULD NOT supply the SMTPUTF8 parameter with the MAIL command. Se la busta o il messaggio inviato richiede le funzionalità dell'estensione SMTPUTF8, il client SMTP compatibile con SMTPUTF8 DEVE fornire il parametro SMTPUTF8 con il comando MAIL. Se questo parametro viene fornito, NON DEVE accettare un valore. Se il client SMTP compatibile con SMTPUTF8 è consapevole che né la busta né il messaggio inviato richiedono alcuna delle funzionalità dell'estensione SMTPUTF8, NON DOVREBBE fornire il parametro SMTPUTF8 con il comando MAIL.

Because there is no guarantee that a next-hop SMTP server will support the SMTPUTF8 extension, use of the SMTPUTF8 extension always carries a risk of transmission failure. In fact, during the early stages of deployment for the SMTPUTF8 extension, the risk will be quite high. Hence, there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting ASCII [ASCII] characters (0x7f and below) as UTF-8 form is that it permits pure-Unicode environments. Poiché non vi è alcuna garanzia che un server SMTP del salto successivo supporti l'estensione SMTPUTF8, l'uso dell'estensione SMTPUTF8 comporta sempre un rischio di fallimento della trasmissione. Infatti, durante le prime fasi di implementazione dell'estensione SMTPUTF8, il rischio sarà piuttosto elevato. Pertanto, vi è un netto vantaggio a breve termine per i messaggi solo ASCII nell'essere inviati senza utilizzare questa estensione. Il vantaggio a lungo termine della conversione dei caratteri ASCII [ASCII] (0x7f e inferiori) in forma UTF-8 è che consente ambienti puramente Unicode.

3.5. Non-ASCII Addresses and Reply-Codes​

An SMTPUTF8-aware SMTP client MUST NOT send an internationalized message to an SMTP server that does not support SMTPUTF8. If the SMTP server does not support this option, then the SMTPUTF8-aware SMTP client has three choices according to Section 3.2 of this specification. Un client SMTP compatibile con SMTPUTF8 NON DEVE inviare un messaggio internazionalizzato a un server SMTP che non supporta SMTPUTF8. Se il server SMTP non supporta questa opzione, il client SMTP compatibile con SMTPUTF8 ha tre scelte secondo la Sezione 3.2 di questa specifica.

The three-digit reply-codes used in this section are based on their meanings as defined in RFC 5321. I codici di risposta a tre cifre utilizzati in questa sezione si basano sui loro significati come definiti nella RFC 5321.

When messages are rejected because the RCPT command requires an ASCII address, the reply-code 553 is returned with the meaning "mailbox name not allowed". When messages are rejected because the MAIL command requires an ASCII address, the reply-code 550 is returned with the meaning "mailbox unavailable". When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply-code "X.6.7" [RFC5248] (see Section 4) is used, meaning "Non-ASCII addresses not permitted for that sender/recipient". Quando i messaggi vengono rifiutati perché il comando RCPT richiede un indirizzo ASCII, viene restituito il codice di risposta 553 con il significato "nome casella di posta non consentito". Quando i messaggi vengono rifiutati perché il comando MAIL richiede un indirizzo ASCII, viene restituito il codice di risposta 550 con il significato "casella di posta non disponibile". Quando il server SMTP compatibile con SMTPUTF8 supporta i codici di stato avanzati del sistema di posta [RFC3463], viene utilizzato il codice di risposta "X.6.7" [RFC5248] (vedere Sezione 4), che significa "Indirizzi non ASCII non consentiti per quel mittente/destinatario".

When messages are rejected for other reasons, the server follows the model of the base email specification in RFC 5321; this extension does not change those circumstances or reply messages. Quando i messaggi vengono rifiutati per altri motivi, il server segue il modello della specifica di base della posta elettronica nella RFC 5321; questa estensione non modifica tali circostanze o messaggi di risposta.

If a message is rejected after the final "." of the DATA command because one or more recipients are unable to accept and process a message with internationalized email headers, the reply-code "554" is used with the meaning "Transaction failed". If the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply code "X.6.9" [RFC5248] (see Section 4) is used to indicate this condition, meaning "UTF-8 header message cannot be transmitted to one or more recipients, so the message must be rejected". Se un messaggio viene rifiutato dopo il "." finale del comando DATA perché uno o più destinatari non sono in grado di accettare ed elaborare un messaggio con intestazioni email internazionalizzate, viene utilizzato il codice di risposta "554" con il significato "Transazione fallita". Se il server SMTP compatibile con SMTPUTF8 supporta i codici di stato avanzati del sistema di posta [RFC3463], viene utilizzato il codice di risposta "X.6.9" [RFC5248] (vedere Sezione 4) per indicare questa condizione, che significa "Il messaggio con intestazione UTF-8 non può essere trasmesso a uno o più destinatari, quindi il messaggio deve essere rifiutato".

The SMTPUTF8-aware SMTP servers are encouraged to detect that recipients cannot accept internationalized messages and generate an error after the RCPT command rather than waiting until after the DATA command to issue an error. I server SMTP compatibili con SMTPUTF8 sono incoraggiati a rilevare che i destinatari non possono accettare messaggi internazionalizzati e generare un errore dopo il comando RCPT piuttosto che attendere fino a dopo il comando DATA per emettere un errore.

3.6. Body Parts and SMTP Extensions​

The MAIL command parameter SMTPUTF8 asserts that a message is an internationalized message or the message being sent needs the SMTPUTF8 support. There is still a chance that a message being sent via the MAIL command with the SMTPUTF8 parameter is not an internationalized message. An SMTPUTF8-aware SMTP client or server that requires accurate knowledge of whether a message is internationalized needs to parse all message header fields and MIME header fields [RFC2045] in the message body. However, this specification does not require that the SMTPUTF8-aware SMTP client or server inspects the message. Il parametro del comando MAIL SMTPUTF8 afferma che un messaggio è un messaggio internazionalizzato o che il messaggio inviato necessita del supporto SMTPUTF8. C'è ancora una possibilità che un messaggio inviato tramite il comando MAIL con il parametro SMTPUTF8 non sia un messaggio internazionalizzato. Un client o server SMTP compatibile con SMTPUTF8 che richiede una conoscenza accurata del fatto che un messaggio sia internazionalizzato deve analizzare tutti i campi dell'intestazione del messaggio e i campi dell'intestazione MIME [RFC2045] nel corpo del messaggio. Tuttavia, questa specifica non richiede che il client o server SMTP compatibile con SMTPUTF8 ispezioni il messaggio.

Although this specification requires that SMTPUTF8-aware SMTP servers support the 8BITMIME extension [RFC6152] to ensure that servers have adequate handling capability for 8-bit data, it does not require non-ASCII body parts in the MIME message as specified in RFC 2045. The SMTPUTF8 extension MAY be used as follows (assuming it is appropriate given the body content): Sebbene questa specifica richieda che i server SMTP compatibili con SMTPUTF8 supportino l'estensione 8BITMIME [RFC6152] per garantire che i server abbiano un'adeguata capacità di gestione per i dati a 8 bit, non richiede parti del corpo non ASCII nel messaggio MIME come specificato nella RFC 2045. L'estensione SMTPUTF8 PUÒ essere utilizzata come segue (assumendo che sia appropriato dato il contenuto del corpo):

  • with the BODY=8BITMIME parameter [RFC6152], or

  • con il parametro BODY=8BITMIME [RFC6152], o

  • with the BODY=BINARYMIME parameter, if the SMTP server advertises BINARYMIME [RFC3030].

  • con il parametro BODY=BINARYMIME, se il server SMTP pubblicizza BINARYMIME [RFC3030].

3.7. Additional ESMTP Changes and Clarifications​

The information carried in the mail transport process involves addresses ("mailboxes") and domain names in various contexts in addition to the MAIL and RCPT commands and extended alternatives to them. In general, the rule is that, when RFC 5321 specifies a mailbox, this SMTP extension requires UTF-8 form to be used for the entire string. When RFC 5321 specifies a domain name, the internationalized domain name SHOULD be in U-label form if the SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label form. Le informazioni trasportate nel processo di trasporto della posta coinvolgono indirizzi ("caselle di posta") e nomi di dominio in vari contesti oltre ai comandi MAIL e RCPT e alle loro alternative estese. In generale, la regola è che, quando la RFC 5321 specifica una casella di posta, questa estensione SMTP richiede che venga utilizzata la forma UTF-8 per l'intera stringa. Quando la RFC 5321 specifica un nome di dominio, il nome di dominio internazionalizzato DOVREBBE essere in forma U-label se l'estensione SMTPUTF8 è supportata; altrimenti, DOVREBBE essere in forma A-label.

The following subsections list and discuss all of the relevant cases. Le seguenti sottosezioni elencano e discutono tutti i casi rilevanti.

3.7.1. The Initial SMTP Exchange​

When an SMTP connection is opened, the SMTP server sends a "greeting" response consisting of the 220 reply-code and some information. The SMTP client then sends the EHLO command. Since the SMTP client cannot know whether the SMTP server supports SMTPUTF8 until after it receives the response to the EHLO, the SMTPUTF8-aware SMTP client MUST send only ASCII (LDH label or A-label [RFC5890]) domains in the EHLO command. If the SMTPUTF8-aware SMTP server provides domain names in the EHLO response, they MUST be in the form of LDH labels or A-labels. Quando viene aperta una connessione SMTP, il server SMTP invia una risposta di "saluto" composta dal codice di risposta 220 e alcune informazioni. Il client SMTP invia quindi il comando EHLO. Poiché il client SMTP non può sapere se il server SMTP supporta SMTPUTF8 fino a dopo aver ricevuto la risposta all'EHLO, il client SMTP compatibile con SMTPUTF8 DEVE inviare solo domini ASCII (etichetta LDH o A-label [RFC5890]) nel comando EHLO. Se il server SMTP compatibile con SMTPUTF8 fornisce nomi di dominio nella risposta EHLO, DEVONO essere sotto forma di etichette LDH o A-label.

3.7.2. Mail eXchangers​

If multiple DNS MX records are used to specify multiple servers for a domain (as described in Section 5 of RFC 5321 [RFC5321]), it is strongly advised that all or none of them SHOULD support the SMTPUTF8 extension. Otherwise, unexpected rejections can happen during temporary or permanent failures, which users might perceive as serious reliability issues. Se vengono utilizzati più record MX DNS per specificare più server per un dominio (come descritto nella Sezione 5 della RFC 5321 [RFC5321]), si consiglia vivamente che tutti o nessuno di essi SUPPORTI l'estensione SMTPUTF8. Altrimenti, possono verificarsi rifiuti imprevisti durante guasti temporanei o permanenti, che gli utenti potrebbero percepire come seri problemi di affidabilità.

3.7.3. Trace Information​

The trace information <Return-path-line>, <Time-stamp-line>, and their related rules are defined in Section 4.4 of RFC 5321 [RFC5321]. This document updates <Mailbox> and <Domain> to support non-ASCII characters. When the SMTPUTF8 extension is used, the 'Reverse-path' clause of the Return-path-line may include an internationalized domain name that uses the U-label form. Also, the 'Stamp' clause of the Time-stamp-line may include an internationalized domain name that uses the U-label form. Le informazioni di traccia <Return-path-line>, <Time-stamp-line> e le relative regole sono definite nella Sezione 4.4 della RFC 5321 [RFC5321]. Questo documento aggiorna <Mailbox> e <Domain> per supportare i caratteri non ASCII. Quando viene utilizzata l'estensione SMTPUTF8, la clausola 'Reverse-path' della Return-path-line può includere un nome di dominio internazionalizzato che utilizza la forma U-label. Inoltre, la clausola 'Stamp' della Time-stamp-line può includere un nome di dominio internazionalizzato che utilizza la forma U-label.

If the messages that include trace fields are sent by an SMTPUTF8-aware SMTP client or relay server without the SMTPUTF8 parameter included in the MAIL commands, trace field values must conform to RFC 5321 regardless of the SMTP server's capability. Se i messaggi che includono campi di traccia vengono inviati da un client o server di inoltro SMTP compatibile con SMTPUTF8 senza il parametro SMTPUTF8 incluso nei comandi MAIL, i valori dei campi di traccia devono essere conformi alla RFC 5321 indipendentemente dalla capacità del server SMTP.

When an SMTPUTF8-aware SMTP server adds a trace field to a message that was or will be transmitted with the SMTPUTF8 parameter included in the MAIL commands, that server SHOULD use the U-label form for internationalized domain names in the new trace field. Quando un server SMTP compatibile con SMTPUTF8 aggiunge un campo di traccia a un messaggio che è stato o sarà trasmesso con il parametro SMTPUTF8 incluso nei comandi MAIL, quel server DOVREBBE utilizzare la forma U-label per i nomi di dominio internazionalizzati nel nuovo campo di traccia.

The protocol value of the 'WITH' clause when this extension is used is one of the SMTPUTF8 values specified in the "IANA Considerations" section of this document. Il valore del protocollo della clausola 'WITH' quando viene utilizzata questa estensione è uno dei valori SMTPUTF8 specificati nella sezione "Considerazioni IANA" di questo documento.

3.7.4. UTF-8 Strings in Replies​

3.7.4.1. MAIL Command​

If an SMTP client follows this specification and sends any MAIL commands containing the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server is permitted to use UTF-8 characters in the email address associated with 251 and 551 reply-codes, and the SMTP client MUST be able to accept and process them. If a given MAIL command does not include the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server MUST NOT return a 251 or 551 response containing a non-ASCII mailbox. Instead, it MUST transform such responses into 250 or 550 responses that do not contain non-ASCII addresses. Se un client SMTP segue questa specifica e invia comandi MAIL contenenti il parametro SMTPUTF8, il server SMTP compatibile con SMTPUTF8 è autorizzato a utilizzare caratteri UTF-8 nell'indirizzo email associato ai codici di risposta 251 e 551, e il client SMTP DEVE essere in grado di accettarli ed elaborarli. Se un determinato comando MAIL non include il parametro SMTPUTF8, il server SMTP compatibile con SMTPUTF8 NON DEVE restituire una risposta 251 o 551 contenente una casella di posta non ASCII. Invece, DEVE trasformare tali risposte in risposte 250 o 550 che non contengono indirizzi non ASCII.

3.7.4.2. VRFY and EXPN Commands and the SMTPUTF8 Parameter​

If the SMTPUTF8 parameter is transmitted with the VRFY and EXPN commands, it indicates that the SMTP client can accept UTF-8 strings in replies to those commands. The parameter with the VRFY and EXPN commands SHOULD only be used after the SMTP client sees the EHLO response with the SMTPUTF8 keyword. This allows an SMTPUTF8-aware SMTP server to use UTF-8 strings in mailbox names and full names that occur in replies, without concern that the SMTP client might be confused by them. An SMTP client that conforms to this specification MUST accept and correctly process replies to the VRFY and EXPN commands that contain UTF-8 strings. However, an SMTPUTF8-aware SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client does not specifically allow such replies by transmitting this parameter with the VRFY and EXPN commands. Se il parametro SMTPUTF8 viene trasmesso con i comandi VRFY ed EXPN, indica che il client SMTP può accettare stringhe UTF-8 nelle risposte a tali comandi. Il parametro con i comandi VRFY ed EXPN DOVREBBE essere utilizzato solo dopo che il client SMTP ha visto la risposta EHLO con la parola chiave SMTPUTF8. Ciò consente a un server SMTP compatibile con SMTPUTF8 di utilizzare stringhe UTF-8 nei nomi delle caselle di posta e nei nomi completi che appaiono nelle risposte, senza preoccuparsi che il client SMTP possa essere confuso da esse. Un client SMTP conforme a questa specifica DEVE accettare ed elaborare correttamente le risposte ai comandi VRFY ed EXPN che contengono stringhe UTF-8. Tuttavia, un server SMTP compatibile con SMTPUTF8 NON DEVE utilizzare stringhe UTF-8 nelle risposte se il client SMTP non consente specificamente tali risposte trasmettendo questo parametro con i comandi VRFY ed EXPN.

Most replies do not require that a mailbox name be included in the returned text, and therefore a UTF-8 string is not needed in them. Some replies, notably those resulting from successful execution of the VRFY and EXPN commands, do include the mailbox. La maggior parte delle risposte non richiede che un nome di casella di posta sia incluso nel testo restituito e pertanto non è necessaria una stringa UTF-8 in esse. Alcune risposte, in particolare quelle risultanti dall'esecuzione riuscita dei comandi VRFY ed EXPN, includono la casella di posta.

VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: Le sintassi dei comandi VERIFY (VRFY) ed EXPAND (EXPN) sono modificate in:

vrfy = "VRFY" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

expn = "EXPN" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

The SMTPUTF8 parameter does not accept a value. If the reply to a VRFY or EXPN command requires a UTF-8 string, but the SMTP client did not use the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server MUST use either the reply-code 252 or 550. Reply-code 252, defined in RFC 5321 [RFC5321], means "Cannot VRFY user, but will accept the message and attempt the delivery". Reply-code 550, also defined in RFC 5321 [RFC5321], means "Requested action not taken: mailbox unavailable". When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code as specified below is used. Using the SMTPUTF8 parameter with a VRFY or EXPN command enables UTF-8 replies for that command only. Il parametro SMTPUTF8 non accetta un valore. Se la risposta a un comando VRFY o EXPN richiede una stringa UTF-8, ma il client SMTP non ha utilizzato il parametro SMTPUTF8, il server SMTP compatibile con SMTPUTF8 DEVE utilizzare il codice di risposta 252 o 550. Il codice di risposta 252, definito nella RFC 5321 [RFC5321], significa "Impossibile verificare l'utente, ma accetterà il messaggio e tenterà la consegna". Il codice di risposta 550, anch'esso definito nella RFC 5321 [RFC5321], significa "Azione richiesta non intrapresa: casella di posta non disponibile". Quando il server SMTP compatibile con SMTPUTF8 supporta i codici di stato avanzati del sistema di posta [RFC3463], viene utilizzato il codice di risposta avanzato come specificato di seguito. L'utilizzo del parametro SMTPUTF8 con un comando VRFY o EXPN abilita le risposte UTF-8 solo per quel comando.

If a normal success response (i.e., 250) is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the following forms: Se viene restituita una normale risposta di successo (cioè 250), la risposta PUÒ includere il nome completo dell'utente e DEVE includere la casella di posta dell'utente. DEVE essere in una delle seguenti forme:

User Name <Mailbox>
 ; Mailbox is defined in Section 3.3 of this document.
 ; User Name can contain non-ASCII characters.

Mailbox
 ; Mailbox is defined in Section 3.3 of this document.

If the SMTP reply requires UTF-8 strings, but a UTF-8 string is not allowed in the reply, and the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code is "X.6.8" [RFC5248] (see Section 4), meaning "A reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client". Se la risposta SMTP richiede stringhe UTF-8, ma una stringa UTF-8 non è consentita nella risposta e il server SMTP compatibile con SMTPUTF8 supporta i codici di stato avanzati del sistema di posta [RFC3463], il codice di risposta avanzato è "X.6.8" [RFC5248] (vedere Sezione 4), che significa "È richiesta una risposta contenente una stringa UTF-8 per mostrare il nome della casella di posta, ma quella forma di risposta non è consentita dal client SMTP".

If the SMTP client does not support the SMTPUTF8 extension, but receives a UTF-8 string in a reply, it may not be able to properly report the reply to the user, and some clients might mishandle that reply. Internationalized messages in replies are only allowed in the commands under the situations described above. Se il client SMTP non supporta l'estensione SMTPUTF8, ma riceve una stringa UTF-8 in una risposta, potrebbe non essere in grado di segnalare correttamente la risposta all'utente e alcuni client potrebbero gestire in modo errato tale risposta. I messaggi internazionalizzati nelle risposte sono consentiti nei comandi solo nelle situazioni descritte sopra.

Although UTF-8 strings are needed to represent email addresses in responses under the rules specified in this section, this extension does not permit the use of UTF-8 strings for any other purposes. SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section. Sebbene le stringhe UTF-8 siano necessarie per rappresentare gli indirizzi email nelle risposte secondo le regole specificate in questa sezione, questa estensione non consente l'uso di stringhe UTF-8 per altri scopi. I server SMTP compatibili con SMTPUTF8 NON DEVONO includere caratteri non ASCII nelle risposte, tranne nei casi limitati specificamente consentiti in questa sezione.

4. IANA Considerations​

4.1. SMTP Service Extensions Registry​

IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension" registry of the "Mail Parameters" registry, according to the following data: La IANA ha aggiunto un nuovo valore "SMTPUTF8" al registro "SMTP Service Extension" del registro "Mail Parameters", secondo i seguenti dati:

KeywordsDescriptionReference
SMTPUTF8Internationalized email address[RFC6531]

4.2. SMTP Enhanced Status Code Registry​

The code definitions in this document replace those specified in RFC 5336, following the guidance in Sections 3.5 and 3.7.4.2 of this document, and based on RFC 5248 [RFC5248]. IANA has updated the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry" with the following data: Le definizioni dei codici in questo documento sostituiscono quelle specificate nella RFC 5336, seguendo le linee guida nelle Sezioni 3.5 e 3.7.4.2 di questo documento e basandosi sulla RFC 5248 [RFC5248]. La IANA ha aggiornato il "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry" con i seguenti dati:

Code: X.6.7 Sample Text: Non-ASCII addresses not permitted for that sender/recipient Associated basic status code: 550, 553 Description: This indicates the reception of a MAIL or RCPT command that non-ASCII addresses are not permitted. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: [email protected]

Code: X.6.8 Sample Text: UTF-8 string reply is required, but not permitted by the SMTP client Associated basic status code: 252, 550, 553 Description: This indicates that a reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: [email protected]

Code: X.6.9 Sample Text: UTF-8 header message cannot be transferred to one or more recipients, so the message must be rejected Associated basic status code: 550 Description: This indicates that transaction failed after the final "." of the DATA command. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: [email protected]

Code: X.6.10 Description: This is a duplicate of X.6.8 and is thus deprecated.

4.3. WITH Protocol Types Sub-Registry of the Mail Transmission Types Registry​

IANA has modified or added the following entries in the "WITH protocol types" sub-registry under the "Mail Transmission Types" registry. La IANA ha modificato o aggiunto le seguenti voci nel registro secondario "WITH protocol types" sotto il registro "Mail Transmission Types".

WITH protocol typesDescriptionReference
UTF8SMTPESMTP with SMTPUTF8[RFC6531]
UTF8SMTPAESMTP with SMTPUTF8 and AUTH[RFC4954] [RFC6531]
UTF8SMTPSESMTP with SMTPUTF8 and STARTTLS[RFC3207] [RFC6531]
UTF8SMTPSAESMTP with SMTPUTF8 and both STARTTLS and AUTH[RFC3207] [RFC4954] [RFC6531]
UTF8LMTPLMTP with SMTPUTF8[RFC6531]
UTF8LMTPALMTP with SMTPUTF8 and AUTH[RFC4954] [RFC6531]
UTF8LMTPSLMTP with SMTPUTF8 and STARTTLS[RFC3207] [RFC6531]
UTF8LMTPSALMTP with SMTPUTF8 and both STARTTLS and AUTH[RFC3207] [RFC4954] [RFC6531]

5. Security Considerations​

The extended security considerations discussion in the framework document [RFC6530] applies here. La discussione estesa sulle considerazioni di sicurezza nel documento quadro [RFC6530] si applica qui.

More security considerations are discussed below: Ulteriori considerazioni sulla sicurezza sono discusse di seguito:

Beyond the use inside the email global system (in SMTP envelopes and message headers), internationalized email addresses will also show up inside other cases, in particular: Oltre all'uso all'interno del sistema globale di posta elettronica (nelle buste SMTP e nelle intestazioni dei messaggi), gli indirizzi email internazionalizzati appariranno anche in altri casi, in particolare:

  • the logging systems of SMTP transactions and other logs to monitor the email systems;

  • i sistemi di registrazione delle transazioni SMTP e altri registri per monitorare i sistemi di posta elettronica;

  • the trouble ticket systems used by security teams to manage security incidents, when an email address is involved;

  • i sistemi di ticket di guasto utilizzati dai team di sicurezza per gestire gli incidenti di sicurezza, quando è coinvolto un indirizzo email;

In order to avoid problems that could cause loss of data, this will likely require extending these systems to support full UTF-8, or require providing an adequate mechanism for mapping non-ASCII strings to ASCII. Al fine di evitare problemi che potrebbero causare la perdita di dati, ciò richiederà probabilmente l'estensione di questi sistemi per supportare completamente UTF-8 o la fornitura di un meccanismo adeguato per la mappatura di stringhe non ASCII in ASCII.

Another security aspect to be considered is related to the ability by security team members to quickly understand, read, and identify email addresses from the logs, when they are tracking an incident. Mechanisms to automatically and quickly provide the origin or ownership of an internationalized email address SHALL be implemented for use by log readers that cannot easily read non-ASCII information. Un altro aspetto di sicurezza da considerare è legato alla capacità dei membri del team di sicurezza di comprendere, leggere e identificare rapidamente gli indirizzi email dai registri, quando stanno tracciando un incidente. I meccanismi per fornire automaticamente e rapidamente l'origine o la proprietà di un indirizzo email internazionalizzato DEVONO essere implementati per l'uso da parte dei lettori di registri che non possono leggere facilmente le informazioni non ASCII.

The SMTP commands VRFY and EXPN are sometimes used in SMTP transactions where there is no message to transfer (by tools used to take automated actions in case potential spam messages are identified). Sections 3.5 and 7.3 of RFC 5321 give detailed descriptions of use and possible behaviors. Implementation of internationalized addresses can also affect logs and actions by these tools. I comandi SMTP VRFY ed EXPN sono talvolta utilizzati nelle transazioni SMTP in cui non vi è alcun messaggio da trasferire (da strumenti utilizzati per intraprendere azioni automatizzate nel caso in cui vengano identificati potenziali messaggi di spam). Le Sezioni 3.5 e 7.3 della RFC 5321 forniscono descrizioni dettagliate dell'uso e dei possibili comportamenti. L'implementazione di indirizzi internazionalizzati può anche influenzare i registri e le azioni di questi strumenti.

6. Acknowledgements​

This document revises RFC 5336 [RFC5336] based on the result of the Email Address Internationalization (EAI) working group's discussion. Many EAI working group members did tests and implementations to move this document to the Standards Track. Significant comments and suggestions were received from Xiaodong LEE, Nai-Wen HSU, Yangwoo KO, Yoshiro YONEYA, and other members of JET and were incorporated into the specification. Additional important comments and suggestions, and often specific text, were contributed by many members of the working group and design team. Those contributions include material from John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee, and Lars Eggert. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here. Questo documento revisiona la RFC 5336 [RFC5336] sulla base del risultato della discussione del gruppo di lavoro Email Address Internationalization (EAI). Molti membri del gruppo di lavoro EAI hanno eseguito test e implementazioni per spostare questo documento nel percorso Standards Track. Commenti e suggerimenti significativi sono stati ricevuti da Xiaodong LEE, Nai-Wen HSU, Yangwoo KO, Yoshiro YONEYA e altri membri del JET e sono stati incorporati nella specifica. Ulteriori commenti e suggerimenti importanti, e spesso testo specifico, sono stati forniti da molti membri del gruppo di lavoro e del team di progettazione. Tali contributi includono materiale di John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee e Lars Eggert. Naturalmente, nessuno degli individui è necessariamente responsabile della combinazione di idee qui rappresentata.

Thanks a lot to Dave Crocker for his comments and helping with ABNF refinement. Molte grazie a Dave Crocker per i suoi commenti e per l'aiuto con il perfezionamento dell'ABNF.

7. References​

7.1. Normative References​

  • [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

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

  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.

  • [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.

  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", 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.

  • [RFC5890] Klensin, J., "Internationalizing Domain Names in Applications (IDNA definitions)", RFC 5890, June 2010.

  • [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

  • [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.

  • [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.

  • [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.

  • [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC RFC6533, February 2012.

7.2. Informative References​

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

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

  • [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.

  • [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

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

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

  • [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.

Authors' Addresses

Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58813007 EMail: [email protected]

Wei MAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58812230 EMail: [email protected]

Ultimo aggiornamento il