tracker issue : CF-4204100

{color:#333333}Hi James,{color} {color:#333333}<CFSET TestEmail = '"Testy McTest" <test@test.com>'>{color} {color:#333333}<CFDUMP VAR="#isValid('email', TestEmail)#">{color}   Above code snippet prints YES in CF 2016 and 2018.    {color:#333333}<CFSET TestEmail = '"Testy McTest" <testtest.com>'>{color} {color:#333333}<CFDUMP VAR="#isValid('email', TestEmail)#">{color}   {color:#333333}Above code prints NO which means the email part within <….> is being validated. Hence this is not a bug and closing it.{color} {color:#333333}Regards,{color} {color:#333333}Suchika{color}

Comment by Suchika S.

Perhaps you should introduce something like isValid("emailwithdisplayname", testEmail) since email address validation that validates garbage isn't really validation at all. A display name is not an email address, and if it was I think it would affect how the message was routed would it not?

Comment by Justin L.

Suchika, Your example compared an email address with a "username". That is not the same thing as adding a cosmetic "display name" into the validation mix. I have third-party systems that are failing as a result of ColdFusion somehow not understanding what an email address is and accepting garbage strings. Please create a basic HTML5 INPUT field using email validation. <input type="email" name="Email" value="" required placeholder="Enter a valid email address"> Then enter the following invalid string: "Testy McTest" <test@test.com> Please advise as to the result you get. Does it differ from CF2016 & CF2018. Yes. Why? Because email address valdiation should only validate the email address (username & domain) and not the "email address + display name" combination. Could you please compare what Adobe is doing with how this is done with C++, Java, PHP, MsSQL, Javascript, HTML5, etc. Here's the validator library that I use & trust with ColdFusion because of past validation issues. It's Dominic Sayers isEmail() library. (It's been ported to Java & I have simple proof of concept code if you need it.) If you go to https://isemail.info/ and attempt to test the string, it returns "Address is invalid for any purpose" and "Address contains text after a comment or Folding White Space". https://isemail.info/%22Testy%20McTest%22%20%3Ctest%40test.com%3E Please update the status back to "definitely a bug" or provide an in-depth explanation regarding how all other email validation is wrong and Adobe's is the only one that is suddenly correct.

Comment by James M.

I've attached a screenshot. I attempted to change my Adobe "Primary Email" and the system (unlike CF2016) reported that it's not a valid email address. But according to isvalid("email"), that entry is valid. Please return status to "bug" and fix this... or internally contact and convince all other Adobe licensed products & services to allow both "display name + email address" as valid email addresses so that everything is consistent.

Comment by James M.

Hi all, isValid("email", value) should follow RFC5322: https://tools.ietf.org/html/rfc5322#section-3.4 (i.e. Suchika is correct) isValid("htmlemail", value) should follow HTML spec: https://html.spec.whatwg.org/#valid-e-mail-address (i.e. James and Justin also have valid use-case expectations) Suchika, do you see what I mean? Anyone want to log an ER? I'll vote it up. Thanks!, -Aaron

Comment by Aaron N.

+1 for isValid("htmlemail", value) to follow HTML spec.

Vote by Aaron N.

It's not just HTML that considers an email and the display name as separate entities. Even though RFC5322 may include "display name" in the validation, no other generic validation that calls itself "email" functions like that. Perhaps the new change should be "EmailRFC" so that past integrations can continue functioning the way that they have prior to CF11. I've read the documentation and there's no mention of any change in behavior regarding "email" validation to include "display name". This new validation rule seems like a potentitally breaking change to me. If ColdFusion developer's blindly accept whatever string validates as a CF11+ "email", add it to a database and then attempt to use that value with another system, database or API (ie, like SparkPost, MailChimp, Amazon SES), those systems will reject the the "RFC Email" address if it contains the display name.

Comment by James M.

RFC5322 defines many things not just email addresses, so pointing out the RFC where this validation came from as some sort of appeal to authority feels a little disingenuous (the RFC defines the entire email format!). That being said, if you really feel like keeping email validation broken and introducing another validation scheme for actual email addresses, you could consider calling it "emailaddr" or "addr-spec" using the terminology introduced in RFC5322 3.4.1 which seems to make the distinction between an email address + display name and comments, versus the email address proper (the addr-spec). This distinction is also made in the introduction on the Wikipedia page for email addresses https://en.wikipedia.org/wiki/Email_address .

Comment by Justin L.

Hi all, The CF11 Beta fix, which I helped test, and which introduced the current behavior, is: https://tracker.adobe.com/#/view/CF-3231157 Please see Anuj's comment (i.e. "Adobe D.", since commenters' names didn't carry over in one of the bug tracker migrations). At minimum, isValid("email", value) and <cfmail> need to be consistent w/ the RFC. Otherwise that creates conflict when isValid("email", value) allows an address that <cfmail> can't handle, or vice-versa. Thanks!, -Aaron

Comment by Aaron N.

Many third-party tools that I use have separate entry fields for DisplayName & Email. Outlook has two fields. If I enter a CF11 valid email address in Outlook as my email address, it's wrong. Perhaps CFMail should be updated to allow two separate fields... one for "displayname" and one for "email". IsValid("email") is not useful as a result. The built-in CFMail function's "To" & "BCC" paramters both currently accept a list of email addresses, but a list of comma-delimited email addresses (plural) doesn't constitute a valid RFC email address (singular). By using CFMail as the reason to validate it, then "test@test.com,test2@test.com" is a valid email address and isValid("email") should be extended to validate a list of email addresses as a valid email address. Adobe D's comment (on CF-3231157) doesn't directly test a "display name + email address" as a single entry. I'm "External U" on that bug report and I recommended comparing behavior with the isEmail() PHP/Java library. I did my homework 2 years ago and published it here (using CF10): https://gamesover2600.tumblr.com/post/152034073124/clientserver-side-email-validation-compared I should update this now that the CF11+ rules have changed. Isn't the authority for a valid mailbox address "RFC 5321 Simple Mail Transfer Protocol" (at least according to Dominic Sayers): https://tools.ietf.org/html/rfc5321 Regarding "valid" email addresses, I created a wildcard email domain that would receive all email and attempted to send email to it. Our mail server wouldn't accept or route many of the "valid" email addresses... so even if CF determines something is "valid", it may not still be useable. No one benefits from a non-routeable, yet valid, email address. ColdFusion 11+ is still the lone technology that I've found that concludes that ["Testy McTest" <test@test.com>] is a valid email address. I ran CF2016's isValid("email") against my unit tests from 2 years and it still fails 62 tests. Here's a list of valid & invalid tests to try: https://fightingforalostcause.net/content/misc/2006/compare-email-regex.php You'll immediately notice that none of the listed test cases try passing "display name + email + brackets" off as an email to test... probably because it seemed to obvious that it should validate as an email. If this validation is to remain, please please please make it an option and rename it to something like "cfemail" or "rfcemail" so that the default behavior is consistent with every other third-party's email validation service, feature & logic.

Comment by James M.

Has the maximum length of an valid email changed? 254 characters is still the the current max length, right? RFC 3696 (from 2004) "In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. However, there is a restriction in RFC 2821 on the length of an address in MAIL and RCPT commands of 254 characters. Since addresses that do not fit in those fields are not normally useful, the upper limit on address lengths should normally be considered to be 254." (NOTE: An extra 2 characters are allowed for optional brackets.) If I enter >254 characters into my internal UDF (which uses Java isEmail() library), I get a "ISEMAIL_RFC5322_LABEL_TOOLONG" error message, but CF10+ isValid("email") indicates that it's valid.

Comment by James M.

Hi James and Justin, Sorry for getting into RFCs. My main point is (IMO): CF's already-existing tag for sending email (<cfmail>) and CF's already-existing function for validating email addresses (isValid("email")) must validate email addresses consistently, b/c they are siblings in the same language (CF). So, if JavaMail (<cfmail>) is updated to adhere to a newer RFC governing the email address format, then isValid("email") would need updated likewise. As for validation that checks if an email address is in its canonical (i.e. "addr-spec") form, I believe that feature is *nearly* as important as isValid("email") owing its allegiance to <cfmail>. I hadn't realized (b/c, like you said, Anuj's comment didn't cover display names) that CF-3231157's fix changed behavior w.r.t. display names. And I agree that breaks a lot of long-existing CF code that expects email addresses to be in their canonical/addr-spec form. Hopefully Suchika, or someone at Adobe, will acknowledge the impact of this backward-compat issue and propose a fix. Possibly, isValid("canonicalemail")? Thanks!, -Aaron

Comment by Aaron N.

Hello , This comment is just to ensure that we have read all your comments .The team is evaluating your suggestions and we will get back to you. Thanks, Suchika.

Comment by Suchika S.

I was recently reviewing the jQuery library that I use for email validation. They recently changed what they were doing and added an important note that indicated they are now "using the same regular expression that the HTML5 specification suggests for browsers to use." Here's the link and basic reasoning behind their decision. If Adobe's validation & reasoning is different, please update the online documents so that all developers are aware that Adobe's email validation is performed much differently and that they may want to consider adding additional rules. A Valid E-mail Address https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address A valid e-mail address is a string that matches the email production of the following ABNF, the character set for which is Unicode. This ABNF implements the extensions described in RFC 1123. [ABNF] [RFC5322] [RFC1034] [RFC1123] This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here. The following JavaScript- and Perl-compatible regular expression is an implementation of the above definition. /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/ A valid e-mail address list is a set of comma-separated tokens, where each token is itself a valid e-mail address. To obtain the list of tokens from a valid e-mail address list, an implementation must split the string on commas.

Comment by James M.