In November 2016 we became aware that Adobe ColdFusion 2016 and earlier versions have issues with sending emails to IDN domains. Something that is possible for a very long time and becomes more and more common - at least in countries like Germany that have special chars. The CFMAIL errors with
The value of the attribute to, which is currently foo@bäüöß.com, is invalid.
coldfusion.tagext.InvalidTagAttributeException: Attribute validation error for tag CFMAIL. at coldfusion.tagext.net.MailTag.validate(MailTag.java:743) at coldfusion.tagext.net.MailTag.processAttributes(MailTag.java:846)
and compared to this failure the validation with
isValid('email', local.email) says the email address is valid.
The issue has been escalated to Adove CF team and than the nightmare started. They tried to implement a hotfix and failed and failed and failed and failed and so on. I have over 90 mails in my inbox only about this one issue. Typically they encoded the full email address including the @ sign and not only the domain name. Than after a few months of tries we have been told they like to wait for JavaMail project to release a newer final version with better IDN support. The code was already available in an RC release. Than on July 17, 2017 - JavaMail 1.6.0 was finaly released. I pinged them a few days later to move on. A month later someone started to work on it and another 20 days later it was marked as "to test". In September 2017 the case was set to closed, but we have not received a hotfix and pleased for a hotfix to verify the fix before it goes into an updater. The case was reopened. On 14. November I received another broken hotfix and in further hotfixes they failed again and again as before. We both have been confused by IDNA2003 and IDNA2008 on several suxxx online IDN converters that all have the same bugs and encode the full email address including the local part of an email. This is wrong - only the top level domain name (after the @ sign) need to be encoded. We also talked about SMTPUTF8 support as they also tried encoding the local part of an email address (that is the part before the @ sign). Once this was nailed out it was clear that CF was only doing IDNA2003 and they need to implement IDNA2008, too. IDNA2008 is the default in latest Postfix releases and in CF2016 now, too.
There are some upcomming changes and if you may need IDN support now and not later you need to ask CF support for the hotfix CF-4198082. This patch will introduce a new JVM argument named -Dcoldfusion.email.idn.version=2003 or -Dcoldfusion.email.idn.version=2008 that currently defaults to 2008.
Additionally there is a new attribute named idnaversion that has been added to the CFMAIL tag. I think it is not really useful to use it as the server admin is the only one who knows what the next SMTP gateway can handle, but as it exists now I document it and maybe you like developing crappy banana code.
<cfmail to="sample@foo.äöüß.de" from="test@äöüß.de" subject="hello" debug="true" idnaversion="2003">
Hello World !
</cfmail>
<cfmail to="sample@foo.äöüß.de" from="test@äöüß.de" subject="hello" debug="true" idnaversion="2008">
Hello World !
</cfmail>
History
- 01/05/2019: CF2018 includes the fix. CF2016 has the fix not included yet.
- 24/09/2018: Official fix may be available in CF2016 Updater 8 and later. Adobe has not added it to Updater 6 or Updater 7 as both seems to be security fixes only.
- 24/04/2018: Official fix should be available in CF2016 Updater 7 and later.
- 05/02/2018: Fixed hotfix with new default is IDNA2008.
- 30/01/2018: Found new bug in patch, multiple TO adresses are broken. Awaiting new hotfix.
- 23/01/2018: Received the first working hotfix. May be part of next updater.
- 25/11/2016: Opened case CF-4198082 with Adobe.