Hispanopedia Wiki
Articulo de referencia

Dirección de correo electrónico

Una dirección de correo electrónico identifica un buzón al que se envían los mensajes. Si bien los primeros sistemas de mensajería utilizaban diversos formatos de dirección, las...

Hispanopedia WikiContenido en espanolLectura gratuita

Una dirección de correo electrónico identifica un buzón al que se envían los mensajes. Si bien los primeros sistemas de mensajería utilizaban diversos formatos de dirección, las direcciones de correo electrónico actuales siguen un conjunto específico de reglas estandarizadas originalmente por el Grupo de Trabajo de Ingeniería de Internet (IETF) en la década de 1980 y actualizadas por los RFC 5322 y 6854. El término "dirección de correo electrónico" en este artículo se refiere únicamente a la especificación de dirección (addr-spec ) de la Sección 3.4 del RFC 5322. El RFC define la dirección de forma más amplia como un buzón o un grupo . El valor de un buzón puede ser una dirección de nombre ( name-addr) , que contiene un nombre para mostrar y una especificación de dirección (addr-spec) , o la especificación de dirección (addr-spec) , que es más común .  

Una dirección de correo electrónico, como jane.smith@example.com , 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 estipula que la parte local distingue entre mayúsculas y minúsculas, [ 1 ] también insta a que los hosts receptores entreguen los mensajes de forma independiente de las mayúsculas y minúsculas, [ 2 ] por ejemplo, que el sistema de correo en el dominio example.com trate a Jane.Smith como equivalente a jane.smith . (Algunos sistemas de correo incluso tratan ambos como equivalentes a jane smith . [ 3 ] ) Los sistemas de correo electrónico a menudo limitan la elección del nombre del usuario a un subconjunto de los caracteres permitidos por los RFC. Con la introducción de los nombres de dominio internacionalizados , se están realizando esfuerzos para permitir caracteres no ASCII en las direcciones de correo electrónico.

Debido a la omnipresencia del correo electrónico hoy en día, muchas páginas web y servicios que ofrecen perfiles o cuentas de usuario utilizan direcciones de correo electrónico como nombres de usuario habituales. [ 4 ] Por ejemplo, si un usuario quiere iniciar sesión en su perfil de videojuegos de Xbox Live , utilizaría su dirección de correo electrónico como nombre de usuario de su cuenta de Microsoft , aunque en este caso el servicio no sea el correo electrónico.

Transporte de mensajes

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, el cliente SMTP busca la dirección IP del servidor de correo (MX) de dicho dominio. El formato general de una dirección de correo electrónico es parte local @ dominio , por ejemplo, jsmith@ [ 192.168.1.2 ] o jsmith@example.com . El cliente SMTP transmite el mensaje al servidor de correo, que puede reenviarlo a otro servidor, hasta que finalmente llega al servidor del destinatario.

La transmisión de correo electrónico desde el ordenador del remitente y entre servidores de correo en Internet utiliza el Protocolo Simple de Transferencia de Correo (SMTP), definido en los RFC 5321 y 5322 , y extensiones como el RFC 6531. Se puede acceder a los buzones de correo y gestionarlos mediante aplicaciones en ordenadores personales, dispositivos móviles o sitios web de correo que utilicen 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) del dominio del destinatario. Un registro de recursos de intercambio de correo ( registro MX ) contiene el nombre del servidor de correo del destinatario. En ausencia de un registro MX, un registro de dirección (ya sea A o AAAA ) especifica directamente el servidor de correo.

La parte local de una dirección de correo electrónico no tiene relevancia para los sistemas de retransmisión de correo intermedios, salvo para el servidor de correo final. Los remitentes y los sistemas de retransmisión intermedios no deben asumir que no distingue entre mayúsculas y minúsculas, ya que el servidor de correo final puede o no tratarla como tal. Un único buzón puede recibir correo para varias direcciones, si así lo configura el administrador. Del mismo modo, una única dirección de correo electrónico puede ser el alias de una lista de distribución para varios buzones. Los alias de correo electrónico , las listas de correo electrónico , el subdireccionamiento y las direcciones comodín (buzones que reciben mensajes independientemente de la parte local) son patrones comunes para lograr diversos objetivos de entrega.

Las direcciones contenidas en los campos de encabezado de un mensaje de correo electrónico no son utilizadas directamente por los servidores de correo para entregar el mensaje. En la transferencia de correo SMTP, el sistema remitente comunica las direcciones de origen y destino; esta información a veces se denomina "sobre del mensaje". Si bien las direcciones del sobre y del encabezado pueden ser las mismas, esto no es estrictamente necesario, y las direcciones de correo electrónico falsificadas o suplantadas se ven con frecuencia en el spam , el phishing y muchas otras estafas en Internet. Esto ha dado lugar a varias iniciativas destinadas a facilitar la detección de dichas falsificaciones de correos electrónicos fraudulentos.

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. [ 5 ] 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 dada en el RFC 3696 informativo (escrito por J. Klensin, el autor de RFC 5321 [ 6 ] ) y las erratas asociadas.

Una dirección de correo electrónico también puede tener un "nombre para mostrar" (Display Name) asociado para el destinatario, que precede a la especificación de la dirección, rodeado de corchetes angulares en ese caso, por ejemplo: Jane  Smith  <jane.smith@example.org> . [ 7 ] Los remitentes de correo basura y los estafadores de phishing suelen utilizar la suplantación de identidad del 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. [ 8 ]

Las primeras formas de direcciones de correo electrónico para redes distintas a Internet incluían otras notaciones, como la requerida por X.400 y la notación de ruta UUCP ( con signo de exclamación), en la que la dirección se especificaba como una secuencia de ordenadores a través de los cuales debía transmitirse el mensaje. Este sistema se utilizó ampliamente 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 aparecer sin comillas o entre comillas.

Si no se incluye entre comillas, puede utilizar cualquiera de estos caracteres ASCII :

  • letras latinas mayúsculas y minúsculas Aa Zy aaz
  • dígitos 0a9
  • caracteres imprimibles!#$%&'*+-/=?^_`{|}~
  • punto ., siempre que no sea el primer ni el último carácter y siempre que tampoco aparezca consecutivamente (por ejemplo, Jane..Doe@example.comno está permitido). [ 9 ]

Si se cita, puede contener espacio, tabulación horizontal (HT), cualquier gráfico ASCII excepto barra invertida y comilla, y un par entre comillas que consiste en una barra invertida seguida de HT, espacio o cualquier gráfico ASCII; también puede dividirse entre líneas en cualquier lugar donde aparezca HT o espacio. A diferencia de las partes locales sin comillas, se permiten las direcciones ".Jane.Doe"@example.com, "Jane.Doe."@example.comy ."Jane..Doe"@example.com

La longitud total máxima de la parte local de una dirección de correo electrónico es de 64 octetos. [ 10 ]

  • 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);
  • Se permiten comentarios entre paréntesis, ya sea al principio o al final de la parte local; por ejemplo, jane.smith(comment)@example.comy (comment)jane.smith@example.comson ambos equivalentes a jane.smith@example.com.

Además de los caracteres ASCII mencionados anteriormente, la RFC 6531 permite el uso de caracteres internacionales superiores a U+007F, codificados como UTF-8 , cuando el EHLO especifica SMTPUTF8 , aunque incluso los sistemas de correo que admiten SMTPUTF8 y 8BITMIME pueden restringir los caracteres que se utilizan al asignar partes locales.

La parte local puede ser una cadena de puntos o una cadena entre comillas; no puede ser una combinación de ambas. Sin embargo, las cadenas y caracteres entre comillas no se utilizan habitualmente. El RFC 5321 también advierte que «un host que espera recibir correo DEBERÍA evitar definir buzones donde la parte local requiera (o utilice) la forma 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 sí distinguen entre mayúsculas y minúsculas janes@example.comy , por lo tanto JaneS@example.com, especifican buzones diferentes; sin embargo, muchas organizaciones consideran que las letras mayúsculas y minúsculas son equivalentes. De hecho, la RFC 5321 advierte que «un servidor que espera recibir correo DEBERÍA evitar definir buzones donde... la parte local distinga entre mayúsculas y minúsculas».

A pesar de la amplia gama de caracteres especiales que son técnicamente válidos, en la práctica, las organizaciones, los servicios de correo, los servidores de correo y los clientes de correo no suelen aceptarlos todos. Por ejemplo, Windows Live Hotmail solo permite crear direcciones de correo electrónico utilizando caracteres alfanuméricos, punto ( .), guion bajo ( _) y guion ( -). [ 11 ] Se recomienda evitar el uso de algunos caracteres especiales para evitar el riesgo de que los correos electrónicos sean rechazados. [ 12 ]

Según la RFC 5321 2.3.11 Buzón y Dirección, «la parte local DEBE ser interpretada y tener asignada una 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 completamente 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 diferenciar buzones que solo se distinguen por el uso de mayúsculas en los caracteres de la parte local, aunque esto no es muy común. [ 13 ] Por ejemplo, Gmail ignora todos los puntos en la parte local de la dirección de correo electrónico del usuario para determinar la identidad de la cuenta. [ 14 ]

Subdireccionamiento

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 menos frecuencia, los que siguen a un signo menos (-), por lo que fred+bar@dominio y fred+foo@dominio podrían terminar en la misma bandeja de entrada que fred+@dominio o incluso como fred@dominio. Por ejemplo, la dirección joeuser+tag@example.com indica la misma dirección de entrega que joeuser@example.com . El RFC 5233 [ 15 ] se refiere a esta convención como subdireccionamiento , pero también se conoce como direccionamiento con signo más , direccionamiento etiquetado o extensiones de correo . Esto puede ser útil para etiquetar correos electrónicos para su clasificación y para el control de spam. [ 16 ] 

Las direcciones de este tipo, que utilizan varios separadores entre el nombre base y la etiqueta, son compatibles con varios servicios de correo electrónico, incluidos Andrew Project (plus), [ 17 ] Runbox (plus), [ 18 ] Gmail (plus), [ 16 ] Rackspace (plus), Yahoo! Mail Plus (guion), [ 19 ] iCloud de Apple (plus), Outlook.com (plus), [ 20 ] Mailfence (plus), [ 21 ] Proton Mail (plus), [ 22 ] Fastmail (plus y direccionamiento de subdominio ), [ 23 ] postale.io (plus), [ 24 ] Pobox (plus), [ 25 ] MeMail (plus), [ 26 ] y MTA como MMDF (igual), Qmail y Courier Mail Server (guion). [ 27 ] [ 28 ] Postfix y Exim permiten configurar un separador arbitrario del conjunto de caracteres válido. [ 29 ] [ 30 ]

El texto de la etiqueta puede usarse para aplicar filtros, [ 27 ] o para crear direcciones de correo electrónico de un solo uso o desechables . [ 31 ]

Dominio

La parte del nombre de dominio de una dirección de correo electrónico debe ajustarse a directrices estrictas: debe coincidir con los requisitos de un nombre de host , una lista de etiquetas DNS separadas por puntos , cada etiqueta limitada a una longitud de 63 caracteres y compuesta por: [ 9 ] : §2

  • Letras latinas mayúsculas y minúsculas Aa Zy aa z;
  • Dígitos 0a 9, siempre que los nombres de dominio de nivel superior no sean todos numéricos;
  • Guion -, siempre que no sea el primer ni el último carácter.

Esta regla se conoce como regla LDH (letras, dígitos, guion). Además, el dominio puede ser una dirección IP literal, rodeada de 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 no ASCII. En los sistemas de correo que cumplen con RFC 6531 y RFC 6532, una dirección de correo electrónico puede estar codificada como UTF-8 , tanto una parte local como un nombre de dominio.

Se permiten comentarios tanto en el dominio como en la parte local; por ejemplo, jane.smith@(comment)example.comy jane.smith@example.com(comment)son equivalentes a jane.smith@example.com.

RFC 2606 especifica que ciertos dominios, por ejemplo, los destinados a documentación y pruebas, no deben ser resolubles y que, como resultado, el correo dirigido a buzones de correo en ellos y sus subdominios no debe poder entregarse. Cabe destacar para el correo electrónico example , invalid , example.com , example.net y example.org . 

Ejemplos

Direcciones de correo electrónico válidas

  • simple@example.com
  • very.common@example.com
  • FirstName.LastName@EasierReading.org(Se ignora el mayúscula/minúscula después de la @ y normalmente antes)
  • x@example.com(parte local de una letra)
  • long.email-address-with-hyphens@and.subdomains.example.com
  • user.name+tag+sorting@example.com(Puede ser redirigido a user.name@example.comla bandeja de entrada dependiendo del servidor de correo)
  • name/surname@example.com(Las barras diagonales son un carácter imprimible y están permitidas)
  • admin@example(nombre de dominio local sin TLD , aunque la ICANN desaconseja encarecidamente las direcciones de correo electrónico sin puntos [ 32 ] )
  • example@s.example(véase la lista de dominios de nivel superior de Internet )
  • " "@example.org(espacio entre las comillas)
  • "jane..doe"@example.org(entre comillas con doble punto)
  • mailhost!username@example.org(Ruta de host modificada utilizada para los servidores de correo UUCP)
  • "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com(incluir caracteres que no sean letras Y múltiples signos de arroba , el primero entre comillas dobles)
  • user%example.com@example.org(% ruta de correo escapada a user@example.com a través de example.org)
  • user-@example.org(parte local que 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 se desaconseja encarecidamente).
  • postmaster@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334](IPv6 utiliza una sintaxis diferente)
  • _test@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334](comienza con un guion bajo para una sintaxis diferente)

Direcciones de correo electrónico válidas con SMTPUTF8

  • I❤️CHOCOLATE@example.com( Los emojis solo están permitidos con SMTPUTF8)

Direcciones de correo electrónico no válidas

  • abc.example.com(sin el carácter @)
  • a@b@c@example.com(Solo se permite una @ fuera de las comillas)
  • a"b(c)d,e:f;g<h>i[j\k]l@example.com(ninguno de los caracteres especiales de esta sección local está permitido fuera de las comillas)
  • just"not"right@example.com(Las cadenas entre comillas deben estar separadas por puntos o ser el único elemento que compone la parte local).
  • this is"not\allowed@example.com(Los espacios, las comillas y las barras invertidas solo pueden aparecer dentro de cadenas entre comillas y precedidas por una barra invertida).
  • this\ still\"not\\allowed@example.com(Aunque se escapen (precedidos por una barra invertida), los espacios, las comillas y las barras invertidas deben ir 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(No se permite el guion bajo en la parte del dominio)

Validación y verificación

Las direcciones de correo electrónico se suelen solicitar en los sitios web para validar la existencia del usuario. Existen otros métodos de validación, como la validación del número de teléfono móvil, la validación del correo postal y la validación del fax.

Generalmente se reconoce que una dirección de correo electrónico consta de dos partes unidas por un signo de arroba ( @ ), aunque las especificaciones técnicas detalladas en el RFC 822 y los RFC posteriores son más extensas. [ 33 ]

Las direcciones de correo electrónico verificadas y sintácticamente correctas no garantizan la existencia de un buzón . Por ello, muchos servidores de correo utilizan otras técnicas y comprueban la existencia del buzón con sistemas relevantes, como el Sistema de Nombres de Dominio (DNS) del dominio, o mediante la verificación por devolución de llamada. Esta última es una solución imperfecta, ya que puede desactivarse para evitar ataques de recolección de directorios o puede ser reportada como spam y provocar su inclusión en una lista negra de DNS (DNSBL) .

Se pueden utilizar varias técnicas de validación para validar una dirección de correo electrónico de un usuario. Por ejemplo, [ 34 ]

  • Enlaces de verificación: La validación de la dirección de correo electrónico para la creación de cuentas en sitios web se realiza a menudo mediante el envío de un correo electrónico a la dirección proporcionada por el usuario con un enlace temporal especial. Al recibirlo, el usuario abre el enlace y activa la cuenta de inmediato. Las direcciones de correo electrónico también son útiles para enviar mensajes de un sitio web, como mensajes y acciones de los usuarios, directamente a la bandeja de entrada.
  • Estándares formales e informales: RFC 3696 proporciona recomendaciones específicas para validar identificadores de Internet, incluidas las direcciones de correo electrónico. Algunos sitios web intentan evaluar la validez de las direcciones de correo electrónico mediante estándares arbitrarios, como rechazar direcciones que contengan caracteres válidos, como + y / , o imponer limitaciones de longitud arbitrarias. La internacionalización de las direcciones de correo electrónico permite un rango de caracteres mucho mayor que el que admiten muchos algoritmos de validación actuales, como todos los caracteres Unicode superiores a U+0080, codificados como UTF-8 .
  • Herramientas algorítmicas: Los sitios web de gran tamaño, los remitentes de correo masivo y los spammers requieren herramientas eficientes para validar las direcciones de correo electrónico. Dichas herramientas dependen de algoritmos heurísticos y modelos estadísticos . [ 35 ]
  • Reputación del remitente: La reputación de un remitente de correo electrónico puede utilizarse para intentar verificar si es de confianza o un posible remitente de spam. Entre los factores que pueden incorporarse a la evaluación de la reputación del remitente se incluyen la calidad de las interacciones previas, el contenido proporcionado y el nivel de interacción con la dirección IP o la dirección de correo electrónico del remitente.
  • Verificación basada en el navegador: Los formularios HTML5 implementados en muchos navegadores permiten que la validación de la dirección de correo electrónico sea manejada por el navegador. [ 36 ]

Algunas empresas ofrecen servicios para validar una dirección de correo electrónico, a menudo mediante una API , pero no hay garantía de que proporcione resultados precisos.

Internacionalización

El IETF dirige un grupo de trabajo técnico y de estándares dedicado a los problemas de internacionalización de direcciones de correo electrónico, denominado Email Address Internationalization (EAI, también conocido como IMA, Internationalized Mail Address). [ 37 ] Este grupo elaboró ​​los RFC 6530 , 6531 , 6532 y 6533 , y continúa trabajando en RFC adicionales relacionados con EAI. 

El grupo de trabajo EAI del IETF publicó el RFC 6530, «Descripción general y marco para el correo electrónico internacionalizado», que permite el uso de caracteres no ASCII tanto en la parte local como en el dominio de una dirección de correo electrónico. El RFC 6530 contempla el correo electrónico basado en la codificación UTF-8 , que permite el uso de todo el repertorio de Unicode . El 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. Si bien la propuesta original incluía un mecanismo de degradación para sistemas heredados, este se ha descartado. [ 38 ] 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 se seguiría transmitiendo en UTF-8. El servidor de correo también es responsable de cualquier mecanismo de mapeo entre el formato IMA y cualquier alias ASCII.

EAI permite a los usuarios tener una dirección localizada en un alfabeto o conjunto de caracteres nativo, así como una representación ASCII para comunicarse con sistemas heredados o para uso independiente del alfabeto. Las aplicaciones que reconocen nombres de dominio y direcciones de correo electrónico internacionalizados deben contar con mecanismos para convertir estas representaciones.

Se prevé una demanda significativa de este tipo de direcciones en China, Japón, Rusia y otros mercados que cuentan con una gran base de usuarios de un sistema de escritura no basado en el alfabeto latino.

Por ejemplo, además del dominio de nivel superior .in , el gobierno de la India en 2011 [ 39 ] obtuvo la aprobación para ".bharat" (de Bhārat Gaṇarājya ), escrito en siete escrituras diferentes [ 40 ] [ 41 ] para uso de hablantes de gujarati, marathi, bengalí, tamil, telugu, punjabi y urdu. La empresa india XgenPlus.com afirma ser el primer proveedor de buzones de correo EAI del mundo, [ 42 ] y el Gobierno de Rajastán ahora proporciona una cuenta de correo electrónico gratuita en el dominio राजस्थान.भारत para cada ciudadano del estado. [ 43 ] Una importante empresa de medios, Rajasthan Patrika, lanzó su dominio IDN पत्रिका.भारत con un correo electrónico de contacto.

Las direcciones de ejemplo que se muestran a continuación no serían gestionadas por servidores basados ​​en RFC 5321 sin una extensión, pero están permitidas por la extensión UTF8SMTP de RFC 6530 y 6531. Los servidores compatibles con esto podrán gestionarlas:  

Véase también

Notas

  1. ↑ En el caso de una copia oculta (CCO) , la dirección de destino no aparece en absoluto en el encabezado.

Referencias

  1. ↑ J. Klensin (octubre de 2008). "Principios generales de sintaxis y modelo de transacción" . Protocolo simple de transferencia de correo . IETF . pág. 15. sec. 2.4. doi : 10.17487/RFC5321 . RFC 5321. La parte local de un buzón DEBE tratarse como sensible a mayúsculas y minúsculas.   
  2. ↑ J. Klensin (octubre de 2008). "Principios generales de sintaxis y modelo de transacción" . Protocolo simple de transferencia de correo . IETF . pág. 15. doi : 10.17487/RFC5321 . RFC 5321. Sin embargo, explotar la distinción entre mayúsculas y minúsculas de las partes locales del buzón dificulta la interoperabilidad y se desaconseja. 
  3. ↑ "...puedes agregar o quitar los puntos de una dirección de correo electrónico sin cambiar la dirección de destino real; y todos llegarán a tu bandeja de entrada..." , Google.com
  4. ↑ Morrison, Sara (06/09/2021). "Cómo una simple dirección de correo electrónico complica las cosas" . Vox . Consultado el 15/07/2024 .
  5. ↑ Klensin, J. (octubre de 2008). "Límites de tamaño y mínimos" . Protocolo simple de transferencia de correo . IETF . sec. 4.5.3.1. doi : 10.17487/RFC5321 . RFC 5321 . 
  6. ^ J. Klensin, RFC 5321 , IETF, octubre de 2008
  7. ↑ "Especificación de dirección" . Formato de mensaje de Internet . IETF . sec. 3.4. doi : 10.17487/RFC5322 . RFC 5322. Consultado el 14 de marzo de 2023 . 
  8. ↑ "Cómo detectar un ataque de suplantación de identidad" . cyber.nj.gov . 19 de noviembre de 2020. Consultado el 17 de abril de 2023 .
  9. ^ Klensin , J. (febrero de 2004). RFC 3696 . IETF . doi : 10.17487/RFC3696 . Consultado el 1 de agosto de 2017 .: §3
  10. ↑ Klensin, J. (octubre de 2008). RFC 5321. IETF . sec. 4.5.3.1.1. doi : 10.17487/RFC5321 . Recuperado el 1 de agosto de 2019 . 
  11. ↑ "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 un ID no válido, por ejemplo, me#1 , o recurrir a una visualización alternativa, por ejemplo, sin estilo o vista de código fuente, para poder leerla.
  12. ↑ "Caracteres en la parte local de una dirección de correo electrónico" . Consultado el 30 de marzo de 2016 .
  13. ↑ ¿ Las direcciones de correo electrónico distinguen entre mayúsculas y minúsculas? Archivado el 3 de junio de 2016 en Wayback Machine por Heinz Tschabitscher
  14. ↑ "Recibir correo de otra persona" . google.com .
  15. ↑ Murchison, K. (2008). Filtrado de correo electrónico Sieve: extensión de subdirecciones . IETF . doi : 10.17487/RFC5233 . RFC 5233. Recuperado el 9 de febrero de 2019 .
  16. 1 2 "Enviar correos electrónicos desde una dirección o alias diferente" . Ayuda de Gmail . Consultado el 13 de diciembre de 2023 .
  17. ↑ "Descripción general del sistema de mensajes Andrew" (PDF) . Consultado el 17 de abril de 2023 .
  18. ↑ "Subdireccionamiento/Direccionamiento Plus" . Consultado el 1 de enero de 2024 .
  19. ↑ "Direcciones desechables en Yahoo Mail" . Ayuda de Yahoo .
  20. ↑ Rivera, Rafael (17 de septiembre de 2013). "Outlook.com también admite alias de correo electrónico más simples con el signo "+" . Within Windows . Archivado del original el 20 de febrero de 2014. Recuperado el 4 de diciembre de 2023 .
  21. ↑ "Plus Addressing: La mejor manera de rastrear a los spammers en 2024" . mailfence.com . 3 de septiembre de 2024.
  22. ↑ "Direcciones y alias" . proton.me .
  23. ↑ "Dirección Plus y dirección de subdominio" . www.fastmail.com . Archivado del original el 6 de octubre de 2020. Consultado el 6 de octubre de 2020 .
  24. ↑ "Preguntas frecuentes de postale.io sobre subdirecciones" . postale.io . Archivado del original el 6 de octubre de 2020. Consultado el 6 de octubre de 2020 .
  25. ↑ "¿Puedo usar mi dirección+extensión@pobox.com con mi cuenta de Pobox?" . helpspot.pobox.com . nd Archivado del original el 3 de octubre de 2020. Consultado el 3 de octubre de 2020. Pobox admite el uso de "+cualquier cadena" (más extensiones) con cualquier dirección.
  26. ↑ "MeMail" . www.memail.com . Consultado el 6 de octubre de 2020 .
  27. 1 2 "Dot-Qmail, Control de la entrega de mensajes de correo" . Archivado del original el 26 de enero de 2012. Recuperado el 27 de enero de 2012 .
  28. ↑ Sill, Dave. "4.1.5. Direcciones de extensión" . Vida con qmail . Consultado el 27 de enero de 2012 .
  29. ↑ "Parámetros de configuración de Postfix" . postfix.org .
  30. ↑ "Parámetros de configuración de Exim, "local_part_suffix"" . exim.org .
  31. ↑ Gina Trapani (2005) "Direcciones de Gmail desechables instantáneas"
  32. ↑ "Prohibidos los nuevos nombres de dominio sin puntos gTLD" . www.icann.org . ICANN . Consultado el 23 de marzo de 2020 .
  33. ↑ "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 .
  34. ↑ "M3AAWG Sender Best Common Practices, Version 3" (PDF) . Grupo de trabajo sobre mensajería, malware y lucha contra el abuso móvil . Febrero de 2015. Consultado el 23 de julio de 2019 .
  35. ↑ Técnicas de verificación y validación para el aseguramiento de la calidad de las direcciones de correo electrónico, por Jan Hornych, 2011, Universidad de Oxford.
  36. ↑ "4.10 Formularios — HTML5" . w3.org . 
  37. ↑ "Páginas de estado de Eai" . Internacionalización de direcciones de correo electrónico (Grupo de trabajo activo) . IETF. 17 de marzo de 2006 - 18 de marzo de 2013. Consultado el 26 de julio de 2008 .
  38. ↑ "Internacionalización de direcciones de correo electrónico (eai)" . IETF . Consultado el 30 de noviembre de 2010 .
  39. ↑ "2011-01-25 - Aprobación de la delegación de los siete dominios de nivel superior que representan a la India en varios idiomas" . features.icann.org .
  40. ↑ "Nombres de dominio internacionalizados (IDN) | Registry.In" . registry.in . Consultado el 17 de octubre de 2016 .
  41. ↑ "Ahora, obtenga su dirección de correo electrónico en hindi" . The Economic Times . Consultado el 17 de octubre de 2016 .
  42. ↑ "Aceptación universal en la India" . 15 de febrero de 2017.
  43. ^ "देश में पहला, प्रदेश के हर नागरिक के लिए मुफ्त ई-वॉल्ट और ई-मेल की सुविधा शुरू - वसुन्धरा राजे" . वसुन्धरा राजे (en hindi). 2017-08-18 . Consultado el 20 de agosto de 2017 .

Lecturas adicionales

  • RFC 821 Protocolo simple de transferencia de correo (Obsoleto por RFC 2821 y 5321 )  
  • 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 (Errata) 
  • RFC 1123 Requisitos para hosts, aplicaciones y soporte de Internet (actualizado por RFC 2821 , 5321 ) (Errata)  
  • RFC 2142 Nombres de buzones para servicios, roles y funciones comunes (Errata) 
  • RFC 2821 Protocolo simple de transferencia de correo (sustituye a RFC 821 , actualiza RFC 1123 , obsoleto por RFC 5321 ) (Errata)    
  • Formato de mensaje de Internet RFC 2822 (Sustituye a RFC 822 , sustituido por RFC 5322 ) (Errata)   
  • RFC 3696 Técnicas de aplicación para la verificación y transformación de nombres (Errata) 
  • RFC 4291 Arquitectura de direccionamiento IP versión 6 (actualizada por RFC 5952 ) (Errata)  
  • RFC 5321 Protocolo simple de transferencia de correo ( RFC 2821 obsoleto , actualizaciones RFC 1123 ) (Erratas)   
  • RFC 5322 Formato de mensaje de Internet (Sustituye a RFC 2822 , actualizado por RFC 6854 ) (Errata)   
  • RFC 5598 Arquitectura de correo de Internet 
  • RFC 5952 Recomendación para la representación textual de direcciones IPv6 (actualiza RFC 4291 ) (Errata)  
  • RFC 6530: Descripción general y marco para el correo electrónico internacionalizado (sustituye a RFC 4952 , 5504 y 5825 ).  
  • RFC 6531 Extensión SMTP para correo electrónico internacionalizado (sustituye a RFC 5336 )  
  • RFC 6854 Actualización del formato de mensaje de Internet para permitir la sintaxis de grupo en los campos de encabezado "From:" y "Sender:" (actualiza RFC 5322 )  
  • Logotipo de WikibooksValidar dirección de correo electrónico en Wikibooks
  • Logotipo de WikibooksBuenas prácticas en Wikibooks
  • Logotipo de Wikimedia CommonsContenido multimedia relacionado con direcciones de correo electrónico en Wikimedia Commons.
Lecturas relacionadas
6 articulos
Correo electrónicoCorreo electrónicoEl correo electrónico (abreviatura de correo electrónico ; también escrito e-mail ) es un método de transmisión y recepción de mensajes mediante di...Grupo de trabajo de ingeniería de InternetEl Grupo de Trabajo de Ingeniería de Internet ( IETF ) es una organización de normalización para Internet y es responsable de los estándares técnic...Solicitud de comentariosUna solicitud de comentarios ( RFC ) es una publicación de una serie de los principales organismos de desarrollo técnico y establecimiento de están...canalsurfing.netNombre de dominioUn ejemplo anotado de un nombre de dominio En Internet , un nombre de dominio es una cadena que identifica un ámbito de autonomía, autoridad o cont...Dirección IPDirección IPUna dirección de Protocolo de Internet ( dirección IP ) es una etiqueta numérica como 192.0.2.1 que se asigna a un dispositivo conectado a una red ...Nombre de dominio internacionalizadoNombre de dominio internacionalizadoUn nombre de dominio internacionalizado ( IDN ) es un nombre de dominio de Internet que contiene al menos una etiqueta que se muestra en aplicacion...