Una dirección de correo electrónico identifica un buzón de correo electrónico al que se envían los mensajes. Si bien los primeros sistemas de mensajería usaban una variedad de formatos para el direccionamiento, hoy en día, las direcciones de correo electrónico siguen un conjunto de reglas específicas originalmente estandarizadas por el Grupo de Trabajo de Ingeniería de Internet (IETF) en la década de 1980, y actualizadas por RFC 5322 y 6854 . El término dirección de correo electrónico en este artículo se refiere a addr-spec en RFC 5322, no a la dirección o el buzón de correo ; es decir, una dirección sin formato sin un nombre para mostrar .
Una dirección de correo electrónico, como [email protected] , se compone de una parte local , el símbolo @ y un dominio , que puede ser un nombre de dominio o una dirección IP entre paréntesis. Aunque el estándar requiere que la parte local distinga entre mayúsculas y minúsculas, [1] también insta a que los hosts receptores entreguen mensajes de manera independiente de las mayúsculas y minúsculas, [2] por ejemplo, que el sistema de correo en el dominio example.com trate a John. como equivalente a john.smith ; algunos sistemas de correo incluso los tratan como equivalentes a johnsmith . [3] Los sistemas de correo a menudo limitan la elección del nombre de los usuarios a un subconjunto de los caracteres técnicamente permitidos.
Con la introducción de los nombres de dominio internacionalizados , están avanzando los esfuerzos para permitir caracteres no ASCII en las direcciones de correo electrónico.
Transporte de mensajes
Una dirección de correo electrónico consta de dos partes, una parte local [a] y un dominio; si el dominio es un nombre de dominio en lugar de una dirección IP, el cliente SMTP utiliza el nombre de dominio para buscar la dirección IP de intercambio de correo. El formato general de una dirección de correo electrónico es local-part @ domain , por ejemplo, jsmith @ [192.168.1.2], [email protected] . El cliente SMTP transmite el mensaje al intercambio de correo, que puede reenviarlo a otro intercambio de correo hasta que finalmente llegue al host del sistema de correo del destinatario.
La transmisión de correo electrónico desde la computadora del autor y entre hosts de correo en Internet utiliza el Protocolo simple de transferencia de correo (SMTP), definido en RFC 5321 y 5322 , y extensiones como RFC 6531. Las aplicaciones de computadoras personales, dispositivos móviles o sitios de correo web pueden acceder a los buzones de correo y administrarlos mediante el protocolo SMTP y el Protocolo de oficina postal (POP) o el Protocolo de acceso a mensajes de Internet (IMAP).
Al transmitir mensajes de correo electrónico , los agentes de usuario de correo (MUA) y los agentes de transferencia de correo (MTA) utilizan el sistema de nombres de dominio (DNS) para buscar un registro de recursos (RR) para el dominio del destinatario. Un registro de recursos del intercambiador de correo (registro MX ) contiene el nombre del servidor de correo del destinatario. En ausencia de un registro MX, un registro de dirección ( A o AAAA ) especifica directamente el host de correo.
La parte local de una dirección de correo electrónico no tiene importancia para los sistemas de retransmisión de correo intermedios que no sean el host de buzón final. Los remitentes de correo electrónico y los sistemas de retransmisión intermedios no deben asumir que no distingue entre mayúsculas y minúsculas, ya que el host del buzón final puede tratarlo o no como tal. Un solo buzón puede recibir correo para varias direcciones de correo electrónico, si el administrador lo configura. Por el contrario, una sola dirección de correo electrónico puede ser el alias de una lista de distribución para muchos buzones de correo. Alias de correo electrónico , listas de correo electrónico , subdireccionamiento y catch-all direcciones, las últimas buzones que se que reciben mensajes, independientemente de la parte local, son patrones comunes para lograr una variedad de objetivos de servicio.
Las direcciones que se encuentran en los campos de encabezado de un mensaje de correo electrónico no son utilizadas directamente por los intercambios de correo para entregar el mensaje. Un mensaje de correo electrónico también contiene un sobre de mensaje que contiene la información para el enrutamiento de correo. Si bien las direcciones de sobre y de encabezado pueden ser iguales, las direcciones de correo electrónico falsificadas , también llamadas direcciones de correo electrónico falsificadas , a menudo se ven en el spam , el phishing y muchas otras estafas basadas en Internet. Esto ha llevado a varias iniciativas que tienen como objetivo hacer que las falsificaciones de correos electrónicos fraudulentos sean más fáciles de detectar.
Sintaxis
El formato de una dirección de correo electrónico es parte local @ dominio , donde la parte local puede tener hasta 64 octetos de longitud y el dominio puede tener un máximo de 255 octetos. [4] Las definiciones formales están en RFC 5322 (secciones 3.2.3 y 3.4.1) y RFC 5321, con una forma más legible dada en el RFC 3696 [b] informativo y las erratas asociadas.
Una dirección de correo electrónico también puede tener un nombre para mostrar asociado para el destinatario, que precede a la especificación de la dirección, ahora rodeado por corchetes angulares, por ejemplo: John Smith
Las formas anteriores de direcciones de correo electrónico para otras redes distintas de Internet incluían otras notaciones, como la requerida por X.400 , y la notación de ruta de bang UUCP , en la que la dirección se proporcionaba en forma de una secuencia de computadoras a través de las cuales el mensaje debería ser retransmitido. Esto fue ampliamente utilizado durante varios años, pero fue reemplazado por los estándares de Internet promulgados por el Grupo de Trabajo de Ingeniería de Internet (IETF).
Parte local
La parte local de la dirección de correo electrónico puede estar sin comillas o entre comillas.
Si no se cita, puede utilizar cualquiera de estos caracteres ASCII :
- mayúsculas y minúsculas latinas letras
A
aZ
ya
az
- dígitos
0
a9
- caracteres imprimibles
!#$%&'*+-/=?^_`{|}~
- punto
.
, siempre que no sea el primer ni el último carácter y siempre que no aparezca consecutivamente (por ejemplo,[email protected]
no está permitido). [5]
Si se cita, puede contener espacio, tabulación horizontal (HT), cualquier gráfico ASCII excepto barra invertida y cita y un par entre comillas que consiste en una barra invertida seguida de HT, espacio o cualquier gráfico ASCII; también se puede dividir entre líneas en cualquier lugar donde aparezca HT o Space. En contraste con no cotizados-partes locales, las direcciones ".John.Doe"@example.com
, "John.Doe."@example.com
y "John..Doe"@example.com
están permitidos.
La longitud total máxima de la parte local de una dirección de correo electrónico es de 64 octetos. [6]
Tenga en cuenta que algunos servidores de correo admiten el reconocimiento de comodines de partes locales, generalmente los caracteres que siguen a un más y menos a menudo los caracteres que siguen a un menos, por lo que fred + bah @ domain y fred + foo @ domain pueden terminar en la misma bandeja de entrada que fred + @ domain o incluso como fred @ domain. Esto puede ser útil para etiquetar correos electrónicos para clasificarlos (ver más abajo) y para controlar el spam. [7] Los aparatos ortopédicos {
y }
también se utilizan de esa manera, aunque con menos frecuencia. [ cita requerida ]
"(),:;<>@[\]
se permiten espacios y caracteres especiales con restricciones (solo se permiten dentro de una cadena entre comillas, como se describe en el párrafo siguiente, y en esa cadena entre comillas, cualquier barra invertida o comilla doble debe ir precedida una vez por una barra invertida);- los comentarios están permitidos entre paréntesis en cualquier extremo de la parte local; por ejemplo,
john.smith(comment)@example.com
y(comment)[email protected]
son ambos equivalentes a[email protected]
.
Además de los caracteres ASCII anteriores, los caracteres internacionales por encima de U + 007F, codificados como UTF-8 , están permitidos por RFC 6531, aunque incluso los sistemas de correo que admiten SMTPUTF8 y 8BITMIME pueden restringir qué caracteres usar al asignar partes locales.
Una parte local es una cadena de puntos o una cadena entre comillas; no puede ser una combinación. Sin embargo, las cadenas y los caracteres entre comillas no se utilizan comúnmente. [ cita requerida ] RFC 5321 también advierte que "un host que espera recibir correo DEBE evitar definir buzones de correo donde la parte local requiere (o usa) la forma de cadena entre comillas".
La parte local postmaster
se trata de forma especial: no distingue entre mayúsculas y minúsculas y debe reenviarse al administrador de correo electrónico del dominio. Técnicamente todos los demás-partes locales son mayúsculas y minúsculas, por lo tanto, [email protected]
y [email protected]
especifican diferentes buzones de correo; sin embargo, muchas organizaciones tratan las letras mayúsculas y minúsculas como equivalentes. De hecho, RFC 5321 advierte que "un host que espera recibir correo DEBE evitar definir buzones de correo donde ... la parte local distingue entre mayúsculas y minúsculas".
A pesar de la amplia gama de caracteres especiales que son técnicamente válidos, las organizaciones, los servicios de correo, los servidores de correo y los clientes de correo en la práctica a menudo no los aceptan todos. Por ejemplo, Windows Live Hotmail solo permite la creación de direcciones de correo electrónico con caracteres alfanuméricos, punto ( .
), subrayado ( _
) y guión ( -
). [8] Un consejo común es evitar el uso de algunos caracteres especiales para evitar el riesgo de mensajes de correo electrónico rechazados. [9]
Dominio
La parte del nombre de dominio de una dirección de correo electrónico debe ajustarse a pautas estrictas: debe coincidir con los requisitos de un nombre de host , una lista de etiquetas DNS separadas por puntos , cada etiqueta está limitada a una longitud de 63 caracteres y consta de: [5] : §2
- mayúsculas y minúsculas latinas letras
A
aZ
ya
az
; - dígitos
0
hasta9
, siempre que los nombres de dominio de nivel superior no sean todos numéricos; - guión
-
, siempre que no sea el primer ni el último carácter.
Esta regla se conoce como regla LDH (letras, dígitos, guión). Además, el dominio puede ser un literal de dirección IP , rodeado por corchetes []
, como jsmith@[192.168.2.1]
o jsmith@[IPv6:2001:db8::1]
, aunque esto rara vez se ve excepto en el correo no deseado . Los nombres de dominio internacionalizados (que están codificados para cumplir con los requisitos de un nombre de host ) permiten la presentación de dominios que no son ASCII. En los sistemas de correo que cumplen con RFC 6531 y RFC 6532, una dirección de correo electrónico puede codificarse como UTF-8 , tanto una parte local como un nombre de dominio.
Los comentarios están permitidos tanto en el dominio como en la parte local; por ejemplo, john.smith@(comment)example.com
y [email protected](comment)
son equivalentes a [email protected]
.
Dominios reservados
RFC 2606 especifica que ciertos dominios, por ejemplo, aquellos destinados a documentación y pruebas, no deben poder resolverse y que, como resultado, el correo dirigido a buzones de correo en ellos y sus subdominios no debe ser entregado. En el caso del correo electrónico, cabe destacar example , invalid , example.com , example.net y example.org .
Ejemplos de
- Direcciones de correo electrónico válidas
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
(puede ir a la[email protected]
bandeja de entrada según el servidor de correo)[email protected]
(parte local de una letra)[email protected]
test/[email protected]
(las barras son un carácter imprimible y están permitidas)admin@mailserver1
(nombre de dominio local sin TLD , aunque ICANN desaconseja encarecidamente las direcciones de correo electrónico sin puntos [10] )[email protected]
(consulte la Lista de dominios de nivel superior de Internet )" "@example.org
(espacio entre las comillas)"john..doe"@example.org
(citado doble punto)[email protected]
(ruta de host bangified utilizada para envíos de correo uucp)user%[email protected]
(% de ruta de correo escapado a [email protected] a través de example.org)[email protected]
(parte local que termina con un carácter no alfanumérico de la lista de caracteres imprimibles permitidos)
- Direcciones de correo electrónico inválidas
Abc.example.com
(sin carácter @)A@b@[email protected]
(solo se permite una @ fuera de las comillas)a"b(c)d,e:f;g
(ninguno de los caracteres especiales en esta parte local está permitido fuera de las comillas)i[j\k][email protected] just"not"[email protected]
(las cadenas entre comillas deben estar separadas por puntos o ser el único elemento que forma la parte local)this is"not\[email protected]
(los espacios, las comillas y las barras invertidas solo pueden existir cuando están dentro de cadenas entre comillas y están precedidas por una barra invertida)this\ still\"not\\[email protected]
(incluso si se escapó (precedido por una barra invertida), los espacios, las comillas y las barras invertidas deben incluirse entre comillas)1234567890123456789012345678901234567890123456789012345678901234+x@example.com
(la parte local tiene más de 64 caracteres)i_like_underscore@but_its_not_allowed_in_this_part.example.com
(El subrayado no está permitido en la parte del dominio)QA[icon]CHOCOLATE[icon]@test.com
(personajes de icono)
Semántica común de partes locales
Según RFC 5321 2.3.11 Buzón y dirección, "... la parte local DEBE ser interpretada y asignada semántica solo por el host especificado en el dominio de la dirección". Esto significa que no se pueden hacer suposiciones sobre el significado de la parte local de otro servidor de correo. Depende totalmente de la configuración del servidor de correo.
Normalización de la parte local
La interpretación de la parte local de una dirección de correo electrónico depende de las convenciones y políticas implementadas en el servidor de correo. Por ejemplo, la distinción entre mayúsculas y minúsculas puede distinguir los buzones de correo que solo difieren en el uso de mayúsculas en los caracteres de la parte local, aunque esto no es muy común. [11] Gmail ignora todos los puntos en la parte local de una dirección @ gmail.com a los efectos de determinar la identidad de la cuenta. [12]
Subdirección
Algunos servicios de correo admiten una etiqueta incluida en la parte local, de modo que la dirección es un alias de un prefijo de la parte local. Por ejemplo, la dirección [email protected] denota la misma dirección de entrega que [email protected] . RFC 5233, [13] se refiere a esta convención como subdireccionamiento , pero también se conoce como direccionamiento adicional , direccionamiento etiquetado o extensiones de correo .
Las direcciones de este formulario, que utilizan varios separadores entre el nombre base y la etiqueta, son compatibles con varios servicios de correo electrónico, incluidos Andrew Project (más), [14] Runbox (más), Gmail (más), [15] Rackspace (más) , Yahoo! Mail Plus (guión), [16] iCloud de Apple (más), Outlook.com (más), [17] ProtonMail (más), [18] Fastmail (más y direccionamiento de subdominios), [19] postale.io (más) , [20] Pobox (más), [21] MeMail (más), [22] MMDF (igual), Qmail y Courier Mail Server (guión). [23] [24] Postfix y Exim permiten configurar un separador arbitrario del conjunto de caracteres legales. [25] [26]
El texto de la etiqueta se puede utilizar para aplicar filtros, [23] o para crear direcciones de correo electrónico de un solo uso o desechables . [27]
En la práctica, la validación de formularios de algunos sitios web puede rechazar caracteres como "+" en una dirección de correo electrónico, tratándolos, incorrectamente, como caracteres no válidos. Esto puede llevar a que un usuario incorrecto reciba un correo electrónico si el "+" es eliminado silenciosamente por un sitio web sin ningún mensaje de advertencia o error. Por ejemplo, un correo electrónico destinado a la dirección de correo electrónico ingresada por el usuario [email protected] podría enviarse incorrectamente a [email protected]. En otros casos, puede ocurrir una mala experiencia de usuario si algunas partes de un sitio, como una página de registro de usuario, permiten el carácter "+" mientras que otras partes, como una página para darse de baja de la lista de correo de un sitio, no lo permiten.
Validación y verificación
Las direcciones de correo electrónico a menudo se solicitan como entrada al sitio web como validación de la existencia del usuario. Hay otros métodos de validación disponibles, como la validación del número de teléfono celular, la validación del correo postal y la validación del fax.
En general, se reconoce que una dirección de correo electrónico tiene dos partes unidas con un signo de arroba ( @ ), aunque la especificación técnica detallada en RFC 822 y las RFC posteriores son más extensas. [28]
Las direcciones de correo electrónico verificadas y sintácticamente correctas no garantizan que exista un buzón de correo electrónico . Por lo tanto, muchos servidores de correo utilizan incorrectamente otras técnicas y verifican la existencia del buzón con sistemas relevantes como el Sistema de nombres de dominio para el dominio o usan la verificación de devolución de llamada para verificar si el buzón existe. La verificación de devolución de llamada es una solución imperfecta, ya que puede deshabilitarse para evitar un ataque de recolección de directorio .
Se pueden utilizar varias técnicas de validación para validar la dirección de correo electrónico de un usuario. Por ejemplo, [29]
- Vínculos de verificación: la validación de la dirección de correo electrónico a menudo se logra para la creación de cuentas en sitios web enviando un correo electrónico a la dirección de correo electrónico proporcionada por el usuario con un hipervínculo temporal especial. Al recibirlo, el usuario abre el enlace, activando inmediatamente la cuenta. Las direcciones de correo electrónico también son útiles como medio para enviar mensajes desde un sitio web, por ejemplo, mensajes de usuario, acciones de usuario, a la bandeja de entrada de correo electrónico.
- Estándares formales e informales: RFC 3696 proporciona consejos específicos para validar identificadores de Internet, incluidas las direcciones de correo electrónico. En cambio, algunos sitios web intentan evaluar la validez de las direcciones de correo electrónico a través de estándares arbitrarios, como rechazar direcciones que contienen caracteres válidos, como + y / , o imponer limitaciones de longitud arbitrarias. La internacionalización de direcciones de correo electrónico proporciona una gama de caracteres mucho más amplia que la que permiten muchos algoritmos de validación actuales, como todos los caracteres Unicode por encima de U + 0080, codificados como UTF-8 .
- Herramientas algorítmicas: los sitios web grandes, los remitentes de correo masivo y los spammers requieren herramientas eficientes para validar las direcciones de correo electrónico. Tales herramientas dependen de algoritmos heurísticos y modelos estadísticos . [30]
- Reputación del remitente: la reputación del remitente de un correo electrónico se puede utilizar para intentar verificar si el remitente es confiable o un potencial spammer. Los factores que pueden incorporarse en una evaluación de la reputación del remitente incluyen la calidad del contacto anterior o el contenido proporcionado por, y los niveles de participación de, la dirección IP o la dirección de correo electrónico del remitente.
- Verificación basada en navegador: los formularios HTML5 implementados en muchos navegadores permiten que el navegador maneje la validación de la dirección de correo electrónico. [31]
Algunas empresas ofrecen servicios para validar una dirección de correo electrónico, a menudo utilizando una interfaz de programación de aplicaciones , pero no hay garantía de que proporcione resultados precisos.
Internacionalización
El IETF lleva a cabo un grupo de trabajo técnico y de estándares dedicado a cuestiones de internacionalización de direcciones de correo electrónico, titulado Internacionalización de direcciones de correo electrónico (EAI, también conocido como IMA, dirección de correo internacionalizada). [32] Este grupo produjo RFC 6530 , 6531 , 6532 y 6533 , y continúa trabajando en RFC adicionales relacionadas con EAI.
El grupo de trabajo EAI del IETF publicó RFC 6530 "Descripción general y marco para el correo electrónico internacionalizado", que permitía utilizar caracteres no ASCII tanto en las partes locales como en el dominio de una dirección de correo electrónico. RFC 6530 proporciona correo electrónico basado en la codificación UTF-8 , que permite el repertorio completo de Unicode . RFC 6531 proporciona un mecanismo para que los servidores SMTP negocien la transmisión del contenido SMTPUTF8 .
Los conceptos básicos de EAI implican el intercambio de correo en UTF-8. Aunque la propuesta original incluía un mecanismo de degradación para los sistemas heredados, ahora se ha eliminado. [33] Los servidores locales son responsables de la parte local de la dirección, mientras que el dominio estaría restringido por las reglas de los nombres de dominio internacionalizados , aunque todavía se transmite en UTF-8. El servidor de correo también es responsable de cualquier mecanismo de asignación entre el formulario IMA y cualquier alias ASCII.
EAI permite a los usuarios tener una dirección localizada en un guión o juego de caracteres del idioma nativo, así como un formulario ASCII para comunicarse con sistemas heredados o para uso independiente del guión. Las aplicaciones que reconocen nombres de dominio y direcciones de correo internacionalizados deben tener facilidades para convertir estas representaciones.
Se espera una demanda significativa de tales direcciones en China, Japón, Rusia y otros mercados que tienen grandes bases de usuarios en un sistema de escritura no latino.
Por ejemplo, además del dominio de nivel superior .in , el gobierno de la India en 2011 [34] obtuvo la aprobación para ".bharat", (de Bhārat Gaṇarājya ), escrito en siete escrituras diferentes [35] [36] para su uso por hablantes de gujrati, marathi, bangali, tamil, telugu, punjabi y urdu. La empresa india XgenPlus.com afirma ser el primer proveedor de buzones de correo EAI del mundo, [37] y el gobierno de Rajasthan ahora proporciona una cuenta de correo electrónico gratuita en el dominio राजस्थान.भारत para todos los ciudadanos del estado. [38] Una empresa de medios líder, Rajasthan Patrika, lanzó su dominio IDN पत्रिका.भारत con correo electrónico contactable.
Ejemplos de internacionalización
Las direcciones de ejemplo a continuación no serían manejadas por servidores basados en RFC 5322, pero están permitidas por RFC 6530. Los servidores que cumplan con esto podrán manejar estas:
- Alfabeto latino con diacríticos : Pelé@example.com
- Alfabeto griego : δοκιμή@παράδειγμα.δοκιμή
- Caracteres chinos tradicionales : 我 買 @ 屋企. 香港
- Caracteres japoneses : 二 ノ 宮 @ 黒 川. 日本
- Caracteres cirílicos : медведь@с-балалайкой.рф
- Caracteres devanagari : संपर्क@डाटामेल.भारत
Apoyo a la internacionalización
- Postfix mailer admite correo internacionalizado desde 2015-02-08 con una versión estable 3.0.0. [39]
- Google admite el envío de correos electrónicos desde y hacia dominios internacionalizados, pero no permite el registro de direcciones de correo electrónico que no sean ASCII. [40]
- Microsoft agregó una funcionalidad similar en Outlook 2016 [41]
- DataMail lanza soporte de correo electrónico internacionalizado para 8 idiomas indios utilizando la plataforma de correo electrónico XgenPlus en India. [42]
Documentos de normas
- RFC 821 - Protocolo simple de transferencia de correo (obsoleto por RFC 2821)
- RFC 822 - Estándar para el formato de mensajes de texto de Internet ARPA (obsoleto por RFC 2822) (Errata)
- RFC 1035 - Nombres de dominio, implementación y especificación (erratas)
- RFC 1123 - Requisitos para hosts de Internet, aplicaciones y soporte (actualizado por RFC 2821, RFC 5321) (erratas)
- RFC 2142 - Nombres de buzones de correo para servicios, roles y funciones comunes (erratas)
- RFC 2821 - Protocolo simple de transferencia de correo (obsoleto RFC 821, actualizaciones RFC 1123, obsoleto por RFC 5321) (erratas)
- RFC 2822 - Formato de mensaje de Internet (obsoleto RFC 822, obsoleto por RFC 5322) (Fe de erratas)
- RFC 3696 - Técnicas de aplicación para la verificación y transformación de nombres (erratas)
- RFC 4291 - Arquitectura de direccionamiento IP versión 6 (actualizado por RFC 5952) (erratas)
- RFC 5321 - Protocolo simple de transferencia de correo (obsoleta RFC 2821, actualiza RFC 1123) (erratas)
- RFC 5322 - Formato de mensaje de Internet (obsoleto RFC 2822, actualizado por RFC 6854) (Errata)
- RFC 5952: una recomendación para la representación de texto de direcciones IPv6 (actualiza RFC 4291) (erratas)
- RFC 6530: descripción general y marco para el correo electrónico internacionalizado (obsoletas RFC 4952, 5504, 5825)
- RFC 6531 - Extensión SMTP para correo electrónico internacionalizado (obsoleta RFC 5336)
- RFC 6854 - Actualización al formato de mensaje de Internet para permitir la sintaxis de grupo en los campos de encabezado "De:" y "Remitente:" (Actualiza RFC 5322)
Ver también
- Técnicas anti-spam
- Cliente de correo electronico
- Casilla de correo electrónico
- Verificacion de Email
- Correo electrónico internacional
Notas
- ^ A veces un nombre de usuario, pero no siempre.
- ^ Escrito por J. Klensin, autor de RFC 5321
Referencias
- ^ J. Klensin (octubre de 2008). "Principios generales de sintaxis y modelo de transacción" . Protocolo simple de transferencia de correo . pag. 15. seg. 2.4. doi : 10.17487 / RFC5321 . RFC 5321 .
La parte local de un buzón DEBE SER tratada como sensible a mayúsculas y minúsculas.
- ^ J. Klensin (octubre de 2008). "Principios generales de sintaxis y modelo de transacción" . Protocolo simple de transferencia de correo . pag. 15. seg. 2.4. doi : 10.17487 / RFC5321 . RFC 5321 .
Sin embargo, aprovechar la distinción entre mayúsculas y minúsculas de las partes locales del buzón impide la interoperabilidad y se desaconseja.
- ^ "... puedes agregar o quitar los puntos de una dirección de correo sin cambiar la dirección de destino real; y todos irán a tu bandeja de entrada ..." , Google.com
- ^ Klensin, J. (octubre de 2008). "Límites y mínimos de tamaño" . Protocolo simple de transferencia de correo . IETF . segundo. 4.5.3.1. doi : 10.17487 / RFC5321 . RFC 5321 .
- ^ a b Klensin, J. (febrero de 2004). RFC 3696 . IETF . doi : 10.17487 / RFC3696 . Consultado el 1 de agosto de 2017 .: §3
- ^ Klensin, J. (octubre de 2008). RFC 5321 . IETF . segundo. 4.5.3.1.1. doi : 10.17487 / RFC5321 . Consultado el 1 de agosto de 2019 .
- ^ "Envíe correos electrónicos desde una dirección o alias diferente: utilice alias de Gmail" . Ayuda de Gmail . Archivado desde el original el 7 de diciembre de 2019 . Consultado el 13 de diciembre de 2019 .
- ^ "Regístrese en Windows Live" . Consultado el 26 de julio de 2008 .. Sin embargo, la frase está oculta, por lo que hay que comprobar la disponibilidad de una ID no válida, por ejemplo, me # 1 , o recurrir a una visualización alternativa, por ejemplo, vista sin estilo o fuente, para poder leerla.
- ^ "Caracteres en la parte local de una dirección de correo electrónico" . Consultado el 30 de marzo de 2016 .
- ^ "Se prohíben los nombres de dominio sin puntos de gTLD nuevos" . www.icann.org . ICANN . Consultado el 23 de marzo de 2020 .
- ^ ¿Las direcciones de correo electrónico distinguen entre mayúsculas y minúsculas? por Heinz Tschabitscher
- ^ "Recibir el correo de otra persona" . google.com .
- ^ "Filtro de correo electrónico de tamiz: extensión de subdirección" . IETF . Consultado el 9 de febrero de 2019 .
- ^ "Una descripción general del sistema de mensajes de Andrew" (PDF) .
- ^ "Utilizando un alias de dirección" . google.com .
- ^ "Direcciones desechables en Yahoo Mail - Ayuda de Yahoo - SLN3523" . help.yahoo.com .
- ^ "Outlook.com también admite alias de correo electrónico más simples" . Dentro de Windows . Archivado desde el original el 20 de febrero de 2014.CS1 maint: bot: estado de URL original desconocido ( enlace )
- ^ "Direcciones y alias" . protonmail.com .
- ^ "Más direccionamiento y direccionamiento de subdominios" . www.fastmail.com . Archivado desde el original el 6 de octubre de 2020 . Consultado el 6 de octubre de 2020 .
- ^ "Preguntas frecuentes de postale.io sobre subdireccionamiento" . postale.io . Archivado desde el original el 6 de octubre de 2020 . Consultado el 6 de octubre de 2020 .
- ^ "¿Puedo usar [email protected] con mi cuenta Pobox?" . helppot.pobox.com . nd Archivado desde el original el 3 de octubre de 2020 . Consultado el 3 de octubre de 2020 .
Pobox admite el uso de "+ anystring" (más extensiones) con cualquier dirección.
- ^ "MeMail" . www.memail.com . Consultado el 6 de octubre de 2020 .
- ^ a b "Dot-Qmail, controla la entrega de mensajes de correo" . Archivado desde el original el 26 de enero de 2012 . Consultado el 27 de enero de 2012 .
- ^ Alféizar, Dave. "4.1.5. Direcciones de extensión" . La vida con qmail . Consultado el 27 de enero de 2012 .
- ^ "Parámetros de configuración de Postfix" . postfix.org .
- ^ "Parámetros de configuración de Exim," local_part_suffix " " . exim.org .
- ^ Gina Trapani (2005) "Direcciones de Gmail instantáneas desechables"
- ^ "Cómo Domino formatea la dirección de Internet del remitente en los mensajes salientes" . Centro de conocimiento de IBM . Consultado el 23 de julio de 2019 .
- ^ "Mejores prácticas comunes del remitente de M3AAWG, versión 3" (PDF) . Grupo de Trabajo de Mensajería, Malware y Anti-Abuso Móvil . Febrero de 2015 . Consultado el 23 de julio de 2019 .
- ^ Técnicas de verificación y validación para la garantía de calidad de direcciones de correo electrónico por Jan Hornych 2011, Universidad de Oxford
- ^ "4.10 Formularios - HTML5" . w3.org .
- ^ "Páginas de estado Eai" . Internacionalización de direcciones de correo electrónico (Active WG) . IETF. 17 de marzo de 2006 - 18 de marzo de 2013 . Consultado el 26 de julio de 2008 .
- ^ "Internacionalización de direcciones de correo electrónico (eai)" . IETF . Consultado el 30 de noviembre de 2010 .
- ^ "2011-01-25 - Aprobación de la delegación de los siete dominios de nivel superior que representan a la India en varios idiomas - myICANN.org" . features.icann.org .
- ^ "Nombres de dominio internacionalizados (IDN) | Registry.In" . registro.in . Consultado el 17 de octubre de 2016 .
- ^ "Ahora, obtenga su dirección de correo electrónico en hindi - The Economic Times" . The Economic Times . Consultado el 17 de octubre de 2016 .
- ^ "Aceptación universal en la India" .
- ^ "देश में पहला, प्रदेश के हर नागरिक के लिए मुफ्त ई-वॉल्ट और ई-मेल की सुविधा शुरू - वसुन्धरा राजे" . वसुन्धरा राजे (en hindi). 2017-08-18 . Consultado el 20 de agosto de 2017 .
- ^ " ' Versión estable de Postfix 3.0.0' - MARC" . marc.info .
- ^ "Un primer paso hacia un correo electrónico más global" . Blog oficial de Google . Consultado el 6 de agosto de 2014 .
- ^ "Novedades de Outlook 2016 para Windows" , support.office.com
- ^ "DataMail lanza un servicio de correo electrónico lingüístico gratuito en ocho idiomas indios" . Tech2 . Consultado el 25 de noviembre de 2017 .
enlaces externos
- Validar la dirección de correo electrónico en Wikilibros
- Mejores prácticas en Wikilibros
- Medios relacionados con la dirección de correo electrónico en Wikimedia Commons