NYCPHP Meetup

[James B. Wetterau Jr.]

Daniel Convissor says:
...
 > Back when I did a study of RFC 822, those were the characters that the
 > RFC said were valid.  Perhaps I made a mistake.  But I haven't heard
 > of any problems with my expression.

I think the characters you had were the ones permitted by the RFC
*that are commonly considered supported*.  To give an obvious example:
if an email address has a / in it, and an address maps directly to a
Unix file or directory, it cannot be written on the system without
translation.

That said, it's still an RFC valid address -- it would just have to be
aliased to something else locally on the Unix system.

In practice you are probably right that almost no one uses such a
weird address.  I vaguely recall one person using an address with a %
to prove a point on one mailing list I was on.

...
 > The one flaw with that is it allows the local part to be just a
 > period: . at foo.com.

Or is it a feature?

 > I've needed to do this for a while.  Thanks for the excuse.

I sincerely appreciate your effort to do the right thing.  Good going!
Seriously, software would be better if more people tried to promptly
fix stuff like this.

While we're at it though, I should mention one other thing:

 From what I can tell, though RFC822 seems to discourage it, it
supports for backward compatibility addresses of this form:

address.example at tld

... evidently because some TLD's used to do addressing like that.

I also can't quite tell from the RFC whether it would be valid for a
TLD to grant its own email addresses, but those would also look like
that.

So you can have a valid email address that has only a TLD to the right
of the "@" with no "." in there.