CF9.01 CFMAIL not encrypting TLS

[webdev314027918]

Patched CF9.01 (save the judgement, it's what I have to support)

Java 1.7-80

Windows 2008 R2

IIS 7.5

SmarterMail 10.7

Server supports TLS 1.1, 1.2 and 1.3.

Typical settings for cfmail are: <cfmail from="#mailfrom#" to="#mailto#" server="mail.mydomain" useTLS="yes" port="2525" subject="Some Subject " type="html"> (Yes, Port 2525 is the TLS smtp port. )

Additionally, the server, use TLS and port are defined in CFAdministrator.

The Message-ID on the non-encrypted email lists a number, then .JavaMail.myservername@mail.mydomainname.  Is there some JavaMail setting that needs changed? Or a property that needs to enable TLS?

Problem I'm trying to solve is the red padlock in Gmail that states "x did not encrypt this message".  I only get this when I send through CFMail, but NOT when I use the Smartermail webmail interface (sends TLS1.1) or through any other smtp client, such as Outlook (sends TLS1.1).

How can I get the CF9 Application Server to encrypt what it sends so I can get rid of the red padlock?

[WolfShade]

I'm just guessing but I assume you probably need to update to a more recent version of Java.  I've heard a few problems similar to what you describe being fixed by updating Java.  Something to do with TLS 1.1, if I remember correctly.

HTH,

^ _ ^

[webdev314027918]

@WolfShade, I appreciate the response.  Unfortunately, Java 7 is the latest major version supported by CF9.01, and ver 80 is the latest available in the 7 JDK I could download and install yesterday (since that was the version in 2015 when Oracle stopped posting updates to the public for that version).

I suspect it has to do with a repeated mantra I'm seeing about Java 7 (in the earlier versions) disabling TLS1.1 and TLS1.2 by default, whereas in the latest version, 131b (that I do not have access to), both are enabled by default. I've added the argument to enable them in the jvm.config file for ColdFusion, but even ColdFusion Muse has written about how that argument is ignored by CF.

I'll keep searching and testing and post back when I find it.  In the meantime, thoughts from any and all.

Sadie

[Charlie Arehart]

Sadie, just because Java 8 is not supported by CF9 doesn’t mean you can’t use it.

It’s a 5 min job to enable it and see if that fixes it for you (and a 1 minute job to revert back to the old, original JVM), including CF restarts each time. If it DOES solve it, then you can contemplate the bigger picture concerns of updating to Java 8 on CF9 (whether any OTHER code may fail, whether you need to import certificates into the NEW jvm), and so on.

If you DO decide to try to do the update, there are a dozen things you can do wrong that would turn this 5 minute job into a nightmare, leaving you think you need to reinstall CF. It need not be that way. See my blog post:

http://www.carehart.org/blog/client/index.cfm/2014/12/11/help_I_updated_CFs_JVM_and_it_wont_start

/charlie

[Wilgeno1]

Charlie, 

Using Java 8 for ColdFusion 9.n.n does work, but I know that CFReport does not work in CF9.n.n on Java 8.  I'm not sure what other features may not be supported. It's always worth the try though.

Regards,

Wil

[webdev314027918]

Charlie, you're absolutely right, what could it hurt? And I have that link you cited bookmarked and I re-read it EVERY time I've updated JAVA for 3 years!

So...I downloaded and installed Java 8, but had to revert back to 7.80 as the newer version DID break a lot of other things.

Thanks for the idea; I'll keep searching.
Sadie

[Dave Watts]

If you're using Java 7, you might try adding this switch to your java.args in the JVM configuration screen in CF Administrator:

-Dhttps.protocols=TLSv1.1,TLSv1.2

Dave Watts, Fig Leaf Software

[webdev314027918]

Dave, thanks for that.  I forgot to put that in my initial post...I do have that exact argument in the jvm.config file, but without any effect.  (In an old post, https://goo.gl/HNuCkH on ColdFusion Muse, Mark Kruger had no luck with it either. )  That's an old link, but then this is old software.  Sigh.

Thank you again.

[BKBK]

Test, in turn. First, with the JVM setting

    -Dhttps.protocols=TLSv1.1

Restart ColdFusion. Test by sending mail.

If that fails, then repeat the process with

    -Dhttps.protocols=TLSv1.2

If that, too, fails then test with

    -Dhttps.protocols=TLSv1,TLSv1.1

and, if still necessary, with

    -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2

[webdev314027918]

BKBK,

Thanks for the suggestions. I  added each argument, in the sequence you suggested, to jvm.config, restarting the CF service after each add/save. (I usually edit jvm.config directly, but I DID log in to CF Administrator afterwards to make sure the arguments were showing there, and they were.  So I did edit the correct file.)

No joy yet.

I've looked at the headers in gmail for emails sent from the same address via the webmail interface and via Outlook.  Both were sent using TLS1.   I'm going to dig in the CF logs to see if I can see anything there.

Thank for your input and feedback. 

[webdev314027918]

If you're still following along...I added a "debug='true'" attribute to the cfmail tag and sent.  (The java.config file has the argument, -Dhttps.protocols=TLSv1,TLSv1.1

Following is the debug output after sending a cfmail test.  The private stuff is replaced with ALL CAPS descriptive text.

Please let me know if this is meaningful.

********************

DEBUG: setDebug: JavaMail version 1.4.2

DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]

DEBUG SMTP: useEhlo true, useAuth false

DEBUG SMTP: trying to connect to host "MYMAILSERVER", port 2525, isSSL false

220 MYMAILSERVER

DEBUG SMTP: connected to host "MYMAILSERVER", port: 2525

EHLO MYSERVERNAME

250-MYMAILSERVER Hello [IP OF MYMAILSERVER]

250-SIZE 31457280

250-AUTH LOGIN CRAM-MD5

250-STARTTLS

250 OK

DEBUG SMTP: Found extension "SIZE", arg "31457280"

DEBUG SMTP: Found extension "AUTH", arg "LOGIN CRAM-MD5"

DEBUG SMTP: Found extension "STARTTLS", arg ""

DEBUG SMTP: Found extension "OK", arg ""

STARTTLS

220 Start TLS negotiation

EHLO MYSERVERNAME

250-MYMAILSERVER Hello [IP OF MY MAILSERVER]

250-SIZE 31457280

250-AUTH LOGIN CRAM-MD5

250 OK

DEBUG SMTP: Found extension "SIZE", arg "31457280"

DEBUG SMTP: Found extension "AUTH", arg "LOGIN CRAM-MD5"

DEBUG SMTP: Found extension "OK", arg ""

DEBUG SMTP: use8bit false

MAIL FROM: SENDING ACCOUNT

250 OK <SENDINGACCOUNT> Sender ok

RCPT TO:<AN_ACCOUNT@gmail.com>

250 OK <AN_ACCOUNT@gmail.com> Recipient ok

DEBUG SMTP: Verified Addresses

DEBUG SMTP:   AN_ACCOUNT@gmail.com

DATA

354 Start mail input; end with <CRLF>.<CRLF>

Date: Sun, 25 Mar 2018 14:09:43 -0500 (CDT)

From: SENDING ACCOUNT

To: AN_ACCOUNT@gmail.com

Message-ID: <257940650.1.1522004983567.JavaMail.MYSERVERNAME$@MYMAILSERVER>

Subject: Debug Test

MIME-Version: 1.0

Content-Type: text/html; charset=UTF-8

Content-Transfer-Encoding: 7bit

X-Mailer: ColdFusion 9 Application Server

  <p>Testing wtih debugging on </p>

250 OK

QUIT

221 Service closing transmission channel

03/25 14:09:43 Information [scheduler-1] - Mail: 'Debug Test2' From:'SENDING ACCOUNT' To:'AN_ACCOUNT@gmail.com' was successfully sent using MYMAILSERVER

**********END************

[BKBK]

Oh, and ColdFusion 9.0.1 is definitely incompatible with Java 8. I arrived at this conclusion several years ago, after dozens of tests on a ColdFusion 9.0.1 installation. The installation was on Windows and had the latest hot fixes.

At the time, I researched the subject at length on the web. I could find no satisfactory account of anyone having successfully implemented ColdFusion 9.0.1 with Java 8.

[Wilgeno1]

I know for a fact ColdFusion 9.0.1 will run on Java 1.8. I also know that it may not be fully supported. I have found the CFREPORT in CF9.n.n does work on Java 1.8 

Regards,

Wil

[webdev314027918]

Thanks very much for all the input Wilgeno.

It looks like I have two things to try:

1. Set up a local mail relay between ColdFusion and the mail server. No, I hadn't thought of that and have never done it, but I think I can. After reading about it, I see how that could solve the problem.
2. Download Java 8 (again), add the Java7 ODBC bridge to it, point ColdFusion to Java 8, restart service and see what is broken.  I don't use CFREPORT but rely heavily on CFPDF, exporting reports to Excel, and I use the CFXHTTP5 tag to make secure cfhttp calls.

I'll report back, likely 24 hours from now, as I'll be working with this in the middle of the night.

Thanks again,

Sadie 

[Charlie Arehart]

I want to address a couple of recent comments in this thread, at once.

First, BKBK, you say "ColdFusion 9.0.1 is definitely incompatible with Java 8.", and you say you concluded that based on "dozens of tests" you ran back some years ago. Do you have any more info on what you found failed?

As Wil has reported here (in later posts after yours), he has found it to work for many, as have I. Again, I'm not saying it's "supported" by Adobe, but heck CF9 is no longer "supported" by Adobe at all. What matters, of course, is whether it "works" for one who feels they must try to run that way (more in a moment), or whether it causes any negative issues for one running CF9 (or even 8).

And Wil has reported one thing that he's seen didn't work (CFReport, though it's not clear what aspect of it didn't work, so it may be that it's not that it will never work for anyone on CF9 with Java 8).

And the OP reports here a concern over the ODBC-JDBC Bridge, which he refers to as being a Java 7 thing. I always thought that was enabled by a 3rd party product that CF embedded, but I could be wrong. If it's indeed based on the one that Java itself provided, I do see people referring to it as indeed being a that was removed in Java 8, but showing ways to try to get around that. Perhaps these are that the OP has found and is investigating: http://www.webtrenches.com/jdbc-odbc-bridge-on-lucee/​ and http://bigfatball.blogspot.it/2016/03/how-to-enable-jdbc-odbc-bridge-for-jdk-8.html.

Of course, all this is what some folks call "putting lipstick on a pig", because not only is CF9 no longer "supported" by Adobe but the bigger problem (it should seem) is that there have been no security updates to it in a few years. So continuing to run on it is unwise (as surely Will and others here have said elsewhere).

I know the OP opened the thread saying "save the judgement", but I think this bears clarifying as it's not about "judging" one a site that is so far behind but instead *warning* about it.

And while getting the JVM updated is a big step to improved security of the underlying platform, it's not one to rely on much. Not only is the CF underlying CF9 not as secure as it can be (if on CF11 or 2016 with latest available updates), but also 9 and earlier run on JRun which is itself EOL'ed. CF 10 and above run on Tomcat, and later updates of 11 and 2016 run on still later and more secure versions of Tomcat.

HTH.

[Dave Watts]

On the part about the JDBC-ODBC bridge:

Adobe provides this functionality using DataDirect SequeLink. But the JDBC side of this is going to have Java dependencies, and I would not be at all surprised if the version of SequeLink bundled with CF 9 doesn't work properly with Java 8. I'm actually kind of in the middle of working with a Java app that works ... differently in Java 7 and Java 8, and it's kind of a pain. There's also a Java-native JDBC-ODBC bridge in Java 7, sun.jdbc.odbc.JdbcOdbcDriver, which doesn't exist in Java 8. I'm not sure why you'd use that instead of SequeLink though. But you can actually just copy the relevant JAR from a Java 7 JDK apparently, if you really need it.

That said, for the OP: all this "I'm on some ancient version, save the judgment" stuff is kind of BS. If you weren't on an ancient version, you wouldn't be needing to ask how to make that old crap work. It costs you time, it costs everyone else time, it doesn't work reliably, etc. I reserve the right to judge that if people are going to ask questions on a public forum. You still have the right to ignore my judgment as always.

Dave Watts, Fig Leaf Software

[BKBK]

Hi Charlie, that was years ago and, sorry to say, I no longer work for the company. But I remember an important project we did. It involved adding a new Java 8 library to an enterprise application running on ColdFusion 9.0.1. That meant changing the Java version from 6 to 8.

We had a list of some 20 to 30 items to test (I don't remember exactly). As I recall, the ColdFusion Administrator, Excel and Web Services were among the components in which errors occurred.

@webdev314027918

Nevertheless, I have no reason to end on a negative note. If your CF9.0.1 application has no critical requirements, then you should have a go with Java 8. You have good reason to have high hopes. Java is largely backward-compatible.

[WolfShade]

I'm not disputing your assessment that Java is largely backward-compatible, but when we were running CF9.0.1 and the Java 1.7u31 was released, it broke our SOLR collections if Security Sandbox was turned on.  When CF10 came out with Java 1.8, the SOLR collections started working, again, so I can't say if the issue was purely Java 1.7u31, or if it was a combination of that and something in CF9.0.1, but I was in a panic for two weeks trying to figure out how we were going to comply with gov't need to be secure and keeping the SOLR collections working.

I guess my point is - every environment is different, and it seems like Java spans a wide range of working / broken scenarios, depending upon said environment.

Either way, I'm just glad that our SOLR collections are working, again. 

V/r,

^ _ ^

[Wilgeno1]

Yes, it's an old article, but still valid. I'm the one that did the testing and wrote that article. It wasn't until ColdFusion 10 Update 18 and ColdFusion 11 that those JVM switches would work.

Have you tried using a local mail relay to take the email from ColdFusion and then having that relay to the actual mail server?

Regards,

Wil

[Charlie Arehart]

Thanks for the kind regards. As for the "lot of other things" that broke, I honestly have not seen that happen. What sort of things? There may be an explanation that is NOT quite what it seems

[webdev314027918]

Charlie, the main "thing" is this server has some sites that need to use the ODBC-JDBC bridge. Again, this is what I have to support 😞 , please don't shoot the messenger.

I've read the ODBC-JDBC bridge can be copied from Java 7 to 8 but didn't try that on Friday.

Have you seen instances where CF9.01 and Java8 work together? And in case it matters, several of the sites rely heavily on cfpdf and related tags.