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.

  • jwt@programming.devEnglish
    671·
    11 months ago

    Probably, from what I can see the address in question isn’t really that exotic. but an email regex that validates 100% correctly is near impossible. And then you still don’t know if the email address actually exists.

    I’d just take the user at their word and send an email with an activation link to the address that was supplied. If the address is invalid, the mail won’t get delivered. No harm done.

    • Alexstarfire@lemmy.worldEnglish
      241·
      11 months ago

      Actually, one of our customers found out the hard way that there is harm in sending emails to invalid addresses. Too many kickbacks and cloud services think you’re a bot. Prevented the customer from being able to send emails for 24 hours.

      This is the result of them “requiring” an email for customers but entering a fake one if they didn’t want to provide their email, and then trying to send out an email to everyone.

      Our software has an option to disable that requirement but they didn’t want to use it because they wanted their staff to remember to ask for an email address. It was not a great setup but they only had themselves to blame.

      • jwt@programming.devEnglish
        17·
        11 months ago

        My guess is that would also occur with valid but non-existing e-mail addresses no? The regex would not be a remedy there anyway.

        Of course you should only use the supplied e-mail address for things like mass mailings once it has been verified (i.e. the activation link from within the mail was clicked)

        • Alexstarfire@lemmy.worldEnglish
          31·
          11 months ago

          That’s exactly what they did. They used something like noaddress@ourbusniess.com to get around the checks we had in place. I’ve intentionally been vague but most people will give their email address to our customers and won’t give a fake one. So under normal situations the amount of bounce backs would be minimal: fat fingering, hearing them incorrectly, or people misremembering their email. Not enough to worry about. Never thought we’d come across a customer intentionally putting in bad email addresses for documentation purposes. They could have just asked us to make the functionality they wanted.

    • Echo Dot@feddit.ukEnglish
      201·
      11 months ago

      The best of validation is just to confirm that the email contains a @ and a . and if it does send it an email with a confirmation link.

      • __dev@lemmy.worldEnglish
        32·
        11 months ago

        TLDs are valid in emails, as are IP V6 addresses, so checking for a . is technically not correct. For example a@b and a@[IPv6:2001:db8::1] are both valid email addresses.

        • HotChickenFeet@sopuli.xyzEnglish
          261·
          11 months ago

          I feel like using a@[IPv6:2001:db8::1] is asking for trouble everywhere online.

          But its tempting to try out, not many people would expect this.

          • Crass Spektakel@lemmy.worldEnglish
            21·
            11 months ago

            try user@123.45.67.89.in-addr.arpa or user@d.e.a.d.b.e.e.f.0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.0.0.0.1.2.3.4.ip6.arpa just for the giggles. Mix it with BANG-Adressing:

            123.45.67.89.in-addr.arpa!d.e.a.d.b.e.e.f.0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.0.0.0.1.2.3.4.ip6.arpa!user

      • rottingleaf@lemmy.zipEnglish
        301·
        11 months ago

        Personally I don’t think that sucks or is even wrong. Case-independent text processing is more cumbersome. ‘U’ and ‘u’ are two different symbols. And you have to make such rules for every language a part of your processing logic.

        If people can take case-dependence for passwords (or official letters and their school papers), then it’s also fine for email addresses.

        The actual problem is cultural, coming from DOS and Windows where many things are case-independent. It’s an acquired taste.

        • dan@upvote.auEnglish
          12·
          11 months ago

          ‘U’ and ‘u’ are two different symbols. And you have to make such rules for every language a part of your processing logic.

          Unicode has standard rules for case folding, which includes the rules for all languages supported by Unicode. Case-insensitive comparisons in all good programming languages uses this data.

          Note that you can’t simply convert both strings to uppercase or lowercase to compare them, as then you’ll run into the Turkish i problem: https://haacked.com/archive/2012/07/05/turkish-i-problem-and-why-you-should-care.aspx/

          • rottingleaf@lemmy.zipEnglish
            5·
            11 months ago

            So good that we all use Unicode now. No CP1251, no ISO single-byte encodings, no Japanese encoding hell.

          • labsin@sh.itjust.worksEnglish
            41·
            11 months ago

            It’s that capitalization is language dependent, which email addresses shouldn’t be as I hope the rules for France shouldn’t be different than for Dutch. For instance é in Dutch is capitalized as E, but in French it is É. The eszett didn’t even have an official capital before 2017

            In most programming languages, case-insensitive string compare without specifying the culture became deprecated. It should imo only be used for fuzzy searching doubles, which you probably will do with ToUpper on all four performance reasons, or maybe some UI validation.

            • dan@upvote.auEnglish
              4·
              11 months ago

              For instance é in Dutch is capitalized as E, but in French it is É

              Sure, but we’re just talking about string comparison rules, and Unicode sees all three of those as being equal. For example, a search engine that uses proper case folding rules in its indexer should return results for “entrée” if you search for “entree”, “Čech” if you search for “cech”, etc.

              It should imo only be used for fuzzy searching doubles, which you probably will do with ToUpper

              You can’t just use ToUpper for comparisons due to issues like you mentioned, and the Turkish i problem. You need to do proper case-insensitive comparisons, which is where the Unicode case folding rules are used.

            • rottingleaf@lemmy.zipEnglish
              1·
              11 months ago

              offtopic: The eszett strictly speaking was a ligature for ‘sz’, which Hungarian orthography kinda preserved while for German the separated version is ‘ss’, and there’s plenty of such stuff in nature.

              In most programming languages, case-insensitive string compare without specifying the culture became deprecated. It should imo only be used for fuzzy searching doubles, which you probably will do with ToUpper on all four performance reasons, or maybe some UI validation.

              Thank you for saying that more clearly.

        • Natanael@slrpnk.netEnglish
          4·
          11 months ago

          But then you run into the issue of incredibly trivial impersonation on any email service which doesn’t reserve all variants of registered names

          • rottingleaf@lemmy.zipEnglish
            1·
            11 months ago

            Yes, email as it really exists kinda sucks, but the idea was nice. When it ran over UUCP, LOL.