23

A third-party email gateway relay is refusing to process a message for an email address we're sending to. The address is in the format of [email protected] (note the two periods). Is this allowed by RFC guidelines?

RFC 2822 seems to object to this in section 3.4.1:

The locally interpreted string is either a quoted-string or a dot-atom. If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters), then the dot-atom form SHOULD be used and the quoted-string form SHOULD NOT be used. Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec.

Furthermore, in that same section, it references this:

addr-spec = local-part "@" domain

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

I interpret this to mean that the localpart can have content separated by dots but there cannot be two successive dots, and it cannot start or end with a dot. That being said, I'm not familiar with dot-atom syntax so maybe I'm mistaken here.

Can someone please confirm and explain?

2 Answers 2

18

Yes you are correct. The section you quoted says that it must be a quoted string OR a dot atom. Since its clearly not a quoted string (the lack of enclosing " makes that clear) it must be a dot-atom...

That leads us to the definition of dot-atom:

Look at this except from RFC 5322 (3.2.3 - page 13) (RFC 2822 contains a similar section) the hint is the 1* in dot-atom-text = 1*atext *("." 1*atext). This effectively means that a dot-atom is made up of strings of one or more "atext" characters separated by dots. A string of 0 atext characters does not count and so you can not have two successive dots (seperated by 0 characters) or a leading or trailing dot.

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
1
5

Your interpretation is correct. The local part may contain groups of atext separated by periods, but multiple consecutive periods are not allowed.

As per section 3.4.1 of RFC 5322 which you quoted in your question, a dot atom "contains no characters other than atext characters or "." surrounded by atext characters". Hence, by definition, a dot atom may not contain two or more consecutive periods.

For reference, here's the atext definition, taken from Section 3.2.3 of RFC 5322:

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

Of course, no two MTAs enforce RFCs in the same way, so you'll find some MTAs will accept double periods where others won't. For example, Exchange will refuse to deliver for addresses containing double periods, but a quick test of a random selection of 3 mail servers that I use all support double periods.

So strictly according to RFC 5322, the organisation hosting the relay you're having problems with is well within their rights to refuse addresses containing double periods.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .