• Not a newt@piefed.ca
      link
      fedilink
      English
      arrow-up
      17
      ·
      2 months ago

      13/21 here. Mostly got hung up on several “this was valid in earlier RFC, and later removed” kind of situations. There are several where I picked the correct answer, but where I know many websites that won’t accept it as valid, and that’s not even the more esoteric ones.

      • NaibofTabr@infosec.pub
        link
        fedilink
        English
        arrow-up
        10
        ·
        2 months ago

        Yeah I feel like the correct answer for anything obsoleted by a more recent RFC should be “Invalid”.

        • JohnEdwa@sopuli.xyz
          link
          fedilink
          arrow-up
          5
          ·
          edit-2
          2 months ago

          But they will work, and according to the spec, you have to build your system so that it can handle those cases. Obsolete doesn’t mean incorrect or invalid, just a “you shouldn’t do this any more”.

          Obsolete Syntax
          Earlier versions of this standard allowed for different (usually more liberal) syntax than is allowed in this version. Also, there have been syntactic elements used in messages on the Internet whose interpretation have never been documented. Though some of these syntactic forms MUST NOT be generated according to the grammar in section 3, they MUST be accepted and parsed by a conformant receiver.

          https://datatracker.ietf.org/doc/html/rfc2822#section-4

          • Frezik@lemmy.blahaj.zone
            link
            fedilink
            English
            arrow-up
            2
            ·
            2 months ago

            Some of those “obsolete” things are outright blocked for specific reasons. For example, routing addresses through multiple servers. It was abused by spammers, so it’s almost always denied these days.

            Looks like this:

            <@foo.example.com@bar.example.com:123@example.com>
            
  • CommanderCloon@lemmy.ml
    link
    fedilink
    arrow-up
    19
    ·
    edit-2
    2 months ago

    Question 5 is incorrect, name@example is a fully valid email address, even after RFC 2822

    The spec of RFC 2822 defines an address (3.4.1) as:

    local- part "@" domain
    

    domain is defined (3.4.1) as:

    domain = dot-atom / domain-literal / obs-domain
    

    dot-atom is defined (3.2.4) as:

    dot-atom = [CFWS] dot-atom-text [CFWS]
    dot-atom-text = 1*atext *("." 1*atext)
    

    1*atext meaning at least 1 alphanumeric character, followed by *("." 1*atext) meaning at least 0 "." 1*atext


    If tomorrow, google decided to use its google top-level domain as an email domain, it would be perfectly valid, as could any other company owning top-level domains

    Google even owns a gmail TLD so I wouldn’t even be surprised if they decided to use it

    • HereIAm@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      2 months ago

      I don’t know if they changes the answer to the question, but it now says name@example is valid.

      • CommanderCloon@lemmy.ml
        link
        fedilink
        arrow-up
        7
        ·
        2 months ago

        It does say it’s valid, but also that it’s obsolete, and while the RFC does define valid but obsolete specs, there is nothing defining domains without a dot as obsolete, and it is in fact defined in the regular spec, not the obsolete section

  • irish_link@lemmy.world
    link
    fedilink
    arrow-up
    15
    ·
    2 months ago

    THIS THING IS STUPID!!!

    Or it’s just me that is the fool. Thanks for sharing. I just learned about 9 new things.

    • rtxn@lemmy.world
      link
      fedilink
      arrow-up
      11
      ·
      edit-2
      2 months ago

      All of the modern internet is built on the decaying carcasses of temporary solutions and things that seemed like a good idea at the moment but are now too widely used to change.

  • Blackmist@feddit.uk
    link
    fedilink
    English
    arrow-up
    15
    ·
    2 months ago

    I don’t think it really matters what the standard is, because you’ll be completely limited by some 25 year old bit of Regex from Stack Overflow that every web developer ever has implemented into their form sanity checks.

    • Frezik@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      5
      ·
      2 months ago

      The main one that gets passed around will match the weirdness fine. In fact, it probably matches things you don’t want, anyway.

      A signin/registration form really only needs to do sanity checks to get rid of obviously bad addresses. You’ll have to send a round-trip email confirmation message to make sure the email is real, anyway, so why bother going into great detail? Just check that there’s an ‘@’ symbol and a dot in the domain. Most of the rest is wanking off.

      • Dremor@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        A domaine without tld (me@home) is a valide address. I saw an email server being used as a mqtt-like server this way (it is very old and predate those software).

        • Frezik@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 months ago

          An address without a domain is irrelevant for a signin/registration form. Which is like 90% of the code being written in the wild to validate addresses.

          If you’re writing an email server, then you need to care about all these details. Most of us never will.

  • Frezik@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    10
    ·
    edit-2
    2 months ago

    Two of my “favorite” features it didn’t even touch on. You can have nested comments:

    foo(one(two(three(four(five(six(seven)))))))@example.com
    

    This will actually fail on that big email regex that gets copied around (originally from Mastering Regular Expressions in 1997), because it can only handle comment nesting to a depth of six. It is actually possible to do indefinite nesting now with recursive regex, but it was developed before that feature existed.

    RFC822 also allows routing addresses through multiple servers:

    <@foo.example.com@bar.example.com:123@example.com>
    

    But this is almost always denied on modern email servers because it was abused by spammers.

  • MonkderVierte@lemmy.zip
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    2 months ago

    My top five from this (all valid):

    • ":()␣::&␣;:"@example.com # fork bomb
    • 👉@👈 and poop@[💩]
    • “@”@[@]
    • c̷̨̈́i̵̮̅l̶̠̐͊͝ȁ̷̠̗̆̍̍n̷͖̘̯̍̈͒̅t̶͍͂͋ř̵̞͈̓ȯ̷̯̠-̸͚̖̟͋s̴͉̦̭̔̆̃͒û̵̥̪͆̒̕c̸̨̨̧̺̎k̵̼͗̀s̸̖̜͍̲̈́͋̂͠@example.com
    • fed-up-yet@␣example.com␣ # ␣ = whitespace
  • Speiser0@feddit.org
    link
    fedilink
    arrow-up
    7
    ·
    2 months ago

    Pretty much everything I’ve seen in e-mail is needlessly complicated and weird. So of course addresses are as well.

  • pyre@lemmy.world
    link
    fedilink
    arrow-up
    7
    ·
    2 months ago

    nice. though valid but obsolete is not a thing… if it’s obsolete it’s invalid.

  • dumnezero@piefed.social
    link
    fedilink
    English
    arrow-up
    6
    ·
    2 months ago

    Thanks to RFC 6532, Zalgo text is a-okay.

    hmmm…

    Yay! You’re average! Time to start making plans for what you’ll do when an LLM takes your job.

    I already have plans.

  • NessD@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    2 months ago

    14 / 21

    This is the score you get when you answer “valid” for every question. Good job.

  • Björn@swg-empire.de
    link
    fedilink
    arrow-up
    5
    ·
    2 months ago

    I had to make an email address just for paypal because those idiots don’t accept subdomains in email addresses.

    • Frezik@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      4
      ·
      2 months ago

      Pizza Hut doesn’t allow dashes in the domain. This prevents me from ordering Pizza Hut with the email under my personal domain. This can be considered a feature.

    • tyler@programming.dev
      link
      fedilink
      arrow-up
      4
      ·
      2 months ago

      You shouldn’t be validating emails yourself anyway. Use a library or check for only the @ and then send an email confirmation.

      • zurohki@aussie.zone
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 months ago

        Even if it’s a completely valid address and the domain exists, they still might’ve fat fingered the username part. Going to extreme lengths to validate email addresses is pointless, you still have to send an email to it anyway.

      • who@feddit.org
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        edit-2
        2 months ago

        Use a library

        Please, no. If someone wrote email address “validation” complex enough to warrant a library, then their code is almost certainly wrong.

        or check for only the @ and then send an email confirmation.

        Yes. Do that.

        If your boss demands a more detailed check at input time, then make it display warnings, not errors, and continue to the confirmation sending step if the user chooses to ignore the warning.

  • TomasEkeli@programming.dev
    link
    fedilink
    arrow-up
    4
    ·
    2 months ago

    I don’t validate emails, I test them.

    That’s your email? OK, what did we send it? if we couldn’t send to it or the user can’t read it there’s no reason to accept it.

    OK, maybe I do some light validation first, but I don’t trust the email address just because it’s email-address-shaped.