1. #11
    Sencha - Ext JS Dev Team evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    16,125
    Vote Rating
    514
    evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute

      0  

    Default


    The email regex isn't meant to be the be all and end all of email verification. It's just meant to catch the common cases. If it doesn't do what you want, you can extend it for the more complicated cases.
    Evan Trimboli
    Sencha Developer
    Twitter - @evantrimboli
    Don't be afraid of the source code!

  2. #12
    Sencha User
    Join Date
    Aug 2008
    Location
    Minnesota
    Posts
    24
    Vote Rating
    0
    usiw is on a distinguished road

      0  

    Default Read the thread

    Read the thread


    Evant is right, and if you would read the whole thread I already provided a regex that provides more functionality, you just need to create a new vtype that uses it:

    Code:
    Ext.apply(Ext.form.VTypes, {
        EmailAddress:  function(v) {
            return /^(?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-\/=?^_`{|}~]+)+@((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}$/.test(v);
        },
        EmailAddressText: 'Must be a valid Email address',
        EmailAddressMask: /[a-zA-Z\d!#$%&'*+\-\/=?^_`{|}~@\.]/
    });
    Quote Originally Posted by usiw View Post
    Here is a regular expression pulled from a larger, more RFC correct regex that should suffice for nearly all real world email addresses:

    Code:
    ^(?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+)+@((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}$
    I pulled out support for
    Code:
    "my name" <my_email@domain.com>
    type emails as well as the
    Code:
    email@[120.90.90.120]
    format to simplify things.
    Last edited by usiw; 15 Oct 2009 at 6:42 AM. Reason: Escaped / in regex strings

  3. #13
    Sencha User
    Join Date
    May 2007
    Posts
    191
    Vote Rating
    0
    temporary is on a distinguished road

      0  

    Default


    Then - what's the point in having a half working email vtype anyway? Either it works out of the box, or it can be left out.

    I know, matching valid email adresses is a hard topic, but I guess the regular user doesn't know this and wonders why a customer can't register with whatever-@somewhere.com

  4. #14
    Sencha User
    Join Date
    Aug 2008
    Location
    Minnesota
    Posts
    24
    Vote Rating
    0
    usiw is on a distinguished road

      0  

    Default


    It's all a matter of preference. For instance, Microsoft's Hotmail and Live email services don't allow the whole RFC character set either:

    Your Windows Live ID can contain only letters, numbers, periods (.), hyphens (-), and underscores (_). The ID can't contain special characters or accented letters.
    and Google's GMail is even more restrictive:

    Sorry, only letters (a-z), numbers (0-9), and periods (.) are allowed.
    I for one use extended characters in most of my email addresses (hyphens, apostrophes, etc) and implement plus filtering which means I am very RFC compliant on my own MTA. Google, on the otherhand, allows periods but ignores them when validating user names (joe.smith@gmail.com, jo.esmith@gmail.com, and joesmith@gmail.com are all the same). Unfortunately, SMTP servers in general are well known for making their own rules about when to follow RFC and when not to. My company has developed its own SMTP server and spam filtering software and has seen its fair share of poorly written SMTP servers trying to deliver email! I would say that ExtJS' decision to make a very simple email validation regex is a safe way to ensure that servers will accept the address. How much more functionality to add is up to you, better to have too little than too much in this case! There are many discussions online about the subject, one being here http://en.wikipedia.org/wiki/E-mail_address.

  5. #15
    Sencha User twisted_pear's Avatar
    Join Date
    Aug 2010
    Location
    North Carolina
    Posts
    23
    Vote Rating
    0
    twisted_pear is on a distinguished road

      0  

    Lightbulb


    Speaking to Gmail addresses, my..n....ame@gmail.com is value, but the above regex does not allow consecutive periods.

    ^(?!\.)(?>\.*?[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+)+@((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}$

    This does, just added *

  6. #16
    Sencha User
    Join Date
    Aug 2008
    Location
    Minnesota
    Posts
    24
    Vote Rating
    0
    usiw is on a distinguished road

      0  

    Default Consecutive periods

    Consecutive periods


    Per RFC 5322(http://tools.ietf.org/html/rfc5322#section-3.2.3), consecutive periods are NOT allowed in the local part (the portion before the @). Google 's use of periods within a name is unique to them but is similar to another feature called plus addressing. A Google email address of my..n...ame@gmail.com is identical to myname@gmail.com and m.y.n.a.m.e@gmail.com. When Google processes the email address they strip all periods from the local part to get the true address. This is not valid RFC which the original regex tries to follow as close as possible (a true RFC compliant regex would be too complex and wouldn't necessarily run in all implementations of the regex engine).

    If you want to add support for these types of addresses(currently only Google uses them) then by all means change the regex, but if you are looking to perform a stricter validation that follows the standard then use the one I originally posted. As a side note, most MTAs don't follow the spec. These variations from the specification may be considered "bugs" in their software or as "features". In Google's case it is a feature, but don't expect everyone else to comply with their addition because it does technically break the spec!

  7. #17
    Sencha User
    Join Date
    Aug 2008
    Location
    Minnesota
    Posts
    24
    Vote Rating
    0
    usiw is on a distinguished road

      0  

    Default Consecutive periods

    Consecutive periods


    Also note that this thread as viewed on the Sencha's forums do not highlight the email addresses that contain consecutive periods, but RFC compliant ones are highlighted! Just an example of how other vendors may not honor the fact that you decided to break the specification by adding extra periods into your Google email address.

  8. #18
    Sencha User twisted_pear's Avatar
    Join Date
    Aug 2010
    Location
    North Carolina
    Posts
    23
    Vote Rating
    0
    twisted_pear is on a distinguished road

      0  

    Default


    usiw,

    Excellent point. What are the risk of accepting non RFC email addresses? Might some mail systems not properly handle those messages? I ask since while I know that not all email providers comply with the RFC, I also consider it a defect against my application if a "valid email" cannot be entered. By "valid email" I mean an address that a user can functionally send/receive mail from. To them this is a valid email address implicitly because it works for them. Thanks.

    J

  9. #19
    Sencha User
    Join Date
    Aug 2008
    Location
    Minnesota
    Posts
    24
    Vote Rating
    0
    usiw is on a distinguished road

      0  

    Default


    There is always a risk when not following the specifications. In the case of emails, most email providers don't perform validation when delivering emails with the thought that the destination mail server will determine if it is a valid email address (if it exists) or not. Note that I said most, not all. I actually work for a company that developed an MTA that handles millions of emails per day and we have the same philosophy of letting the destination server validate the address. Some SMTP servers have the option of being more strict on the email address validation and some have this enabled by default. It's this loose following of the spec that allows many (not all) spam messages to get through.

    Many mail clients don't allow for invalid email addresses to be entered into the TO: field as well. Mac Mail complains when an email address contains consecutive periods, but it gives a "Send Anyway" button as a workaround. Outlook 2011 doesn't complain. Without doing a thorough test of all the email clients you are never sure which ones may reject the address and therefore not send the email. Several years back I was unable to register for a Microsoft Tech.Net account because they claimed my email address was invalid (it contained an underscore). In this case their email validation was too simplistic and only checked for a-zA-Z0-9 and dash before the @.

    The short answer to your question is that there exists the possibility that some email clients and some SMTP servers may reject the address claiming it as invalid (which it technically is). In the real world though you will find that most will accept it as valid. The question is whether or not you want to deal with the person that is unable to send to that type of address. If you decide not to follow the spec then head in the direction of being more forgiving on your validation, meaning don't reject addresses that are valid but be willing to accept addresses that may not be considered valid.

  10. #20
    Sencha User
    Join Date
    Aug 2008
    Location
    Minnesota
    Posts
    24
    Vote Rating
    0
    usiw is on a distinguished road

      0  

    Default


    I tested several SMTP servers using an email address with consecutive periods and about half of them returned this:

    "RCPT TO address improperly formatted, see RFC 821 sec 3.3"

    so it appears that there are more strict servers than I originally thought. Better to stick to the spec otherwise you'll be getting rejected emails or bounce backs!

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar