Czy dozwolone są dwa okresy w lokalnej części adresu e-mail?

Przekaźnik bramy e-mail innej firmy odmawia przetworzenia wiadomości na adres e-mail, na który wysyłamy. Adres jest w formacie imię .. nazwisko @ adresatomena.com (zwróć uwagę na dwie kropki). Czy jest to dozwolone przez wytyczne RFC?

RFC 2822 wydaje się sprzeciwiać temu w sekcji 3.4.1:

Lokalnie interpretowany ciąg jest ciągiem cytowanym lub kropkowym. Jeśli ciąg może być reprezentowany jako atom-kropka (to znaczy nie zawiera żadnych znaków innych niż znaki atext lub „.” Otoczone znakami atext), wówczas NALEŻY użyć postaci kropki-atomu, a forma łańcucha cytowanego NIE POWINNA być użytym. Komentarze i składane białe znaki NIE powinny być używane wokół „@” w specyfikacji addr.

Ponadto w tej samej sekcji znajduje się odniesienie do tego:

addr-spec = domena „@” części lokalnej

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

Interpretuję to w ten sposób, że część lokalna może mieć treść oddzieloną kropkami, ale nie może być dwóch kolejnych kropek i nie może zaczynać się ani kończyć kropką. To powiedziawszy, nie znam składni atomu kropkowego, więc może się tutaj mylę.

Czy ktoś może potwierdzić i wyjaśnić?

Tak, masz rację. Cytowana sekcja mówi, że musi to być ciąg cytowany LUB atom kropkowy. Ponieważ wyraźnie nie jest cytowanym ciągiem (brak załączania "wyjaśnia to) , musi to być kropka-atom ...

To prowadzi nas do definicji atomu kropkowego:

Spójrz na to, z wyjątkiem RFC 5322 (3.2.3 - strona 13) (RFC 2822 zawiera podobną sekcję) wskazówka jest 1*w dot-atom-text = 1*atext *("." 1*atext). Oznacza to, że atom kropkowy składa się z ciągów jednego lub więcej znaków „atext” oddzielonych kropkami. Ciąg 0 znaków tekstowych nie ma znaczenia, więc nie możesz mieć dwóch kolejnych kropek (oddzielonych 0 znakami) ani kropki wiodącej lub końcowej.

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

Twoja interpretacja jest poprawna. Część lokalna może zawierać grupy atekstów oddzielone kropkami, ale wiele kolejnych okresów jest niedozwolonych.

Zgodnie z sekcją 3.4.1 RFC 5322, którą zacytowałeś w swoim pytaniu, atom kropki „ nie zawiera żadnych znaków innych niż znaki atext lub„. ”Otoczony znakami atext ”. Dlatego z definicji atom kropki nie może zawierać dwóch lub więcej kolejnych okresów.

Dla odniesienia, oto definicja atext, zaczerpnięta z Sekcji 3.2.3 RFC 5322 :

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

Oczywiście, żadne dwa MTA nie egzekwują RFC w ten sam sposób, więc niektóre MTA zaakceptują podwójne okresy, a inne nie. Na przykład Exchange odmówi dostarczenia adresów zawierających podwójne kropki, ale szybki test losowego wyboru 3 serwerów pocztowych, których używam, wszystkie obsługują podwójne kropki.

Więc ściśle według RFC 5322, organizacja hostująca przekaźnik, z którym masz problemy, ma prawo odmówić adresu zawierającego podwójne kropki.