• Andy Miller (unregistered)
  • (nodebb)

    I prefer that validator to the one that blocks my emails from the TLD '.online' , because as any fool knows, there are no TLDs with more than 4 characters in them .

  • -to- (unregistered)
  • (nodebb)

    Pity about poor "[email protected]", I guess... (It's valid, but probably no longer functional...)

  • (nodebb)

    @Remy - OK, now using your "Compressed" line, set a breakpoint on all e-mails that DO contain an '@' but not a '.' ....

    (Hint, it can be done, but in my experience less than 5% of developers actually know how to set data driven breakpoints....and even if they do, it has a much higher impact on performance....)

  • Remy Zandwijk (unregistered)

    Your E-Mail Validation Logic is Wrong: https://www.netmeister.org/blog/email.html

    It is, uh, complicated.

  • my name is missing (unregistered)

    This was state of the art @.com era.

  • A N Other (unregistered)

    ...and I recall from the dim-and-distant past (a bit under 10 years ago) a customer insisting that we implement address validation to stop people using 'fake' email addresses ending in '.net' and '.uk'. This from a UK-based organisation, at the same time as new TLD like '.info' were very publicaly coming in to common usage.

    IIRC I implemented a basic regex (only about 3 lines long) to validate the address structure and enforce the TLD requirements. I updated that thing about 10 times as live customers complained that their email address was being rejected, before I left the programme.

    Curiously it was always the TLD enforcement portion...

  • RLB (unregistered) in reply to mike_james

    I prefer that validator to the one that blocks my emails from the TLD '.online' , because as any fool knows, there are no TLDs with more than 4 characters in them .

    Precisely. There are exactly three kinds of e-mail validators: ones that are overly simple and have false positives but at least no false negatives, ones that are overly clever and have false negatives (and probably false positives as well), and that one monster one from Zalgo, sorry, the IETF. In practice, the overly simple ones do the best job. If only because false positives are inevitable: in theory, [email protected] is a valid e-mail addres, but in practice, it's a false positive.

  • Edd (unregistered)

    This feels like something that could be used to warn the user that the address he wrote could be incomplete

  • (nodebb)

    Such code is coming from people who do not study enough and want to become programmer.

  • (nodebb) in reply to Nagesh

    Come on... this is a classic case of people not stating what they are actually trying to do, and then evaluating the result by some invisible yardstick.

    If you want to help people use the UI properly, do either a trivial validation or the ugly regular expression. Getting creative here will result in support calls or lost customers.

    If you want "good" email addresses for marketing purposes, send a confirmation message.

    If you want to prevent people from evading your requirement to sign up for something that they don't actually want, then also block all of the mail anonymizers (e.g. mailinator.com) and all of the addressing extensions (e.g. plus addressing).

  • The Shadow (doesn't) Knows (unregistered)

    It used to be that nested conditions were the way to write everything - faster, clearer, easier - guess the hip kids are doing it a different way for now.

  • (nodebb)

    "Good" emails are useful for more than just marketing purposes. "Send me a copy of every order placed in my etsy store", for example.

    [email protected] is a valid email address that contains no periods. It's only useful within a single Linux system, but if the local mail server tries to forbid it, it will cause a lot of problems.

  • Guest (unregistered)

    I would love to know if this code ever actually presented a problem, because I suspect it did not. It seems like it's going to handle all the real world use cases it needs to, more than well enough.

  • jay (unregistered)

    I have an email address that ends in ".us", and every now and then it gets rejected by email validators. I guess they think all domain names must end in com, net, or org.

    I'd rather have my validator be too loose than too tight. False positives mean an occasional typo doesn't get flagged. False negatives means you refuse to let someone place an order or sign up or whatever.

  • jay (unregistered)

    Something that really grates on me that I see in my company's code all the time is:

     if (x>0) // or whatever condition
        return true;
       return false;

    I mean, as opposed to just saying "return x>0;".

    Or even worse to my mind:

    if (someflag)
      return true;
      return false;
  • (nodebb) in reply to Ross_Presser

    "Good" emails are useful for more than just marketing purposes.

    Good was in quotes because good is a highly subjective term. Good means many things to many people, your example is just one among many. My point was that if you don't say what your particular "good" is, then expect that you won't get the correct result.

  • Worf (unregistered)

    Yeah, the only email validation you should do is just check it's at least a reasonable format of [email protected][sub.]domain.tld. This will catch most basic typos. The actual validation is when you send the user an email asking them if they actually meant to join up.

    It's like validating credit card numbers. Lund's Algorithm is there to catch basic typos. You then pass it to the processor which actually makes sure it's a valid card.

  • Foo AKA Fooo (unregistered) in reply to TheCPUWizard

    What's with this obsession with breakpoints? By this logic, one couldn't use any Boolean operators at all.

    You don't need to debug a trivial function like this, especially if you write it in a readable way in the first place. (I mean debug according to what it was written to do, not what it should do in this case.)

    If you need to debug some calling code that might use such an address, you do the same as you do when debugging some calling code that uses an address that contains a "+" and no "-" or whatever, you use a conditional breakpoint. No need to expose the internals of a validating function to handle some very specific hypothetical scenario.

    [email protected]

    PS: Talking about false positives, get rid of that FUCKING reCAPTCHA!

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to jay

    I've found that most incoming e-mail from .us addresses is spam. I actually have my inbound SMTP set up to whitelist the .us subdomains of two people that I know. And then I reject basically every vanity TLD there is, because no actual human (other than spammers) uses them for their inbox.

    Also spammers have lost their edge, and actually set up valid domains to spam from, for almost a decade now. In the good old days of the spam kings, their outbound mailers would just lie about it. This makes it so much easier to filter them. What I don't understand is why they loved ".stream" so much, probably it was cheapest.

  • Randal L. Schwartz (google)

    My favorite often-rejected address is "fred&[email protected]". It's perfectly legal, and an autoresponder (try it!), but has never been spammed, despite tons of online references. Now, "[email protected]" has gotten more than its share.

  • 516052 (unregistered) in reply to Foo AKA Fooo

    Usage breeds habit. Code is meant to be easy to read, decompress and debug for humans. And thus you want to create a habit of writing code that is like that. And you do this by writing good code even when it is not nessecary.

    If you instead train your self to keep minimizing code you'll end up creating a habit of doing so all the time. And than when you run into a situation where everyone, your future self included, wishes you didn't you'll still do it because that's the way you just work.

    It is better to create good habits early than to fix them later.

  • wideguy (unregistered)
    Comment held for moderation.
  • (nodebb)

    The only way to tell if an email address is valid is to send an email to it and ask the owner of the address if they received it. Almost all other attempts to validate an email address are a complete waste of time. I say, just do a scan to make sure it contains an @ and leave it at that. Maybe check that the domain has a . in it and is well formed (I checked a few random TLDs and none of them had MX records, so a mail server wouldn't know where to send a message whose recipient is [email protected]

  • DRY (unregistered)
    Comment held for moderation.
  • 516052 (unregistered) in reply to Jeremy Pereira
    Comment held for moderation.
  • Abigail (unregistered)
    Comment held for moderation.
  • Foo AKA Fooo (unregistered) in reply to 516052
    Comment held for moderation.
  • aalien (unregistered)

    Validating email addresses for syntax is actually very simple: almost any string with at least one character on both sides of @ is valid. For example, /@a is a completely valid email address. Any more complicated check will result in false positives. And no, you can't refer to RFC's, since in practice email services will support more characters than the RFC says.

    Also, Yucca mentioned. To the market place!

  • MaxiTB (unregistered)
    Comment held for moderation.
  • MaxiTB (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to Jeremy Pereira

    Checking there's a @, that the mailbox isn't an empty string and that the hostname has at least one . in a non-leading non-terminal position in it (i.e., isn't local!) is about all you can really do for early validation; virtually everything it catches is the obviously wrong stuff. It doesn't mean the address is right, but rather that it isn't dumb-ass wrong. After that, it's did the message get received by someone expecting it…

  • Christian Bau (unregistered)

    What do you want to achieve? That users enter a valid email address that can receive emails? Only way to do that is send out a message and receive a reply.

    What you should make sure is that the user hasn’t entered nothing. Like empty string, their username, password, credit card number. For that you make the minimal checks. Like an @ with something in front of it and at the end of it. You could do more checking and ask “are you sure that’s your email address”, and the user has to tap on “Yes”. You can’t prevent me from entering a fake like “[email protected]”, so why what you worry if I enter “[email protected]”?

  • David Mårtensson (unregistered) in reply to mike_james
    Comment held for moderation.
  • (nodebb) in reply to Randal L. Schwartz

    Is it possible to get an ampersand in there? I know some servers allow the single quote to be present in the email address.

  • (nodebb)

    Not too long ago, I had a couple of tickets for this. (Some emails would not get through.) My application was in the middle of a chain that sent out invoices and so on.

    After a couple of iterations, I just said: F* it, I'll pass everything to the SMTP server and let them deal with it.

  • Martin (unregistered)
    Comment held for moderation.
  • Anonymous (unregistered)

    Even this blocks legitimate albeit rare email addresses - a domain that's just a country code or TLD, therefore with no periods, is valid. (Though I believe it would still work if you added a trailing dot).

  • RandomNick42 (unregistered)

    Furiously enough, the fact that the email validation in one of my corporate systems I unearthed recently forced 2-4 char TLDs wasn't even TRWTF.

    Did you guys know all the email addresses MUST be in lowercase?

    I sure didn't. And neither did the customers app support admin trying to set up a notification e-mail target.

  • RandomNick42 (unregistered) in reply to mike_james

    Furiously enough, the fact that the email validation in one of my corporate systems I unearthed recently forced 2-4 char TLDs wasn't even TRWTF.

    Did you guys know all the email addresses MUST be in lowercase?

    I sure didn't. And neither did the customers app support admin trying to set up a notification e-mail target.

Leave a comment on “Where You At?”

Log In or post as a guest

Replying to comment #:

« Return to Article