• 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 "john@uk", 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.

    root@localhost 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;
else
   return false;

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

    Or even worse to my mind:

    if (someflag)
  return true;
else
  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 something@[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.

    .@

    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)

    That is perfectly fine as far as email validation goes in practice: it prevents user from entering e.g. their name in the wrong field.

    The actual problems with email address cannot be solved technically: typoes, wrong addresses (wether on purpose or by ignorance), non existing addresses.

  • (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 postmaster@com

  • DRY (unregistered)

    public bool EmailIsValid(String email)

    {

    for check in ["@", "."] {

    return false unless email.Contains(check);

}

return true;

    }

  • 516052 (unregistered) in reply to Jeremy Pereira

    Yes and no. Whilst I agree that proper validation is a fools errand some form of basic check combined with a non binding warning to the user is very useful to avoid typos.

  • Abigail (unregistered)

    I say, just do a scan to make sure it contains an @ and leave it at that.

    And reject all those bang paths?

  • Foo AKA Fooo (unregistered) in reply to 516052

    I agree with your last sentence, but I don't agree that writing 14 lines instead of 1 is a good habit. YAGNI!

  • 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)

    When I hear e-mail validation, I am usually extremely surprised about the lack of understand when it comes to the very unreliable message transport mechanics behind e-mail. Spoiler, the correct way to validate an e-mail address looks like this:

    return email.IndexOf('@') > 0

    I will explain why, but first we actually have to consider the UX side of things and most common mistakes users will make:

    1. The user will not realize an e-Mail is needed for this input field: Usually this a sign of bad UX followed by bad UI design, for example the text is to small, the input field labelling is non-existend or reads something along "Mail Address" or the label is not attached to the input field correctly, so screen readers or other devices are not presenting meaning of the input field to the user correctly.

    2.) The e-mail address is valid but due to a typo, the user can not be reached or any transport layer will not allow the e-mail to pass through for some reason. This can be IP spam filter, client spam filter, some bad or overzealous implementations of validations along the way, geo-locking etc.

    === Validation of input (solution to 1) ===

    return email.IndexOf('@') > 0

    Now it's very transparent way the given validation code is indeed the best solution: a) It validates that users didn't enter something else than an e-mail. b) It also validates that '@' is not the first character, for example when the user enters by mistake a chat reply shortcut.

    === Validation if the user can be reached (solution to 2) ===

    The only way to validate if the user can be reached, is by sending an mail with a reply link. Even this method does not mean that every mail will be received, but it at least ensures that the user entered HIS e-mail address and a mail can get through. This is the only way and from a UX side there has to be resend options and the possibility to change the e-mail address at any time with same validations in place.

  • MaxiTB (unregistered)

    On a side note, I find it funny that the nested vs. inline discussion is still going on religiously :-)

    I had a coworker once which: a) Removed all nested ifs in favor of unreadable inline && and || (in various combination with various groupings and negations). b) Remove all inline tertiary operators in favor of nested ifs or even more unreadable inline && and ||.

    It was completely incostistent, produced horrible code with endless seeming lines or even worst spread over multiple lines in a random fashion (seemingly by an abitary line character limit), so basically your typical code monkey code.

    Personally I never use the best most readable option available and I judge the by feedback of junior developers when they do my code reviews. This is the proper way to create readable code as a professional senior (mostly preferring a fluent annotation anyway), no matter if you prefer inline or a nested approach.

    How would I write the code?

    protected bool IsValidEmail(string self) => self.Contains('@') && self.Contains('.');

    However I use fluent validations for models anyway this days, people that write validators by hand are honestly more hobby developers: https://www.nuget.org/packages/FluentValidation/

  • (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 “daft@dog”?

  • David Mårtensson (unregistered) in reply to mike_james

    Agreed, the only improvement I would suggest is the collapsing to a one liner and checking for the dot AFTER the @.

    (I know you can technically write the IP of the server as decimal but I can live with not accepting that)

    For anything more fancy your most likely going to exclude valid emails out of ignorance.

  • (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.

  • 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 #:

Log Out

« Return to Article