1. 12

/.+@.+..+/i

I love it.

  1.  

  2. 7

    I have a .email domain for my email, and it is often rejected because of (I assume) hardcoded acceptable TLDs

    But why stop there, don’t use regex to validate form fields at all.

    I’ve lost count of how many times something like this has happened:

    Enter name exactly as it appears on passport

    Enters name

    Only use letters!

    Looks at code

    pattern="[a-zA-Z ]+"

    🤷‍♀️

    1. 4

      My personal favourite is credit card or phone number fields that require NO SPECIAL CHARACTERS. What? Why? They’re not in any way ambiguous. Up yours, web page!

    2. 6

      I used to think the best way was to check for anything, @, anything, ., anything and then I was informed it is possible to have an email address with no dot if the domain side is an ipv6 address…

      1. 2

        That sounds like it wouldn’t work with SPF or DKIM any way?

        1. 3

          Do SPF or DKIM matter in this context? The email receiver validates these things for the sender. You don’t need it if you only plan to receive emails, do you?

      2. 5

        I’m not a fan of /.+@.+\..+/i, because it assumes that the domain part has at least one dot, which may not be the case. Case in point: foo@localdomain, bar@[2001:DB8::1]. Both are valid, but the regex wouldn’t match either.

        Just send an email, and be done with it.

        1. 5

          FOSDEM 2018 had a fun talk about that. Horrifying what constitutes a valid email address.

          1. 3

            An oldie but a goodie, I actually think about this article and /@/ more regularly than one might think doing web development. I also have definitely taken the advice to heart.