But how can I be considered to be "asking for it" if I put a dot, hyphen or number in my email address, when millions of email addresses have them; the standard permits them; and many institutional policies create emails with them by default?
Which characters can I have in my email address, that won't cause you to tell me it's my own fault when they get rejected?
I agree that you have no way of knowing what all the code along the way does, but you can at least hope that it behaves in something resembling a standards-compliant fashion. Otherwise, what's the point of email addresses at all?
Hope is all you have, if email is the black box wilderness you describe. You rely on hope regardless of whether or not your email address contains "super-special characters".
My whole point is that there is a standard for an email address, outlined in a freely-available document. If an application claims to handle email, that claim implies conformance to that standard. Any deviation should be documented.
Your claim appears to be that there is some other definition of a "legit" email address, that you can absolutely 100% guarantee will be handled by absolutely every single email-handling application ever (without relying on hope).
Please answer these questions -
1) What, exactly, is the format of such a "legit" email address, according to your definition?
Your view of this whole subject seems to be completely upside down.
There's no such thing as a 100% guarantee when it comes to email (Interwebs 101) but it should be completely obvious to any sane person that you are getting much closer to those 100% if you don't use any "super-special characters" in your e-mail address as opposed to people "asking for it" by using an address like {^|~!}@gmail.com - which will obviously get you into some kind of trouble, sooner or later, whether it's Facebook's validation rejecting it or mail applications which can't handle it properly.
So of course, while there can't be 100%, from the perspective of an application that deals with e-mails, you'd want to get as close as possible. And like I said in an earlier comment, I wouldn't expect problems with characters such as - _ . but yeah, who knows?
And actually, there's no way anyone could ever have that obscure example address used above, as hey surprise, GMail won't allow you to register it (same for Hotmail). So, I am not sure what this means now:
GMail only allows alphanumeric characters and dots in mail addresses because...
a) ...their coders don't know the RFC and hardly anything about that whole e-mail thing in general, so they provided us with a heavily flawed product, according to your definition.
b) ...their coders have already been doing this whole development and e-mail thing for a week or two and it was obvious to them that "super-special characters" could lead (and have previously led) to trouble, so they're saving less 'techy' people from registering addresses that are basically "asking for it".
Ever since the first comment I left here, my whole point is that everyone who has built applications sending a lot of e-mails just knows that it's insane to assume that everybody else "does it right" and that combinations of special characters, escaping and UTF-8 often result in 'lots of fun'... not. That's far from being fully RFC-compliant but that's how it is, out there in the wild.
One last example: according to Wikipedia, Hotmail "refuses to send mail to any address containing any of the following standards-permissible characters: ! # $ % * / ? ^ ` { | } ~". (And being aware of this, you'd be "asking for it".)
1) Regarding the kinds of mailbox names an email provider will provide you with, it's up to the provider. My employer, for example, only lets us have firstname.surname, With the addition of a single digit in case more than one employee has that name. These limitations have nothing to do with standards compliance.
2) Gmail does allow you to send mail to non-legit, but standards-compliant addresses like {^|~!}@example.com, because they know that their own mailbox name rules don't extend to other providers.
Regarding your point b) evidently they're not smart enough to grasp that addresses with + in them only work on the theoretical internet, and not the real one.
Completely different to standards-compliance, yes. However it is exactly the same thing as GMail's alphanumeric only rule.
To reiterate - the mailbox names that a email provider will provide are subject to the naming conventions defined by that provider. Whether the convention is firstname.lastname; 5-7 characters only; alphabetic only; or 13375p34k transcriptions of characters from Lord of the Rings. None of that has anything to do with whether they are standards-compliant.
The test is whether they will send email to any RFC-compliant email address regardless of whether it conforms to their own mailbox naming convention. Gmail does.
Which characters can I have in my email address, that won't cause you to tell me it's my own fault when they get rejected?
I agree that you have no way of knowing what all the code along the way does, but you can at least hope that it behaves in something resembling a standards-compliant fashion. Otherwise, what's the point of email addresses at all?