Un indirizzo email può contenere caratteri internazionali (non inglesi)?

Question

Se è possibile, devo accettare tali e-mail dagli utenti e quali problemi aspettarsi quando invierò mail a tali indirizzi?

Answer 1

Ufficialmente, per RFC 6532 - Sì.

Per una rapida spiegazione, consultare wikipedia sull'argomento.

Answer 2

Non ancora. L'IEEE ha in programma di fare questo: H-Online article: IEFT planning internationalised email addresses, ecco la citazione RfC: SMTP Extension for Internationalized Email Addresses

da H-Online (come è andato giù):

Internet Engineering Task Force (IETF) ha pubblicato tre documenti cruciali per la standardizzazione delle intestazioni degli indirizzi e-mail che includono simboli al di fuori del set di caratteri ASCII. Ciò significa che presto potrai utilizzare caratteri cinesi, accenti francesi e dieresi tedesche negli indirizzi di posta elettronica e solo nel corpo del messaggio . Quindi, se il tuo nome è Zoë e lavori per un'azienda che produce facciate , potresti essere interessato a un nuovo indirizzo email. Ma i rappresentanti dei fornitori si stanno già lamentando. Dicono che dovrebbe essere una "mania di aggiornamento" se lo standard Unicode UTF-8 è sostituire il codice standard americano per l'interscambio di informazioni (ASCII) attualmente utilizzato come lingua di posta elettronica generale.

RFC 5335 specifica l'uso di UTF-8 in praticamente tutte le intestazioni delle e-mail. Devono essere apportate modifiche a client SMTP, server SMTP, agenti di posta elettronica (MUA), software per mailing list, gateway ad altri media, e in qualsiasi altro luogo in cui l'email viene elaborata o inoltrata. RFC 5336 espande il protocollo di trasporto e-mail SMTP. A livello del protocollo , l'espansione è etichettata come UTF8SMTP.

un nuovo header campo verranno aggiunti come una sorta di "paracadute d'emergenza" per garantire che UTF-8 messaggi di posta elettronica hanno un atterraggio morbido se vengono buttati fuori prima di raggiungere il destinatario da sistemi che non sono stati aggiornati. "OldAddress" è un indirizzo puramente ASCII. Ma OldAddress non è essere utilizzato come canale per un secondo tentativo di trasferimento, ma piuttosto per rendere sicuro che il feedback viene inviato a casa.

Infine, RFC5337 assicura che vengano inviati messaggi corretti relativi a lo stato di consegna di e-mail non-ASCII. L'indirizzo corretto di un destinatario non raggiungibile deve essere restituito, anche se il trasporto ulteriore ha stato rifiutato. L'e-mail Address Addressization (EAI) che funziona con il gruppo sta funzionando anche su una serie di "meccanismi di downgrade" per i campi di intestazione e la busta. Se possibile, l'informazione originale dell'intestazione deve essere "impacchettata" e conservata.

Il DeNIC della Germania, il registrar per il dominio ".de", è comunque lo che fa proprio questo. "Non c'è davvero molto che possiamo fare", ha spiegato il portavoce della DeNIC Klaus Herzig, .DeNIC sta invece pagando più attenzione all'aggiornamento su cui sta lavorando IETF per lo standard dei domini internazionali - RFC3490 o IDNA2003 poiché è noto anche come . "Non ne siamo così felici perché non esiste la compatibilità con le versioni precedenti di ", ha spiegato Herzig. Quando arriva l'aggiornamento, DeNIC dice che sarà lanciato il suo peso dietro il simbolo "ß" - anche noto come estzett - che è stato trascurato fino ad ora. Il registrar tedesco dice anche che potrebbe attendere un po 'prima di accendere la luce della mancanza di compatibilità con le versioni precedenti. Una volta che il nuovo standard è in esecuzione stabile e i registrar e i provider lo hanno adottato, verrà aggiunto il numero .

Al contrario, gli esperti ritengono che i registrar cinesi in Cina e Taiwan implementeranno rapidamente il cambiamento per la posta elettronica internazionalizzata. I rappresentanti di CNIC e TWNIC sono autori degli standard. Gli utenti cinesi attualmente devono scrivere e-mail in ASCII a sinistra di il simbolo @ e in caratteri cinesi a destra di esso per i domini cinesi , che sono già stati internazionalizzati.

(Monika Ermert)

Answer 3

Vorrei assumere sì dal momento che un certo numero di domini di primo livello già permettono non ASCII caratteri per i domini e poiché il dominio è parte di un indirizzo di posta elettronica, è perfettamente possibile. Un esempio di tale dominio sarebbe www.öko.de

Answer 4

risposta breve: sì

non solo nel nome utente, ma anche nel nome di dominio sono ammessi.

Answer 5

Il problema è che alcuni client di posta (strumenti server e/o strumenti desktop) non lo supportano e generano un'eccezione di 'e-mail non valida' quando si tenta di inviare una posta a un indirizzo che contiene dieresi, ad esempio.

Se si desidera un supporto completo, è possibile eseguire il trucco convertendo le parti dell'indirizzo e-mail in "punycode". Ciò consente agli utenti di digitare i propri indirizzi nel modo consueto, ma si salva il modo supportato.

Esempio: müller.com »xn--mller-kva.com

Entrambi i punti per la stessa cosa.

Answer 6

La risposta è sì, ma devono essere codificati appositamente.

Look at this. Leggere la parte che si riferisce alla posta elettronica-header e RFC 2047.

Answer 7

Aggiornamento 2015: Usa RFC 6532

Il sperimentale 5335 è diventato obsoleto da: 6532 e
in seguito è stato impostato a "Categoria: Standard Track" ,
facendo it lo standard.

I Section 3.2 (sintassi Estensioni di RFC 5322) ha aggiornato la maggior parte dei campi di testo per
includere (corretta) UTF-8.

The following rules extend the ABNF syntax defined in [RFC5322] and 
[RFC5234] in order to allow UTF-8 content. 

VCHAR =/ UTF8-non-ascii 
ctext =/ UTF8-non-ascii 
atext =/ UTF8-non-ascii 
qtext =/ UTF8-non-ascii 
text =/ UTF8-non-ascii 
      ; note that this upgrades the body to UTF-8 
dtext =/ UTF8-non-ascii 

The preceding changes mean that the following constructs now 
allow UTF-8: 
    1. Unstructured text, used in header fields like 
     "Subject:" or "Content-description:". 
    2. Any construct that uses atoms, including but not limited 
     to the local parts of addresses and Message-IDs. This 
     includes addresses in the "for" clauses of "Received:" 
     header fields. 
    3. Quoted strings. 
    4. Domains. 

Note that header field names are not on this list; these are still 
restricted to ASCII. 

Si prega di notare la esplicito inclusione di Domini.
E l'esclusione esplicita dell'intestazione nomi.

Nota anche su NFKC:

The UTF-8 NFKC normalization form SHOULD NOT be used because 
it may lose information that is needed to correctly spell 
some names in some unusual circumstances. 

E Section 3 inizio:

Also note that messages in this format require the use of the 
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.