http://qs321.pair.com?node_id=393811


in reply to Re: Please evaluate: RegEx for validating e-mail addresses
in thread Please evaluate: RegEx for validating e-mail addresses

If this is a "slight" correction... *lol*

Thanks, Ovid, but I'd like to make a generic regex so I can use both in and outside Perl (in a JavaScript Function for websites, for an example).

Replies are listed 'Best First'.
Re^3: Please evaluate: RegEx for validating e-mail addresses
by davido (Cardinal) on Sep 25, 2004 at 17:39 UTC

    The point that Ovid was making is that if you wish to use a regular expression to validate an email address's format, you've got to make a choice: Either use that whopping big regexp that he provided, or risk mistakenly rejecting valid addresses. If you don't mind rejecting valid addresses, go with a less intricate regular expression, but it won't be a robust solution.


    Dave

      davido,
      While you and Ovid are both correct, context is important. Just because all of those email addresses are valid WRT the RFC, they likely are not valid for a given MTA. It is also conceivable probable that an MTA accepts email addresses as valid that are categorized as invalid by the RFC. Having spent a couple of years managing an enterprise email gateway, I have seen what happens when two MTAs can't agree on what is and is not valid.

      My whole point being is that - right or wrong, a simple form of a regex can work for validating email addresses when what governs valid is local environment and not the global RFC.

      Cheers - L~R

        L-R, I think you're confusing "stuff that microsoft produces" with actual Mail Transfer Agents.

        All internet MTAs that I'm aware of would have no problems understanding and delivering those addresses. Sendmail, qmail, postfix, exim, smail, qsmtpd, etc etc.

        I will stand firm on chastising anyone that narrows "valid email" down to their own limited view of email. Follow the RFC, or don't play at all. If you want to "embrace and extend", please do that in the privacy of your own cubicle, not out in public.

        I will also stand firm on chastising those (such as you, L-R) who support such narrow views. Please don't do that. It makes my job harder as well.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

        I do understand the point you're making; that sometimes there is a "good enough" solution, especially where a full RFC implementation seems like overkill in the context of a more closed environment.

        But you mentioned that you've seen what happens when two MTA's can't agree on what is and is not valid. I imagine that can be quite a problem. So why make things worse by supporting the building of solutions that fail to meet the RFC? If a particular network is going to send and receive email over the internet, or if a webpage is going to be validating email addresses that are to be valid on the internet, a mostly-correct solution is going to be somewhat-incorrect. I know that CGI Programming with Perl suggests a mostly-correct solution for matching email addresses. But there exists (in the CPAN modules) solutions that are fully correct. If writing ones' own fully-compliant solution is too much work, there's always those modules.

        The OP suggested that he couldn't use modules because this ultimately will be ported to another language. ...well at least learn from the modules out there how to go about the task. Or invoke Perl from that other language's code to perform the test. ...or ask the question in a PHP-oriented group, where undoubtedly it has been answered before. ;)


        Dave