Or it could open you up to other attacks when the service coalesces all those emails to one canonical example (to uniquely identify you or whatever -- note that almost no online service recognizes the importance of caps in the email address you use as a username for example, where the underlying email provider sometimes does) but does so differently than the actual email service, allowing anyone and their dog to create an email which will collide with yours.
Allowing anything else that a-z 0-9 and some characters like - _ . as the name part of an email address is pure madness. If the mail provider treats User@domain as a different address than user@domain, and delivers them to different customers this is simply asking for trouble. Even if it's standard compliant behavior.
As a less contrived example then, consider "andix.hacker@foo.com" vs "andix..hacker@foo.com". Some email service providers canonicalize those to the same thing, and some don't.
Your service using emails for logins or adspam or whatever now faces a choice. You probably have to accept periods, and you probably don't want to try to hard-code all the different ways a period might be used legitimately as opposed to a typo, so you have to deal with that problem somehow. You can canonicalize (opening yourself up to hijacks, some unintentional as legitimate users just have emails that clash in your system), or not (potentially locking out some users).
