How many of you would have an outright revolt on your hands from your QA/QE folks if you banned mailinator? I think everyplace I worked would experience this same issue if we did this.
I used to have a first.m.last@university.edu address and that one was touch-and-go as well due to the fact that the mailbox had two .'s in it. I actually had to file a support request to get Amazon Student to accept it, even. Nobody from a university with that scheme ever registered before?
For the record, the gold standard for email validation is "send a confirmation link and see if they click it". Don't try and get fancy.
One other trick is that Gmail ignores .'s in addresses entirely. first.last@gmail.com is the same as firstlast or f.irstlast.
That means validation was working correctly. The email addresses are invalid even if the server will accept email for them.
Yeah, I'm with the other guy, regardless of whether or not it's a good idea to do validation (it's not), that's not an address that should pass validation because it's not a valid domain or hostname.
I could see it being less of a big deal in the mailbox portion given that it's now kinda kosher to ignore dots there.
[1] docomo customer with two dots in email
Ask me how I know this.
But make sure you have some sort of rate limiting set up, so malicious users can't take advantage to spam someone's mailbox (and get your server blacklisted).
I'm not aware of any RFC that says that mail sent to a+foo@example.com should go to the same mailbox as mail sent to a+bar@example.com (nor am I aware of any RFC that forbids this). I thought that GMail made up that feature and other vendors followed suit since users find it handy.
> Subaddressing is the practice of augmenting the local-part of an
> [RFC2822] address with some 'detail' information in order to give
> some extra meaning to that address. One common way of encoding
> 'detail' information into the local-part is to add a 'separator
> character sequence', such as "+", to form a boundary between the
^^^^^^^^^^^
> 'user' (original local-part) and 'detail' sub-parts of the address,
> much like the "@" character forms the boundary between the local-part
> and domain.
The RFC even gives an example using the hash:
> o A message addressed to "5551212#123@example.com" is delivered to
the voice mailbox number "123" at phone number "5551212".There is no RFC that requires this behavior. Subaddressing within the local part is recognized as a common practice (e.g., in RFC 5233), but nothing requires a system to support subaddressing, or requires a system that does to support a particular separator character or character sequence (e.g., "+") for subaddressing. Email systems are free to implement or not implement subaddressing, and to use any character sequence they want as the separator.