Dois períodos são permitidos na parte local de um endereço de email?

Uma retransmissão de gateway de email de terceiros se recusa a processar uma mensagem para um endereço de email para o qual estamos enviando. O endereço está no formato de primeiro nome .. último nome @ destinatáriodomínio.com (observe os dois períodos). Isso é permitido pelas diretrizes da RFC?

A RFC 2822 parece se opor a isso na seção 3.4.1:

A sequência interpretada localmente é uma sequência de aspas ou um átomo de ponto. Se a string pode ser representada como um átomo de ponto (ou seja, não contém caracteres que não sejam caracteres de texto ou "." Cercados por caracteres de texto), então a forma de átomo de ponto DEVE ser usada e a forma de string entre aspas NÃO DEVE ser usado. Comentários e espaço em branco dobrável NÃO DEVEM ser usados ​​em torno do "@" na especificação de endereço.

Além disso, nessa mesma seção, ele faz referência a isso:

addr-spec = domínio "@" da parte local

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

Interpreto que isso signifique que a parte local pode ter conteúdo separado por pontos, mas não pode haver dois pontos sucessivos e não pode começar ou terminar com um ponto. Dito isto, eu não estou familiarizado com a sintaxe de átomo de ponto, então talvez eu esteja enganado aqui.

Alguém pode confirmar e explicar?

Sim você está correto. A seção que você citou diz que deve ser uma string citada OU um átomo de ponto. Como não é claramente uma string citada (a falta de inclusão "deixa isso claro) , deve ser um átomo de ponto ...

Isso nos leva à definição de átomo de ponto:

Olhe para isso, exceto a partir de RFC 5322 (3.2.3 - página 13) (RFC 2822 contém uma seção similar) a dica é o 1*no dot-atom-text = 1*atext *("." 1*atext). Isso significa efetivamente que um átomo de ponto é composto de cadeias de caracteres de um ou mais caracteres de "texto" separados por pontos. Uma sequência de 0 caracteres de texto não conta e, portanto, você não pode ter dois pontos sucessivos (separados por 0 caracteres) ou um ponto inicial ou 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

Sua interpretação está correta. A parte local pode conter grupos de texto separados por pontos, mas vários períodos consecutivos não são permitidos.

Conforme a seção 3.4.1 da RFC 5322, citada em sua pergunta, um átomo de ponto " não contém caracteres além de caracteres de texto ou". "Cercado por caracteres de texto ". Portanto, por definição, um átomo de ponto pode não conter dois ou mais períodos consecutivos.

Para referência, aqui está a definição de texto, retirada da Seção 3.2.3 da RFC 5322 :

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

Obviamente, não há dois MTAs que aplicam RFCs da mesma maneira; portanto, alguns MTAs aceitarão períodos duplos, enquanto outros não. Por exemplo, o Exchange se recusará a entregar endereços contendo períodos duplos, mas um teste rápido de uma seleção aleatória de três servidores de correio que eu uso todos dá suporte a períodos duplos.

Portanto, estritamente de acordo com a RFC 5322, a organização que hospeda a retransmissão com a qual você está tendo problemas está bem dentro do direito de recusar endereços contendo períodos duplos.