Thanks, all, for your helpful comments on regular expressions. I'll plan to learn more at the meeting tonight.
Richard
On Jan 22, 2004, at 10:26 AM, Michael L Torrie wrote:
On Thu, 2004-01-22 at 09:31, Richard Miller wrote:UUG:
A line in my PHP script tests for bad email addresses with the following regular expression: ... if (!ereg("[EMAIL PROTECTED],5}$", $email))
Just want to mention that one of my pet peeves is web sites that think
that email addresses with a "+" in the name aren't valid. They are
valid and rfc compliant. Technically you might want to allow them. For
example, [EMAIL PROTECTED] is a valid e-mail address. Just for
those that don't know how the plus sign is treated, according to the
SMTP RFC's, mail clients should accept e-mail addresses with a plus sign
in it, but for the purposes of delivery, everything after the plus sign
is ignored. This allows for some cool filtering and spam prevention.
For example, all my e-mail communication with comcast is done with
torriem+comcast. If I start getting spam that is being sent to
torriem+comcast, then I know who sold my address and then I can block
all mail with the "+comast" suffix.
...
However, this expression evaluates email addresses like
[EMAIL PROTECTED]" and "[EMAIL PROTECTED]" as incorrect.
It's the subdomain or two dots after the @ sign that causes the
problem. How can I change my expression above to allow email addresses
with subdomains?
Perhaps tonight at the UUG meeting we'll gleen the necessary information
on regular expressions to make this work. At the moment, without
spending a lot of time trying things I don't have any helpful advice,
unfortunately.
Also, if I am going to worry about (and allow) email addresses that have 2 dots after the @ sign, should I worry about there being email addresses with 3 or more dots? What expression would handle an infinite number of dots after the @ sign?
In theory, an address could have any number of "." separators after the @ sign. In practice I don't know of any really deep domains like that, but there is certainly nothing in the RFCs that would preclude it.
Michael
Thanks!
Richard
(Am I asking this just 10 hours premature?)
______________________________________________________________________ ____________________ BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list-- Michael L Torrie <[EMAIL PROTECTED]>
____________________ BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
smime.p7s
Description: S/MIME cryptographic signature
____________________ BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
