¿Se permiten dos períodos en la parte local de una dirección de correo electrónico?

Una retransmisión de puerta de enlace de correo electrónico de terceros se niega a procesar un mensaje para una dirección de correo electrónico a la que estamos enviando. La dirección está en el formato de nombre .. apellido @nombrededominio.com (tenga en cuenta los dos puntos). ¿Está permitido por las pautas de RFC?

RFC 2822 parece objetar esto en la sección 3.4.1:

La cadena interpretada localmente es una cadena entre comillas o un átomo de puntos. Si la cadena se puede representar como un átomo de punto (es decir, no contiene más caracteres que atext o "." Rodeado de caracteres de atext), entonces la forma de átomo de punto DEBE usarse y la forma de cadena entre comillas NO DEBE ser usado. Los comentarios y el espacio en blanco plegable NO DEBEN usarse alrededor de la "@" en la especificación de dirección.

Además, en esa misma sección, hace referencia a esto:

addr-spec = dominio "@" de parte local

local-part = dot-atom / quoted-string / obs-local-part

Interpreto que esto significa que la parte local puede tener contenido separado por puntos, pero no puede haber dos puntos sucesivos , y no puede comenzar o terminar con un punto. Dicho esto, no estoy familiarizado con la sintaxis punto-átomo, así que tal vez me equivoque aquí.

¿Alguien puede confirmar y explicar?

Sí, estás en lo correcto. La sección que citó dice que debe ser una cadena entre comillas O un átomo de puntos. Como claramente no es una cadena citada (la falta de encerramiento lo "deja claro) debe ser un átomo de puntos ...

Eso nos lleva a la definición de punto-átomo:

Mire esto, excepto en RFC 5322 (3.2.3 - página 13) (RFC 2822 contiene una sección similar) la sugerencia es 1*in dot-atom-text = 1*atext *("." 1*atext). Esto significa efectivamente que un átomo de puntos está formado por cadenas de uno o más caracteres "atext" separados por puntos. Una cadena de 0 caracteres de texto no cuenta y, por lo tanto, no puede tener dos puntos sucesivos (separados por 0 caracteres) o un punto inicial o final.

RFC 5322                Internet Message Format             October 2008


   atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"

   atom            =   [CFWS] 1*atext [CFWS]

   dot-atom-text   =   1*atext *("." 1*atext)

   dot-atom        =   [CFWS] dot-atom-text [CFWS]

   specials        =   "(" / ")" /        ; Special characters that do
                       "<" / ">" /        ;  not appear in atext
                       "[" / "]" /
                       ":" / ";" /
                       "@" / "\" /
                       "," / "." /
                       DQUOTE

Tu interpretación es correcta. La parte local puede contener grupos de texto separados por puntos, pero no se permiten varios períodos consecutivos.

Según la sección 3.4.1 de RFC 5322 que citó en su pregunta, un átomo de punto " no contiene más caracteres que atext o". "Rodeado de caracteres atext ". Por lo tanto, por definición, un átomo de puntos no puede contener dos o más períodos consecutivos.

Como referencia, aquí está la definición atext, tomada de la Sección 3.2.3 de RFC 5322 :

atext           =       ALPHA / DIGIT / ; Any character except controls,
                        "!" / "#" /     ;  SP, and specials.
                        "$" / "%" /     ;  Used for atoms
                        "&" / "'" /
                        "*" / "+" /
                        "-" / "/" /
                        "=" / "?" /
                        "^" / "_" /
                        "`" / "{" /
                        "|" / "}" /
                        "~"

Por supuesto, no hay dos MTA que apliquen RFC de la misma manera, por lo que encontrará que algunos MTA aceptarán períodos dobles donde otros no lo harán. Por ejemplo, Exchange se negará a entregar direcciones que contengan períodos dobles, pero una prueba rápida de una selección aleatoria de 3 servidores de correo que utilizo todos los períodos dobles de soporte.

Por lo tanto, estrictamente de acuerdo con RFC 5322, la organización que aloja el retransmisor con el que tiene problemas está dentro de sus derechos para rechazar direcciones que contengan períodos dobles.