Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > RE: Don't use regular expressions to "validate" email addresses (was:Ineed some help with a regexp please)

Reply
Thread Tools

RE: Don't use regular expressions to "validate" email addresses (was:Ineed some help with a regexp please)

 
 
bruce
Guest
Posts: n/a
 
      09-22-2006
so ben...

if you were creating a web app with an email form... rather than try to
check if the email is valid... you'd create something to allow anyone to
potentially spam the hell out of a system...

my two cents worth... try to verify/validate that the email is valid, and
possibly belongs to the user...

peace...



-----Original Message-----
From: python-list-bounces+bedouglas=
[mailtoython-list-bounces+bedouglas=]On Behalf
Of Ben Finney
Sent: Thursday, September 21, 2006 6:07 PM
To: python-
Subject: Don't use regular expressions to "validate" email addresses
(was: Ineed some help with a regexp please)


"John Machin" <> writes:

> A little more is unfortunately not enough. The best advice you got was
> to use an existing e-mail address validator. The definition of a valid
> e-mail address is complicated. You may care to check out "Mastering
> Regular Expressions" by Jeffery Friedl. In the first edition, at least
> (I haven't looked at the 2nd), he works through assembling a 4700+ byte
> regex for validating e-mail addresses. Yes, that's 4KB. It's the best
> advertisement for *not* using regexes for a task like that that I've
> ever seen.


The best advice I've seen when people ask "How do I validate whether
an email address is valid?" was "Try sending mail to it".

It's both Pythonic, and truly the best way. If you actually want to
confirm, don't try to validate it statically; *use* the email address,
and check the result. Send an email to that address, and don't use it
any further unless you get a reply saying "yes, this is the right
address to use" from the recipient.

The sending system's mail transport agent, not regular expressions,
determines which part is the domain to send the mail to.

The domain name system, not regular expressions, determines what
domains are valid, and what host should receive mail for that domain.

Most especially, the receiving mail system, not regular expressions,
determines what local-parts are valid.

--
\ "I believe in making the world safe for our children, but not |
`\ our children's children, because I don't think children should |
_o__) be having sex." -- Jack Handey |
Ben Finney

--
http://mail.python.org/mailman/listinfo/python-list

 
Reply With Quote
 
 
 
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      09-22-2006
bruce wrote:
> so ben...
>
> if you were creating a web app with an email form... rather than try to
> check if the email is valid...


Ever bothered to read the relevant rfc ?

> you'd create something to allow anyone to
> potentially spam the hell out of a system...


I'm sorry, but I fail to see how validating (or not) an email address
could prevent using a webmail form for spamming. Care to elaborate ?

> my two cents worth... try to verify/validate that the email is valid,


If it doesn't have an @ somewhere in it, it's not a valid mail address.
Else, it may or not be a valid email address - and then the only
reliable way to know is to send a mail to that address.

> and
> possibly belongs to the user...


How do you intend to check this ?

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in ''.split('@')])"
 
Reply With Quote
 
 
 
 
Fredrik Lundh
Guest
Posts: n/a
 
      09-22-2006
Bruno Desthuilliers wrote:

>> if you were creating a web app with an email form... rather than try to
>> check if the email is valid...

>
> Ever bothered to read the relevant rfc ?


or the perl faq:

http://faq.perl.org/perlfaq9.html#How_do_I_check_a_val

</F>



 
Reply With Quote
 
Damjan
Guest
Posts: n/a
 
      09-22-2006
>> you'd create something to allow anyone to
>> potentially spam the hell out of a system...

>
> I'm sorry, but I fail to see how validating (or not) an email address
> could prevent using a webmail form for spamming. Care to elaborate ?


The best way would be to implement some limiting features. Try two times
from the same IP address in less than 10 minutes and you are banned for the
day. Or some such.


--
damjan
 
Reply With Quote
 
Cameron Laird
Guest
Posts: n/a
 
      09-22-2006
In article <4513d40c$0$75029$>,
Damjan <> wrote:
>>> you'd create something to allow anyone to
>>> potentially spam the hell out of a system...

>>
>> I'm sorry, but I fail to see how validating (or not) an email address
>> could prevent using a webmail form for spamming. Care to elaborate ?

>
>The best way would be to implement some limiting features. Try two times
>from the same IP address in less than 10 minutes and you are banned for the
>day. Or some such.

.
.
.
I'm having a lot of trouble imagining the problem this
fixes. I certainly deal with plenty of spam that would
continue to flow even were this proposal to be implemented.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[regexp] How to convert string "/regexp/i" to /regexp/i - ? Joao Silva Ruby 16 08-21-2009 05:52 PM
Re: Don't use regular expressions to "validate" email addresses Ben Finney Python 0 09-22-2006 02:17 AM
Help me understand use of regular expressions to validate data Ted Perl Misc 5 05-30-2006 02:02 AM
Regular Expressions, WSH, and not getting New RegExp to work at all Bã§TãRÐ ASP General 3 02-09-2004 02:45 PM
Add custom regular expressions to the validation list of available expressions Jay Douglas ASP .Net 0 08-15-2003 10:19 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57