tracker issue : CF-4204100

select a category, or use search below
(searches all categories and all time range)
Title:

isValid("email") shouldn't ignore a "display name"

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/NotABug

Reporter/Name(from Bugbase): James M. / ()

Created: 03/15/2019

Components: Language, Functions

Versions: 2016

Failure Type: Incorrectly functioning

Found In Build/Fixed In Build: CF 11, 2016 & 2018... /

Priority/Frequency: Normal / Most users will encounter

Locale/System: English / Win 2016

Vote Count: 5

Problem Description:
An email address consists of a “local-part, an @ symbol, then a case-insensitive domain... at least this is how it worked all the way up until ColdFusion 11 when an additional "display name" started being allowed.

Steps to Reproduce:
<CFSET TestEmail = '"Testy McTest" <test@test.com>'>
<CFDUMP VAR="#isValid('email', TestEmail)#">

Actual Result:
YES

Expected Result:
NO

Any Workarounds:
Write your own UDF and check for quotes, brackets or spaces. It's not perfect, but better than validating the entire "display name" + "email" as an valid email address and then passing it to third-party validation and having it fail.
<cfscript>
function isEmail(inputString)
	if (refind("\<|\>|""|#Chr(32)#", arguments.inputString){
		return false;
	}
	return isValid("email", arguments.inputString);
}
</cfscript>

Attachments:

Comments:

{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.
30711 | May 10, 2019 06:46:54 AM GMT
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.
30712 | May 10, 2019 01:19:23 PM GMT
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.
30717 | May 13, 2019 01:50:10 PM GMT
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.
30718 | May 13, 2019 03:04:52 PM GMT
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.
30721 | May 14, 2019 10:00:31 AM GMT
+1 for isValid("htmlemail", value) to follow HTML spec.
Vote by Aaron N.
30722 | May 14, 2019 10:04:21 AM GMT
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.
30730 | May 14, 2019 01:31:13 PM GMT
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.
30731 | May 14, 2019 02:57:16 PM GMT
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.
30732 | May 14, 2019 07:02:21 PM GMT
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.
30733 | May 14, 2019 08:09:25 PM GMT
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.
30734 | May 14, 2019 08:21:40 PM GMT
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.
30737 | May 15, 2019 08:35:39 AM GMT
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.
30763 | May 17, 2019 07:26:21 AM GMT