I think Jacob sort of touches on this in his post but too often it's not explicit what people are looking for under the vague and broad umbrella of "e-mail validation".
If it's "Did the AOL user signing up for my site forget the '.com' part at the end of the address?" then some pretty simplistic text-based matching will do.
If it's "Is the address supplied a valid mailbox that is controlled by the person who is supplying it to me?" then all the string parsing in the world isn't going to save you. You'll need to roundtrip something out to the mailbox with confirmation instructions. And even then you're not out of the woods -- maybe the user's mailbox is full, or a transient DNS error is causing a problem.
I think e-mail address validation tends to be a bit of a tarpit for nerds (myself included) because the delicious complexity of RFCs 822 and 2822 makes writing code to handle the grammars they describe a fun challenge. That makes it easy to forget what the point of the address validation in the real world actually is: handholding well-meaning users that may have made a careless mistake, or robust protection against malicious users, or bot protection (in which case you probably want to ban RFC-valid addresses that have known-suspicious domain names or components), etc.