email - que - tema en mailchimp
¿Puede una dirección de correo electrónico contener caracteres internacionales(no ingleses)? (7)
Si es posible, ¿debo aceptar esos correos electrónicos de los usuarios y qué problemas puedo esperar cuando enviaré correos a esas direcciones?
Aún no. El IEEE planea hacer esto: Artículo H-Online: IEFT planeando direcciones de correo electrónico internacionalizadas , aquí está el RfC: Extensión SMTP para direcciones de correo electrónico internacionalizadas
Cita de H-Online (según descendió):
El Grupo de trabajo de ingeniería de Internet (IETF) ha publicado tres documentos cruciales para la estandarización de encabezados de direcciones de correo electrónico que incluyen símbolos fuera del conjunto de caracteres ASCII. Esto significa que pronto podrá usar caracteres chinos, acentos franceses y diéresis alemanes en las direcciones de correo electrónico y solo en el cuerpo del mensaje. Entonces, si su nombre es Zoë y trabaja para una empresa que fabrica fachadas, podría estar interesado en una nueva dirección de correo electrónico. Pero los representantes de los proveedores ya están gimiendo. Dicen que debería haber una "manía de actualización" si el UTF-8 de Unicode reemplazara el Código Estándar Americano para el Intercambio de Información (ASCII) que se usa actualmente como el idioma general del correo electrónico.
RFC 5335 especifica el uso de UTF-8 en prácticamente todos los encabezados de correo electrónico. Los cambios se tendrían que hacer a los clientes SMTP, servidores SMTP, agentes de usuario de correo (MUA), software para listas de correo, puertas de enlace a otros medios y en cualquier otro lugar donde se procese o transfiera el correo electrónico. RFC 5336 amplía el protocolo de transporte de correo electrónico SMTP. En el nivel del protocolo, la expansión se denomina UTF8SMTP.
Se agregará un nuevo campo de encabezado como una especie de "paracaídas de emergencia" para garantizar que los correos electrónicos UTF-8 tengan un aterrizaje suave si se lanzan antes de llegar al destinatario por sistemas que no se han actualizado. El "OldAddress" es una dirección puramente ASCII. Pero OldAddress no se debe usar como un canal para un segundo intento de transferencia, sino para asegurarse de que la retroalimentación se envíe a casa.
Finalmente, RFC5337 asegura que se envían los mensajes correctos relacionados con el estado de entrega de los correos electrónicos no ASCII. Se debe devolver la dirección correcta de un destinatario inalcanzable, incluso si se ha rechazado el transporte adicional. El grupo de trabajo de internacionalización de direcciones de correo electrónico (EAI) también está trabajando en una serie de "mecanismos de bajada" para varios campos de encabezado y el sobre. Si es posible, la información del encabezado original se debe "empaquetar" y conservar.
DeNIC de Alemania, el registrador del dominio ".de", está tomando esto en serio. "Realmente no hay mucho que podamos hacer", explicó el portavoz de DeNIC, Klaus Herzig. En cambio, DeNIC está prestando más atención a la actualización en la que el IETF está trabajando para el estándar de dominios internacionales: RFC3490 o IDNA2003, como se lo conoce a veces. "No estamos muy contentos porque no hay compatibilidad con versiones anteriores", explicó Herzig. Cuando llega la actualización, DeNIC dice que arrojará su peso detrás del símbolo "ß", también conocido como estzett, que se ha pasado por alto hasta ahora. El registrador alemán también dice que puede esperar un poco antes de cambiar a la luz de la falta de compatibilidad con versiones anteriores. Una vez que el nuevo estándar se ejecute de manera estable y los registradores y proveedores lo hayan adoptado, se agregará el ß.
En contraste, los expertos creen que los registradores chinos en China y Taiwán implementarán rápidamente el cambio para el correo electrónico internacionalizado. Los representantes de CNIC y TWNIC son autores de los estándares. Los usuarios chinos actualmente tienen que escribir correos electrónicos en ASCII a la izquierda de @ y en caracteres chinos a la derecha para los dominios chinos, que ya se han internacionalizado.
(Monika Ermert)
Actualización 2015: utilice RFC 6532
El experimental 5335 ha sido obsoleto por: 6532 y
esto más tarde se ha establecido en "Categoría: Normas Track",
convirtiéndolo en el estándar.
La Sección 3.2 (Extensiones de sintaxis a RFC 5322 ) ha actualizado la mayoría de los campos de texto a
incluye (apropiado) 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.
Tenga en cuenta la inclusión explícita de dominios.
Y la exclusión explícita de los nombres de encabezado.
También NFKC en cuenta acerca de 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.
Y la Sección 3 comienza:
Also note that messages in this format require the use of the
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.
El problema es que algunos clientes de correo (herramientas de servidor y / o herramientas de escritorio) no lo admiten y lanzan una excepción de "correo electrónico no válido" cuando intenta enviar un correo a una dirección que contiene diéresis, por ejemplo.
Si quieres soporte completo, puedes hacer el truco con la conversión de las partes de la dirección de correo electrónico a "código puny". Esto permite a los usuarios escribir sus direcciones de la manera habitual, pero lo guarda a la manera de nivel admitido.
Ejemplo: müller.com »xn--mller-kva.com
Ambos apuntan a lo mismo.
La respuesta es sí, pero deben codificarse especialmente.
Mira esto . Lea la parte que se refiere a los encabezados de correo electrónico y al RFC 2047.
Supongo que sí, ya que varios dominios de nivel superior ya permiten dominios no ascii para dominios y dado que el dominio es parte de una dirección de correo electrónico, es perfectamente posible. Un ejemplo de dicho dominio sería www.öko.de
respuesta corta: sí
no solo en el nombre de usuario sino también en el nombre de dominio están permitidos.