Una dirección de correo electrónico identifica un buzón de correo electrónico al que se entregan los mensajes. Si bien los primeros sistemas de mensajería utilizaban una variedad de formatos para dirigirse, hoy en día las direcciones de correo electrónico siguen un conjunto de reglas específicas originalmente estandarizadas por el Internet Engineering Task Force (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 solo a addr-spec en la Sección 3.4 de RFC 5322. El RFC define la dirección de manera más amplia como un buzón o un grupo . Un valor de buzón puede ser name-addr , que contiene un nombre para mostrar y addr-spec , o el más común addr-spec solo.
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 corchetes. 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 mayúsculas y minúsculas, [2] por ejemplo, que el sistema de correo en el dominio ejemplo.com trate a John. Smith 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 por parte de los usuarios a un subconjunto de los caracteres técnicamente permitidos.
Con la introducción de nombres de dominio internacionalizados , se están avanzando en los esfuerzos para permitir caracteres no ASCII en las direcciones de correo electrónico.
Una dirección de correo electrónico consta de dos partes, una parte local (a veces un nombre de usuario, pero no siempre) y un dominio; Si el dominio es un nombre de dominio en lugar de una dirección IP, entonces el cliente SMTP utiliza el nombre de dominio para buscar la dirección IP del intercambio de correo. El formato general de una dirección de correo electrónico es parte local @ dominio , 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 servidores de correo en Internet utiliza el Protocolo simple de transferencia de correo (SMTP), definido en RFC 5321 y 5322, y extensiones como RFC 6531. Se puede acceder a los buzones de correo y administrarlos mediante aplicaciones en computadoras personales, dispositivos móviles o sitios de correo web , utilizando 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 servidor 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 distintos del host del buzón de correo final. Los remitentes de correo electrónico y los sistemas de retransmisión intermedia no deben asumir que no distingue entre mayúsculas y minúsculas, ya que el host del buzón de correo final puede tratarlo o no como tal. Un único buzón puede recibir correo para varias direcciones de correo electrónico, si lo configura el administrador. Por el contrario, una única dirección de correo electrónico puede ser el alias de una lista de distribución para muchos buzones de correo. Los alias de correo electrónico , las listas de correo electrónico , las subdirecciones y las direcciones generales (estas últimas son buzones de correo que reciben mensajes independientemente de la parte local) son patrones comunes para lograr una variedad de objetivos de entrega.
Las direcciones que se encuentran en los campos del 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 del correo. Si bien las direcciones del sobre y del encabezado pueden ser iguales, las direcciones de correo electrónico falsificadas (también llamadas direcciones de correo electrónico falsificadas ) se ven a menudo en spam , phishing y muchas otras estafas basadas en Internet. Esto ha dado lugar a varias iniciativas cuyo objetivo es hacer que estas falsificaciones de correos electrónicos fraudulentos sean más fáciles de detectar.
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 se encuentran en RFC 5322 (secciones 3.2.3 y 3.4.1) y RFC 5321, con una forma más legible en el RFC 3696 informativo (escrito por J. Klensin, autor de RFC 5321) y el erratas asociadas.
Una dirección de correo electrónico también puede tener un "nombre para mostrar" asociado (nombre para mostrar) para el destinatario, que precede a la especificación de la dirección, ahora rodeada por corchetes angulares, por ejemplo: John Smith <[email protected]> . [5] Los spammers y los phishers de correo electrónico a menudo utilizan la "suplantación de nombre para mostrar" para engañar a sus víctimas, utilizando un nombre para mostrar falso o una dirección de correo electrónico diferente como nombre para mostrar. [6]
Las formas anteriores de direcciones de correo electrónico para otras redes además de Internet incluían otras notaciones, como la requerida por X.400 y la notación de ruta de explosión UUCP , en la que la dirección se proporcionaba en forma de una secuencia de computadoras a través de las cuales debía pasar el mensaje. ser retransmitido. Esto fue ampliamente utilizado durante varios años, pero fue reemplazado por los estándares de Internet promulgados por el Internet Engineering Task Force (IETF).
La parte local de la dirección de correo electrónico puede no estar entrecomillada o puede estar entre comillas.
Si no está entre comillas, puede utilizar cualquiera de estos caracteres ASCII :
Aa Zy aaz0a9!#$%&'*+-/=?^_`{|}~., siempre que no sea el primer ni el último carácter y siempre que no aparezca consecutivamente (por ejemplo, [email protected]no está permitido). [7]Si está entre comillas, 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. A diferencia de las partes locales sin comillas, las direcciones ".John.Doe"@example.comy están permitidas."John.Doe."@example.com"John..Doe"@example.com
La longitud total máxima de la parte local de una dirección de correo electrónico es de 64 octetos. [8]
"(),:;<>@[\]se permiten con restricciones (solo se permiten dentro de una cadena entrecomillada, como se describe en el párrafo siguiente, y en esa cadena entrecomillada, cualquier barra invertida o comilla doble debe ir precedida una vez por una barra invertida);john.smith(comment)@example.comy (comment)[email protected]ambos son equivalentes a [email protected].Además de los caracteres ASCII anteriores, los caracteres internacionales superiores a U+007F, codificados como UTF-8 , están permitidos por RFC 6531 cuando EHLO especifica SMTPUTF8 , aunque incluso los sistemas de correo que admiten SMTPUTF8 y 8BITMIME pueden restringir qué caracteres usar al asignar datos locales. -partes.
Una parte local es una cadena de puntos o una cadena entre comillas; no puede ser una combinación. Sin embargo, las cadenas y caracteres entre comillas no se utilizan habitualmente. [ cita necesaria ] RFC 5321 también advierte que "un host que espera recibir correo DEBE evitar definir buzones de correo donde la parte local requiera (o use) el formulario de cadena entre comillas".
La parte local postmasterse 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, todas las demás partes locales distinguen entre mayúsculas y minúsculas y, por lo tanto [email protected], [email protected]especifican buzones de correo diferentes; 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 gran variedad de caracteres especiales técnicamente válidos, en la práctica las organizaciones, los servicios de correo, los servidores de correo y los clientes de correo a menudo no los aceptan todos. Por ejemplo, Windows Live Hotmail solo permite la creación de direcciones de correo electrónico utilizando caracteres alfanuméricos, punto ( .), guión bajo ( _) y guión ( -). [9] El consejo común es evitar el uso de algunos caracteres especiales para evitar el riesgo de correos electrónicos rechazados. [10]
Según RFC 5321 2.3.11 Buzón y dirección, "la parte local DEBE ser interpretada y asignada semántica únicamente 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.
La interpretación de la parte local 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 buzones que difieren sólo 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 para determinar la identidad de la cuenta. [12]
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. Normalmente, los caracteres que siguen a un signo más y con menor frecuencia los caracteres que siguen a un signo menos, por lo que fred+bah@dominio y fred+foo@dominio pueden terminar en la misma bandeja de entrada que fred+@dominio o incluso como fred@dominio. Por ejemplo, la dirección [email protected] indica la misma dirección de entrega que [email protected] . RFC 5233 [13] se refiere a esta convención como subdireccionamiento , pero también se la conoce como direccionamiento plus , direccionamiento etiquetado o extensiones de correo . Esto puede resultar útil para etiquetar correos electrónicos para clasificarlos y controlar el spam. [14]
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), [15] Runbox (más), [16] Gmail (más), [14] Rackspace. (más), Yahoo! Mail Plus (guión), [17] iCloud de Apple (más), Outlook.com (más), [18] Proton Mail (más), [19] Fastmail (más y direccionamiento de subdominio), [20] postale.io (más ), [21] Pobox (más), [22] MeMail (más), [23] MMDF (es igual), Qmail y Courier Mail Server (guión). [24] [25] Postfix y Exim permiten configurar un separador arbitrario del conjunto de caracteres legales. [26] [27]
El texto de la etiqueta se puede utilizar para aplicar filtrado [24] o para crear direcciones de correo electrónico desechables o de un solo uso . [28]
La parte del nombre de dominio de una dirección de correo electrónico debe ajustarse a pautas estrictas: debe cumplir 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: [7] : §2
Ahacia Zy ahacia z;0hasta 9, siempre que los nombres de dominio de nivel superior no sean exclusivamente numéricos;-, 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 una dirección IP literal, entre 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 como parte local como como nombre de dominio.
Se permiten comentarios tanto en el dominio como en la parte local; por ejemplo, john.smith@(comment)example.comy [email protected](comment)son equivalentes a [email protected].
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 deben poder entregarse. Cabe destacar para el correo electrónico example , invalid , example.com , example.net y example.org .
[email protected][email protected][email protected](parte local de una letra)[email protected][email protected](puede redirigirse a la [email protected]bandeja de entrada según el servidor de correo)name/[email protected](las barras son un carácter imprimible y están permitidas)admin@example(nombre de dominio local sin TLD , aunque ICANN desaconseja encarecidamente las direcciones de correo electrónico sin punto [29] )[email protected](ver la Lista de dominios de nivel superior de Internet )" "@example.org(espacio entre comillas)"john..doe"@example.org(citado con doble punto)[email protected](ruta de host bangificada utilizada para correos uucp)"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com(incluya caracteres que no sean letras Y varios signos de arroba , el primero entre comillas dobles)user%[email protected](% de ruta de correo escapada a [email protected] a través de ejemplo.org)[email protected](la parte local termina con un carácter no alfanumérico de la lista de caracteres imprimibles permitidos)postmaster@[123.123.123.123](Se permiten direcciones IP en lugar de dominios cuando están entre corchetes, pero no se recomiendan)postmaster@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334](IPv6 usa una sintaxis diferente)_test@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334](comience con guión bajo sintaxis diferente)I❤️CHOCOLATE🍫@example.com( los emoji solo están permitidos con SMTPUTF8)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<h>i[j\k][email protected](ninguno de los caracteres especiales en esta parte local está permitido fuera de las comillas)just"not"[email protected](las cadenas entrecomilladas deben estar separadas por puntos o ser el único elemento que compone la parte local)this is"not\[email protected](Los espacios, comillas y barras invertidas solo pueden existir cuando están entre comillas y precedidos por una barra invertida)this\ still\"not\\[email protected](incluso si están precedidos por una barra invertida, los espacios, las comillas y las barras invertidas deben estar contenidos entre comillas)1234567890123456789012345678901234567890123456789012345678901234+x@example.com(la parte local tiene más de 64 caracteres)i.like.underscores@but_they_are_not_allowed_in_this_part(el guión bajo no está permitido en la parte del dominio)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 de números de teléfonos móviles, validación de correo postal y validación de fax.
Generalmente se reconoce que una dirección de correo electrónico tiene dos partes unidas con un signo de arroba ( @ ), aunque las especificaciones técnicas detalladas en RFC 822 y RFC posteriores son más extensas. [30]
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 otras técnicas y verifican la existencia del buzón con sistemas relevantes, como el Sistema de nombres de dominio para el dominio o utilizan 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 directorios , o las devoluciones de llamada pueden reportarse como spam y dar lugar a una lista en un DNSBL .
Se pueden utilizar varias técnicas de validación para validar la dirección de correo electrónico de un usuario. Por ejemplo, [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.
El IETF dirige 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). [34] Este grupo produjo RFC 6530, 6531, 6532 y 6533, y continúa trabajando en RFC adicionales relacionados con EAI.
El grupo de trabajo EAI del IETF publicó RFC 6530 "Descripción general y marco para el correo electrónico internacionalizado", que permitió el uso de 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 abandonado. [35] 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 aún se transmite en UTF-8. El servidor de correo también es responsable de cualquier mecanismo de mapeo entre el formulario IMA y cualquier alias ASCII.
EAI permite a los usuarios tener una dirección localizada en una escritura o conjunto de caracteres del idioma nativo, así como un formulario ASCII para comunicarse con sistemas heredados o para uso independiente de la escritura. Las aplicaciones que reconocen nombres de dominio y direcciones de correo internacionalizados deben tener funciones para convertir estas representaciones.
Se espera una demanda significativa de este tipo de 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 [36] obtuvo la aprobación para ".bharat", (de Bhārat Gaṇarājya ), escrito en siete escrituras diferentes [37] [38] 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, [39] y el Gobierno de Rajasthan ahora proporciona una cuenta de correo electrónico gratuita en el dominio राजस्थान.भारत para cada ciudadano del estado. [40] Una empresa de medios líder, Rajasthan Patrika, lanzó su dominio IDN पत्रिका.भारत con correo electrónico contactable.
Las direcciones de ejemplo siguientes no serían manejadas por servidores basados en RFC 5322, pero sí están permitidas por RFC 6530. Los servidores que cumplan con esto podrán manejar estas:
La parte local de un buzón DEBE tratarse distinguiendo entre mayúsculas y minúsculas.
Sin embargo, aprovechar la distinción entre mayúsculas y minúsculas de las partes locales del buzón impide la interoperabilidad y no se recomienda.
Pobox admite el uso de "+anystring" (más extensiones) con cualquier dirección.
Validar dirección de correo electrónico en WikilibrosMejores prácticas en Wikilibros
Medios relacionados con la dirección de correo electrónico en Wikimedia Commons
