I also reached out to them on Twitter but they directed me to this form. I followed up with them on Twitter with what happened in this screenshot but they are now ignoring me.

  • aard@kyu.deEnglish
    22·
    11 months ago

    I’m not aware of any correct email validations. I’m still looking for something accepting a space in the localpart.

    Also a surprising number of sites mess with the casing of the localpart. Don’t do that - many mailservers do accept arbitrary case, but not all. MyName@example.com and myname@example.com are two different mail addresses, which may point to the same mailbox if you are lucky.

    • CosmicTurtle@lemmy.worldEnglish
      263·
      11 months ago

      The only correct regex for email is: .+@.+

      So long as the address has a local part, the at sign, and a hostname, it’s a valid email address.

      Whether it goes somewhere is the tricky part.

      • xantoxis@lemmy.worldEnglish
        262·
        11 months ago

        Sorry, this is not a correct regex for an email address.

        Sending using mail on a local unix system? You only need the local part.

        STOP VALIDATING NAMES AND EMAIL ADDRESSES. Send a verification email. Full stop. Don’t do anything else. You really want to do this anyway, because it’s a defense against bots.

        • Turun@feddit.deEnglish
          61·
          11 months ago

          I think it’s fair to prevent users from causing mail sent to your internal systems. It probably won’t cause any issues getting mail to the machine inbox for (no domain name), but it reasonably makes security uneasy.

          • xantoxis@lemmy.worldEnglish
            7·
            11 months ago

            The statement I was responding to was “This is the correct email regex”. There is no correct email regex. Don’t parse emails with a regex. You probably don’t need to parse emails at all.

        • elrik@lemmy.worldEnglish
          51·
          11 months ago

          Yes, but no. Pretty much every application that accepts an email address on a form is going to turn around and make an API call to send that email. Guess what that API is going to do when you send it a string for a recipient address without an @ sign? It’s going to refuse it with an error.

          Therefore the correct amount of validation is that which satisfies whatever format the underlying API requires.

          For example, AWS SES requires addresses in the form UserName@[SubDomain.]Domain.TopLevelDomain along with other caveats. If the application is using SES to send emails, I’m not going to allow an input that doesn’t meet those requirements.

          • xantoxis@lemmy.worldEnglish
            71·
            11 months ago

            Therefore the correct amount of validation is that which satisfies whatever format the underlying API requires.

            You mean the validation which the underlying API will perform on its own? You don’t need to do it.

            • elrik@lemmy.worldEnglish
              41·
              11 months ago

              I disagree. You should have validation at each layer, as it’s easier to handle bad inputs and errors the earlier they are caught.

              It’s especially important in this case with email because often one or more of the following comes into play when you’re dealing with an email input:

              • You’re doing more than sending an email (for ex, creating a record for a new user).
              • The UI isn’t waiting for you to send that email (for ex, it’s handled through a queue or some other background process).
              • The API call to send an email has a cost (both time and money).
              • You have multiple email recipients (better hope that external API error tells you which one failed).

              I’m not suggesting that validation of an email should attempt to be exhaustive, but a well thought-out implementation validates all user inputs. Even the underlying API in this example is validating the email you give it before trying to send an email through its own underlying API.

              Passing obvious garbage inputs down is just bad practice.