trailing dot in local part of email

Question

In our online shop, we ran into a problem wherein a certain user can't purchase because of an "invalid email address". It looks like this:

her.email.address.@docomo.ne.jp

I think what's setting off the invalid email error is the trailing dot in the local part of the email. In the code, I commented out the second condition:

if (isc_substr($local, 0, 1) == '.' || isc_substr($local, -1, 1) == '.')

to make it work. Is this safe? Or should we advise the customer to change her email address?

Answer 1

EDIT: My old answer was wrong.

I see absolutely no safety implications in this rule, but RfC 5322 explicitly only allows dots inside the local part of the mail address, not at the beginning and end. That being said, I would not be surprised if in practice, it would still just work with a lot of mail servers. So, while .@example.com is not a valid address according to RfC 5322, for practical purposes, it could be a working address, only the mail server for example.com can know.

As I said, the relevant spec is RfC 5322, taking into account that RfC 5321 adds the restriction that the local part not have more than 64 characters. And, yes, the standard allows for a lot of addresses that will simply not work for very many web sites or mail programs, such as "this is v@lid!"@example.com. It is unwise to use this kind of addresses, but that is because of software bugs that lead to them not being accepted.

Answer 2

That email address is indeed violating the standard (RFC 5322), and I would advice the user to change her address. However, there should not be any security implications when you allow your local parts to end in dots.

The standard also doesn't allow two or more consecutive dots, and this restriction can be a bit more security relevant: Think of something like ../../. Yes, slashes are allowed in email addresses, and code that isn't prepared for that might do something nasty with the local part. Chances are low, but, you know, I've seen things… ;)

Since the standard is a bit hard to read, here's what it says:

RFC 5322 allows having dots in the local part, however, there are two important limitations: It does not allow two or more consecutive dots, and it also does not allow the local part to start or end with a dot.

Section 3.4.1 describes the local-part, and the three syntaxes it may have. The "usual" one is the dot-atom syntax, and that is essentially defined in section 3.2.3 as

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

where atext are printable US-ASCII characters with some exceptions:

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

So dot-atom-text is basically defined as "at least one atext character, followed by zero or more occurences of [a dot followed by one or more atext characters]". That means abc is okay and a.bc.d as well, but .abc is not (because it doesn't start with atext), and neither are a..b (because there's no atext following the first dot) or abc. (again because there's no atext following).

As I said above, you can choose to ignore those restrictions (although I would advise against allowing consecutive dots), but essentially your shopping cart software is perfectly right to disallow that email address.