I tend to use something like this rule, too. Except that I don't like having an IP in the domain part (it's valid, but screams spam), and a FQDN instead of a (possibly local/internal) hostname. So /.+@.+\..+/ it is for me (plus checking it's not an IP). Unless of course the application interacts with intranet hostnames, but imho those should be avoided these days anyway.

Imho it's more important to allow a user to fix a mistake: "We sent you a confirmation e-mail to $email_address. Spotted a mistake? Click here to change your email address."

Are decimal & hexadecimal addresses accepted as email domains? e.g. root@2130706433 & root@0x7f000001

No. For IPv4 the dotted syntax must be used and for IPv6, the colon syntax preceded by the string “IPv6:”. In either case the whole thing must be enclosed in square brackets.

Technically, the address must also be surrounded by brackets.

Isn’t that what I said?

You’re right, you did. Sorry, I must have missed it.

Those would be interpreted as strings, not hex.

"Address literals" as domains are not something that will work widely; if my memory serves most MTAs don't have them enabled in their default configs.

i'm not sure there must be something before the "@".

I am certain. There must be something before the @.

The @ itself is optional (I believe the RFC disagrees, but on practice it is), but if it's there, there must be something after it too. So the only really required "field" is the one before the @.

ok, i admit the rfc may prescribes something like .+(@.+)?

i've just drawn the conclusion from that the local part is interpredet solely by the receiving party. that's why case-conversion should be avoided, since the receiving party may be case sensitive. so further thinking, local part can be empty perhaps, depending on the implementation.