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.