Yup. Even spaces are allowed if you put double quotes around the local part: “Kevin Spacey”@example.com. It’s really surprising, there’s very little that can be verified if you strictly follow the RFC.

And comments:

    Muhammad.(I am  the greatest) Ali @(the)Vegas.WBA

(an example lifted directly from RFC-822, apparently written by a madman in love with 70s parser theory).

> there’s very little that can be verified if you strictly follow the RFC.

That's not correct. You can reliably, completely validate all email addresses . . . by sending an email to them containing information that can be used to confirm the owner's identity. All together now: the MTA is the only source of "is it valid or not" for email addresses.

This is a common issue with text based formats and ietf/RFCs. HTTP allows comments in some headers. And allows line breaks:

  H: hi
    Mom

Is the same as

  H: hi Mom

Bets on how many http clients and servers get this right? Without losing speed?

My guess is when you're not responsible for ensuring compatibility or having to deal with writing robust, fast, code, the temptation to be cute with your format overtakes things.

I expect all commonly used HTTP clients (Chrome, Firefox, IE, even libcurl) and servers (Apache, Nginx, does IIS still exist?) get this right.

I, too, would expect that the most common pieces of software with massive amounts of engineering time invested get it right (but almost certainly with a performance hit). But I'd be unsurprised to find that one doesn't handle the http parsing spec correctly somewhere.

The issue is that such a spec is entirely unneeded and overly complicated. No benefit, only downsides. And for something as simple as basic parsing rules! Not even getting into anything that should be difficult.