Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #18227 > unrolled thread

Email Vali8dation Problem

Back to article view | Back to comp.lang.javascript

Contents

  Email Vali8dation Problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-01-23 15:27 -0700
    Re: Email Vali8dation Problem Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-01-24 01:18 +0100
      Re: Email Vali8dation Problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-24 02:06 +0100
        Re: Email Vali8dation Problem Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-01-24 22:30 +0100
          Re: Email Vali8dation Problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-24 22:38 +0100
      Re: Email Vali8dation Problem Jeff North <jnorthau@yahoo.com.au> - 2013-01-24 13:04 +1100
        Re: Email Vali8dation Problem Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-01-24 22:24 +0100
          Re: Email Vali8dation Problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-24 22:40 +0100
          Re: Email Vali8dation Problem Jeff North <jnorthau@yahoo.com.au> - 2013-01-26 00:12 +1100
            Re: Email Vali8dation Problem Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-01-25 21:56 +0100
              Re: Email Vali8dation Problem Jeff North <jnorthau@yahoo.com.au> - 2013-01-26 10:56 +1100
                Re: Email Vali8dation Problem Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-01-26 01:56 +0100
                  Re: Email Vali8dation Problem Jeff North <jnorthau@yahoo.com.au> - 2013-01-26 20:14 +1100
                    Re: Email Vali8dation Problem Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-01-26 13:21 +0100
                      Re: Email Vali8dation Problem Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-01-26 15:07 +0200
                        Re: Email Vali8dation Problem "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2013-01-26 16:04 +0200
                          Re: Email Vali8dation Problem Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-01-26 16:37 +0200
                        Re: Email Vali8dation Problem Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-01-26 15:46 +0100
                      Re: Email Vali8dation Problem Jeff North <jnorthau@yahoo.com.au> - 2013-01-27 10:30 +1100
    Re: Email Vali8dation Problem Andreas Bergmaier <andber93@web.de> - 2013-01-24 01:58 +0100
      Re: Email Vali8dation Problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-24 02:08 +0100
      Re: Email Vali8dation Problem "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-01-24 10:25 +0100
    Re: Email Vali8dation Problem Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-24 11:15 +0100
      Re: Email Validation Problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-01-24 08:53 -0700
        Re: Email Validation Problem Luc Yen <luc@goal.tw> - 2013-01-25 13:53 -0800
    Re: Email Vali8dation Problem Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-01-24 19:59 +0000
      Re: Email Vali8dation Problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-01-25 09:37 -0700
        Re: Email Vali8dation Problem Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-01-25 22:08 +0100
          Re: Email Vali8dation Problem Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-01-26 20:51 +0000

Page 1 of 2  [1] 2  Next page →

#18227 — Email Vali8dation Problem

Hi:

    I have the following undernoted isEMail() function defined in the <head> 
section of a  page

    This function returns false for:

                m.smith@example.com

    But this is (I believe)a validly-formatted email address and should 
return 'true',

    And, also:

                m.smith@dumbo.example.com also, obviously returns 'false'.

    Woud someone take a 'stab' at correcting the regex expression below to 
allow the above formatted email addresses to return 'true'.

    btw, google brings up dozens of variations for this task, but I'd like 
to get the 'perfect' one :((

Thanks !

-- 
Mel Smith

***** my  isEmail() function ***

function isEmail(email) {
return 
/^([a-zA-Z0-9_\-])+\@(([a-zA-Z0-9\-])+)+(\.[a-zA-Z]{2,6})(\.[a-zA-Z]{2})?$/i.test(email) 
;
}

***********************

[toc] | [next] | [standalone]

#18230

"Mel Smith" <med_cutout_syntel@aol.com> writes:

>     I have the following undernoted isEMail() function

You have put it in your signature, so it is quite inconvenient to quote
it. Anyway:
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address

[toc] | [prev] | [next] | [standalone]

#18232

Eric Bednarz wrote:

> "Mel Smith" <med_cutout_syntel@aol.com> writes:
>>     I have the following undernoted isEMail() function
> 
> You have put it in your signature, so it is quite inconvenient to quote
> it. Anyway:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the
> type-attribute.html#valid-e-mail-address

Apparently there is no way that HTML specification writers would refrain 
from talking about programming languages when they have absolutely no clue 
what they are talking about.

The “wilful violation of RFC 5322”, which will result in several valid e-
mail adresses not being considered valid in WHATWG HTML, is another of those 
statements that can only be considered a bad joke.  One can only hope that 
the W3C editors of HTML5 will prevent such WHATWG HTML nonsense from 
spreading too far.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18243

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Eric Bednarz wrote:

>> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the
>> type-attribute.html#valid-e-mail-address

I'm positive that I didn't write that.

> The “wilful violation of RFC 5322”, which will result in several valid e-
> mail adresses not being considered valid in WHATWG HTML, is another of those 
> statements that can only be considered a bad joke.  One can only hope that 
> the W3C editors of HTML5 will prevent such WHATWG HTML nonsense from 
> spreading too far.

Holding your breath *is* recommended in this particular case. :-)

[toc] | [prev] | [next] | [standalone]

#18244

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Eric Bednarz wrote:
>>> [<http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-
>>> the-type-attribute.html#valid-e-mail-address>]
> 
> I'm positive that I didn't write that.

There, I fixed it for you.  (Happens often when I need to fix KNode's borken 
handling of long quoted lines manually.  Unfortunately, apparently Debian is 
taking their time with packaging the latest version of KNode.)
 
>> The “wilful violation of RFC 5322”, which will result in several valid e-
>> mail adresses not being considered valid in WHATWG HTML, is another of
>> those statements that can only be considered a bad joke.  One can only
>> hope that the W3C editors of HTML5 will prevent such WHATWG HTML nonsense
>> from spreading too far.
> 
> Holding your breath *is* recommended in this particular case. :-)

ACK :)

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18234

On Thu, 24 Jan 2013 01:18:12 +0100, in comp.lang.javascript Eric
Bednarz <bednarz@fahr-zur-hoelle.org>
<m28v7jsabf.fsf@nntp.bednarz.nl> wrote:

>| "Mel Smith" <med_cutout_syntel@aol.com> writes:
>| 
>| >     I have the following undernoted isEMail() function
>| 
>| You have put it in your signature, so it is quite inconvenient to quote
>| it. Anyway:
>| http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address

Be aware that this the regexp on the WHATWG doesn't catch all invalid
addresses i.e.:
abc@ex
a.123@example.co.uk.123
The above return true.

The one I use is:
^[a-z0-9_\-]+(\.[_a-z0-9\-]+)*@([_a-z0-9\-]+\.)+([a-z]{2}|aero|arpa|biz|com|coop|edu|gov|info|int|jobs|mil|museum|name|nato|net|org|pro|travel)$
but it too has it's shortcomings.

HTH

[toc] | [prev] | [next] | [standalone]

#18242

Jeff North <jnorthau@yahoo.com.au> writes:

> Eric Bednarz <bednarz@fahr-zur-hoelle.org> wrote:
>
>>| http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address
>
> Be aware that this the regexp on the WHATWG doesn't catch all invalid
> addresses i.e.:

Are you familiar with the robustness principle?

(And beware that *your* regular expression has a stronger relation with the
proverbial shot in the dark than with RFC compliant syntax; not that I'm
suggesting one should strive for the latter.)

> abc@ex
> a.123@example.co.uk.123
> The above return true.

And they pass the build in validation of input[type=email] fields in
Chrome, Firefox, Opera and IE 10. So using the HTML5/WHATWG pattern as a
fallback should provide a consistent experience. Nice, isn't it.

[toc] | [prev] | [next] | [standalone]

#18245

Eric Bednarz wrote:

> Jeff North <jnorthau@yahoo.com.au> writes:
>> abc@ex
>> a.123@example.co.uk.123
>> The above return true.
> 
> And they pass the build in validation of input[type=email] fields in
> Chrome, Firefox, Opera and IE 10. So using the HTML5/WHATWG pattern as a
> fallback should provide a consistent experience. Nice, isn't it.

Not if theirs is too strict, which it is.  No, that is *not* nice.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18248

On Thu, 24 Jan 2013 22:24:40 +0100, in comp.lang.javascript Eric
Bednarz <bednarz@fahr-zur-hoelle.org>
<m2622m9svb.fsf@nntp.bednarz.nl> wrote:

>| Jeff North <jnorthau@yahoo.com.au> writes:
>| 
>| > Eric Bednarz <bednarz@fahr-zur-hoelle.org> wrote:
>| >
>| >>| http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address
>| >
>| > Be aware that this the regexp on the WHATWG doesn't catch all invalid
>| > addresses i.e.:
>| 
>| Are you familiar with the robustness principle?
>| 
>| (And beware that *your* regular expression has a stronger relation with the
>| proverbial shot in the dark than with RFC compliant syntax; not that I'm
>| suggesting one should strive for the latter.)
>| 
>| > abc@ex
>| > a.123@example.co.uk.123
>| > The above return true.
>| 
>| And they pass the build in validation of input[type=email] fields in
>| Chrome, Firefox, Opera and IE 10. So using the HTML5/WHATWG pattern as a
>| fallback should provide a consistent experience. Nice, isn't it.

So you thing that 1@1 is a valid email address as it passes the
validation routine in the above mentioned browsers.

[toc] | [prev] | [next] | [standalone]

#18253

Jeff North <jnorthau@yahoo.com.au> writes:

> Eric Bednarz <bednarz@fahr-zur-hoelle.org> wrote:

>>| Are you familiar with the robustness principle?

[...]

> So you thing that 1@1 is a valid email address as it passes the
> validation routine in the above mentioned browsers.

A simple 'no' would have sufficed.

-- 
http://isemail.info/1%401

[toc] | [prev] | [next] | [standalone]

#18257

On Fri, 25 Jan 2013 21:56:12 +0100, in comp.lang.javascript Eric
Bednarz <bednarz@fahr-zur-hoelle.org>
<m2mwvxc783.fsf@nntp.bednarz.nl> wrote:

>| Jeff North <jnorthau@yahoo.com.au> writes:
>| 
>| > Eric Bednarz <bednarz@fahr-zur-hoelle.org> wrote:
>| 
>| >>| Are you familiar with the robustness principle?
>| 
>| [...]
>| 
>| > So you thing that 1@1 is a valid email address as it passes the
>| > validation routine in the above mentioned browsers.
>| 
>| A simple 'no' would have sufficed.

Be conservative in what you do, be liberal in what you accept from
others (often reworded as "Be conservative in what you send, liberal
in what you accept").

So, why are you concerned about input validation?
Oh that's right, your 'robustness principle' or Postel's Law is
nothing to do with data validation but about a TCP protocol.
http://queue.acm.org/detail.cfm?id=1999945

[toc] | [prev] | [next] | [standalone]

#18259

Jeff North <jnorthau@yahoo.com.au> writes:

> Eric Bednarz <bednarz@fahr-zur-hoelle.org> wrote:
>
>>| Jeff North <jnorthau@yahoo.com.au> writes:
>>| 
>>| > Eric Bednarz <bednarz@fahr-zur-hoelle.org> wrote:
>>| 
>>| >>| Are you familiar with the robustness principle?
>>| 
>>| [...]
>>| 
>>| > So you thing that 1@1 is a valid email address as it passes the
>>| > validation routine in the above mentioned browsers.
>>| 
>>| A simple 'no' would have sufficed.
>
> Be conservative in what you do, be liberal in what you accept from
> others (often reworded as "Be conservative in what you send, liberal
> in what you accept").

It's OK with me if you are too lazy to attribute your sources, but it is
rather lame to do so in combination with selective quoting.

> So, why are you concerned about input validation?

I'm only concerned about really bad input validation (e.g. your
example); you seem to have a hard time to grasp that the only potential
problem with the WHATWG/HTML5 implementation is not that it is too
liberal but that it is too restrictive; I would call that rather
academical edge cases, but (re)strict(ivel)y speaking Thomas is quite
right, of course.

Besides, I really do thing that 1@1 is a valid email address.

> Oh that's right, your 'robustness principle' or Postel's Law is
> nothing to do with data validation but about a TCP protocol.
> http://queue.acm.org/detail.cfm?id=1999945

Try to relocate 'general design' in that Wikipedia article.

[toc] | [prev] | [next] | [standalone]

#18260

On Sat, 26 Jan 2013 01:56:15 +0100, in comp.lang.javascript Eric
Bednarz <bednarz@fahr-zur-hoelle.org>
<m2vcakg3tc.fsf@nntp.bednarz.nl> wrote:

>| Jeff North <jnorthau@yahoo.com.au> writes:
>| 
>| > Eric Bednarz <bednarz@fahr-zur-hoelle.org> wrote:
>| >
>| >>| Jeff North <jnorthau@yahoo.com.au> writes:
>| >>| 
>| >>| > Eric Bednarz <bednarz@fahr-zur-hoelle.org> wrote:
>| >>| 
>| >>| >>| Are you familiar with the robustness principle?
>| >>| 
>| >>| [...]
>| >>| 
>| >>| > So you thing that 1@1 is a valid email address as it passes the
>| >>| > validation routine in the above mentioned browsers.
>| >>| 
>| >>| A simple 'no' would have sufficed.
>| >
>| > Be conservative in what you do, be liberal in what you accept from
>| > others (often reworded as "Be conservative in what you send, liberal
>| > in what you accept").
>| 
>| It's OK with me if you are too lazy to attribute your sources, but it is
>| rather lame to do so in combination with selective quoting.

This is 'rich' coming from someone who snips text without attribution.
 
>| > So, why are you concerned about input validation?
>| 
>| I'm only concerned about really bad input validation (e.g. your
>| example); 

The example I gave that you snipped without attribution? If you had
read my original post (and not snipped it without attribution) then
you would've noticed the following "but it too has it's shortcomings".
Which means I never claimed it was perfect. The only 'bad thing' I can
see about the regexp is that it forces users to enter a correctly
structured email address. 

>| you seem to have a hard time to grasp that the only potential
>| problem with the WHATWG/HTML5 implementation is not that it is too
>| liberal but that it is too restrictive; I would call that rather
>| academical edge cases, but (re)strict(ivel)y speaking Thomas is quite
>| right, of course.

The WHATWG regexp too restrictive ROTFLMAO. If it was too restrictive
then it certainly wouldn't allow invalid structured email addresses.
 
>| Besides, I really do thing that 1@1 is a valid email address.

What you think and reality are galaxies apart.
 
>| > Oh that's right, your 'robustness principle' or Postel's Law is
>| > nothing to do with data validation but about a TCP protocol.
>| > http://queue.acm.org/detail.cfm?id=1999945
>| 
>| Try to relocate 'general design' in that Wikipedia article.

Doesn't matter how much you try and twist things the 'robustness
principle' is still about the TCP protocol and nothing to do with data
validation.

[toc] | [prev] | [next] | [standalone]

#18261

Jeff North <jnorthau@yahoo.com.au> writes:

> [...] The only 'bad thing' I can
> see about the regexp is that it forces users to enter a correctly
> structured email address. 

Let's have another look then.

^[a-z0-9_\-]+(\.[_a-z0-9\-]+)*@([_a-z0-9\-]+\.)+([a-z]{2}|aero|arpa|biz|com|coop|edu|gov|info|int|jobs|mil|museum|name|nato|net|org|pro|travel)$

On second thought, the only bad thing I can see is that you use
completely arbitrary rules for the local part and the domain part.
The rest looks fine.

> Doesn't matter how much you try and twist things the 'robustness
> principle' is still about the TCP protocol

Know your pleonasms.

Anyway, I see your point. The world is just full of dumb people who
don't get it. I even know people who aim to and succeed in writing
progams for MS Windows that do one thing and do it well. If they were
just a tad smarter they would understand that they can't do that,
because that's the principle for writing UNIX programs.

> and nothing to do with data
> validation.

Being liberal in accepting user input can save you a lot of
embarrassment, which is considered a good thing where I come from.
Your mileage will vary.

[toc] | [prev] | [next] | [standalone]

#18262

Eric Bednarz <bednarz@fahr-zur-hoelle.org> writes:
> Jeff North <jnorthau@yahoo.com.au> writes:

>> [...] The only 'bad thing' I can
>> see about the regexp is that it forces users to enter a correctly
>> structured email address. 

> Let's have another look then.
> ^[a-z0-9_\-]+(\.[_a-z0-9\-]+)*@([_a-z0-9\-]+\.)+([a-z]{2}|aero|arpa|biz|com|coop|edu|gov|info|int|jobs|mil|museum|name|nato|net|org|pro|travel)$

> On second thought, the only bad thing I can see is that you use
> completely arbitrary rules for the local part and the domain part.

Very restricting! That does not allow any national domains!

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#18263

2013-01-26 15:07, Jukka Lahtinen wrote:

>> ^[a-z0-9_\-]+(\.[_a-z0-9\-]+)*@([_a-z0-9\-]+\.)+([a-z]{2}|aero|arpa|biz|com|coop|edu|gov|info|int|jobs|mil|museum|name|nato|net|org|pro|travel)$
[...]
> Very restricting! That does not allow any national domains!

Rather, it allows too many of them, including nonexistent national 
domains, but that's probably intentional. The part
[a-z]{2}
allows any 2-character string consisting of Ascii letters.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#18264

"Jukka K. Korpela" <jkorpela@cs.tut.fi> writes:
> 2013-01-26 15:07, Jukka Lahtinen wrote:

>> ^[a-z0-9_\-]+(\.[_a-z0-9\-]+)*@([_a-z0-9\-]+\.)+([a-z]{2}|aero|arpa|biz|com|coop|edu|gov|info|int|jobs|mil|museum|name|nato|net|org|pro|travel)$
> [...]
>> Very restricting! That does not allow any national domains!

> Rather, it allows too many of them, including nonexistent national
> domains, but that's probably intentional. The part
> [a-z]{2}
> allows any 2-character string consisting of Ascii letters.

Oh, I missed that. Anyway, I wouldn't say it alllows too many anything.
It's not a good idea to validate the address too strictly, because it's
too easy to miss some perfectly valid case.
Just check that there's one @ character somewhere and it's not the first
character, and after the @ there is at least one dot, and at least one
alphanumeric character before and after every dot.

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#18265

Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> writes:

> Eric Bednarz <bednarz@fahr-zur-hoelle.org> writes:
>> Jeff North <jnorthau@yahoo.com.au> writes:
>
>>> [...] The only 'bad thing' I can
>>> see about the regexp is that it forces users to enter a correctly
>>> structured email address. 
>
>> Let's have another look then.
>> ^[a-z0-9_\-]+(\.[_a-z0-9\-]+)*@([_a-z0-9\-]+\.)+([a-z]{2}|aero|arpa|biz|com|coop|edu|gov|info|int|jobs|mil|museum|name|nato|net|org|pro|travel)$
>
>> On second thought, the only bad thing I can see is that you use
>> completely arbitrary rules for the local part and the domain part.
>
> Very restricting! That does not allow any national domains!

Yes it does. But it manages to get a lot of other things wrong. In no
particular order, and far from complete:

- No uppercase letters.
- A bunch of legal characters are not allowed in the local part
  (and that does not even include splitting hairs about quoted strings
  and commments.)
- The group in the local part is silly and just wastes memory.
- An underscore in the domain part?
- Putting IP addresses aside, a bunch of registered top level domains
  are missing; the real problem of course is that hard-coding any set
  of domains is an inherently stupid idea. If you really want to
  validate that a TLD is registered, use a web service that queries
  IANA. Seriously. nato? That was dumped in the nineties.

[toc] | [prev] | [next] | [standalone]

#18270

On Sat, 26 Jan 2013 13:21:10 +0100, in comp.lang.javascript Eric
Bednarz <bednarz@fahr-zur-hoelle.org>
<m2pq0suocp.fsf@nntp.bednarz.nl> wrote:

>| Being liberal in accepting user input can save you a lot of
>| embarrassment, which is considered a good thing where I come from.
>| Your mileage will vary.

Care to post a web site that you have created and that has a data
entry form. I'd like to test how much you adhere to the 'robustness
principle'. If your form doesn't allow me to enter any information
that I want in any field then you are not adhering to the principle.

[toc] | [prev] | [next] | [standalone]

#18231

Mel Smith schrieb:
> Hi:
>
>      I have the following undernoted isEMail() function defined in the <head>
> section of a  page
>
>      This function returns false for:
>
>                  m.smith@example.com
>                  m.smith@dumbo.example.com
>
>      Woud someone take a 'stab' at correcting the regex expression below to
> allow the above formatted email addresses to return 'true'.
 >
 > 
/^([a-zA-Z0-9_\-])+\@(([a-zA-Z0-9\-])+)+(\.[a-zA-Z]{2,6})(\.[a-zA-Z]{2})?$/i.test(email) 


The part before the at-sign does not allow dots.

The part after the at-sign does only allow two-level-domains with a 
2-to-6-char TLD or three-level domains with two-char TLD and 2-to-6-char 
second-level-domain. "example" has 7 chars.

Also, the expression (([a-zA-Z0-9\-])+)+ is very odd and could lead to 
catastrophic backtracking.

> google brings up dozens of variations for this task, but I'd like
> to get the 'perfect' one :((

There is no perfect one. Email adresses in RFC format are even not 
parsable by regular expressions.

However, don't overcomplificate the task. Checking whether the entered 
address is syntactically valid *and* catching all edge cases is hardly 
possible. At last, you never know whether the user entered an existing 
mail or just "john.doe@example.com".

Using /^\s*(.+@.+)\s*$/ should be enough to check whether the entered 
string looks like an email adress, and warning the user if it does not.

regards,
  Bergi

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web