One of the nifty conveniences of ColdFusion is its built-in ability to communicate with other systems in a variety of Internet protocols, inclusing mail protocols like POP and SMTP. In general, setting up ColdFusion to work with a mail server is a simple affair:

1. Log into the ColdFusion Administrator.
2. Click the Mail entry under Server Settings.
3. Fill out the form with the name or IP address of your mail server.
4. Change the SMTP port, if appropriate.
5. Click Submit.

For years, setting up a mail server in CF worked pretty much like this. More recently, though, mail servers have started to widely adopt encryption technology, reverse DNS checking, and other measures designed to enhance security and combat spam. This change of affairs has forced companires like Adobe to add features to their products to support these new technologies. In the case of mail connections with ColdFusion, the current solution works but is not always easy to implement.

At Emergent Path, we recently added a publicly signed SSL certificate to our mail server to enable encryption for all mail traffic. Immediatley, we noticed that our corporate web site (and yes, this blog) could not send email out because the ColdFusion server could not talk to the mail server.

After some research and a quick check around the CF/Java blogsphere,I got an opinion from Jeff Smallwood that I should try importing the mail server cert into ColdFusion to see if that would resolve the issue. Importing a cert into the keystore in ColdFusion's JVM isn't that dificult, but it is the sort of exacting task that is easy to get wrong, especially if you have not done it before. For a couple of threads on that topic, check Terry Ryan's blog entry on importing certs with the keytool.

I imported the cert and restarted ColdFusion, but the system would still not connect to our mail server. Hmm. 

Next, I dropped to the command line on the CF server to try and debug the connection to the mail server that way.

telnet mailserver.emergentpath.com 25
Service not available (-37) 
connection closed by foreign host

A search for the error condition along with the name of our mail server (XMail), yielded this thread about DNS checking on the XMail Forum. Ah, now I was getting somewhere. The mail server is set up to run reverse DNS checks on all peers, and it couldn't verify the identity of the CF server, so it would not accept the connection. A quick trip to the console of the internal DNS server to add the internal IP address mapping of the server to its hostname fixed that problem, and I was ready to test again, but I still got an error. 

A little further searching about ColdFusion and TLS mail settings led me to a blog post from TACFUG about connecting to GMail from ColdFusion. I copied the settings, changed the appropriate bits for my server, and the system were finally able to communicate.

The lesson to take away from our experience is how many variables there are now in connecting to a mail server. If you are trying to connect to a simlarly locked down mail server from your CF server, remember all the security measures mail administrators put in place to block bad traffic, and account for all the possible sources of connection failures.I would also recommend a conversation ahead of time with your mail server administrator and internal DNS administrator. Researching the issues ahead of time could save you a whole lot of trouble later on.

UPDATE: Jared Rypa-Hauer brought to my attention an add-on tool for CF Admin that enables you to work with the CF keystore in the Admin rather than on the command line.  The tool is an open source project on RIAForge called CertMan.

There is a new bout of SQL injection attacks making the rounds on the Internet right now, and some of these attacks are specifically targeted at sites running on ColdFusion. Check out a post from Ben Forta on the latest SQL injection attacks for more background.

What can you do to protect yourself? The best thing you can do is secure all of the variables in your database queries inside CF with the <cfqueryparam> tag. Using <cfqueryparam> will shut the door on random SQL strings being injected into your applications.

Emergent Path is growing! We have added two new team members in the last couple of months and I wanted to give them a warm welcome.

 Babak Parvizi comes to us after a year at RIA consulting standouts Cynergy Systems, and several years as a bioinformatics software developer at biotech firm Invitrogen. Babak has a background in biotech sciences and has also spent several years doing software development with Perl, Java, Flash, and Flex. Babak joins Emergent Path as a Senior Software Consultant to lead our RIA consulting and product development efforts.

Abraham Mathew comes to Emergent Path after seven years of experience in the entertainment industry, where he built DVD games and did DVD authoring for high-profile media clients like Fox, WHV, BBC, SnapTV, Lions Gate, NewLine, and Disney. He also has prior consulting experience with Java, Oracle, and PowerBuilder. Abraham joins Emergent Path as a Software Developer, building Flex, Java, and ColdFusion applications. 

Welcome to Babak and Abraham.

I gave two presentations at Webmaniacs- Flexbuilder/Eclipse Secrets and Tips, and Understanding AIR Security. You can download the presentations from the links. I especially enjoyed giving the Secrets and Tips, because it talks about patterns in software development, from a practical standpoint of our work patterns as developers and offering ways to  improve the experience of working with FB/Eclipse.

One of the things I really enjoyed about Webmaniacs was the high quality of attendees across the board. I met a tremendous number of smart people doing interesting things in the software industry from all across the US and several other countries. I also really enjoyed the more intimate feel of the conference due to its limited size. Don't get me wrong, I love going to Adobe MAX, but the size of the conference has become a hindrance to deeper interactions with people in the community, and I felt Webmaniacs struck just the right balance- located in a more intimate, everyday space than a typical large conference at a convention center.

I admit it, I haven't used CF 8's AJAX tags in any applications to speak of yet, and I haven't really even looked closely at CF 8 AJAX capabilities. Fortunately, I was able to catch Adam Lehman's talk this morning on building applications using ColdFusion's built-in AJAX tags and libraries. Adam demonstrated some very cool uses of AJAX, including a sample master-detail editing function using cfwindow. You can get the demos from Adam's blog. 

Yesterday, Foundstone security consultant Dean Saxe gave a great talk on web application security. Dean covered well-known security vulnerabilities like SQL injection and XSS attacks, and he covered less well-known issues like man-in-the-middle SSL certificate attacks that could expose users to hacks on a seemingly secure site.

Software developers need to know about these issues so they can learn to build applications with a focus on security. Business users need to know about these issues so they can understand potential threats to their businesses.

Security is a set of trade-offs based on risk level and risk tolerance, and everyone concerned should understand the risks in their applications.

I'm at the Webmaniacs conference in Washington, DC today. This morning, Ben Forta gave the keynote address on ColdFusion 8, but he also gave the crowd a preview of a couple of things in store for the future of ColdFusion- a public bug tracker and a public enhancements request system complete with voting for feature requests. This is great IT governance practice and I am very glad to see Adobe adopting this model for ColdFusion, as they have with Flex already.

Lately at Emergent Path we have been building applications using ColdFusion on the server side and Flex on the front end to create very compelling Rich Internet Apps. I have settled on a standard set of technologies and frameworks that provide a standard way of building web apps, and I wanted to share my thoughts.  I am hardly alone in the direction I am moving. Anecdotally, several people I know have been building applications in a simliar way, and blogs and mailing lists are starting to fill with technical questions around various parts of the solution.

On the client, we use Flex with the Cairngorm framework to build well-organized, maintainable code. Cairngorm has a reputation as being a little heavy, and we have experimented with variaous cusotmizations and simplications of the framework. There are other Flex frameworks out there, but Cairngorm at the moment is the most widely used, so that is our current standard. Flex handles the View and Controller aspects of the application.

On the server, we use ColdFusion 8 (and that's important, upgrade your server!) with Coldspring to handle the Model. Coldspring is robust and scalable and is rapidly becoming my favorite ColdFusion framework. It only handles the model, and it is a complimentary technology to Fusebox, Mach-II, Model-Glue, Coldbox, and in this case, Flex. 

Coldspring supports the Transfer and Reactor ORM frameworks, but to date we have not used them in any development projects. We tend to customize the model code, and ORM for us has no clear advantage over other code generators. We have been using the Illudium Pu-36 Code Generator for our base model generation. It is a fairly limited tool, supporting only 1:1 table-entity mapping, but it is very easy to use and allows for customization of the code templates to suit your own architectural style.

Under this paradigm, our ColdFusion apps end up with an Application.cfc and index.cfm in the root, the coldspring folder, a model folder, a services folder (for remote service proxies), and that's it. The Coldspring.xml config file, and any other folders (such as upload/download directories, db scripts) can be held outside the webroot and accessed through the local file system. Images and CSS elements are held in the Flex source folder and deployed at compile-time to the proper location.

This paradigm offers simplicity, rapid development, scalability, and good code organization for long-term maintainability. I've been thinking about making an acronym for it, but I haven't come up with anything yet. 

I have had several r eaders ask me for a copy of the compiled 64-bit Java Service Wrapper for Windows x86-64, so I am including a link to it. If you plan to download and use this code, please be warned, I did not compile the code, it was sent to me by a guy named Sandeep whose info I found on the Java Service Wrapper mailing list. Having said that, I have used his compile of the wrapper and it seems to work fine. It comes with no warranty and no guarantees that it will work for you. If you want it, here is the link:

64-bit Java Service Wrapper for Windows x86-64

If you need help with configuration, take a look at the Java Service Wrapper web site.

Digging further on my Java heap issue, I decided to try to figure out what was causing these objects to remain in memory during the life of the request. I modified my code so that all the beans were instantiated in the request scope. I still maintained a function in the main cfm template to set properties of the object in the XML document, and this function accepted an object as an argument. I thought this might have some effect on the ability of CF to garbage collect the objects, but I decided to see what would happen anyway. My test showed a clear trend toward a larger heap size when indexing 10,000 documents, although the heap in this test maxed out at 158 MB and seemed to have some ability to clear memory along the way.

Next, I modified the inline function so that it used the object bean in the request scope rather than accepting a bean as an argument. Under this scenario, the beans would all be instantiated in the request scope and used in the request scope, all within a single cfm page. Would that be enough to allow gc to remove the objects from memory? Under this scenario, the heap maxed out at 140 MB, a bit lower than previously, but perhaps not significant.

After that, I modified the XML routines so that the XML documents were also created and used in the request scope and never passed from one place to another. At this point, I was now using component, but not passing any complex datatypes from place to place, instead simply referencing them in the request scope. This time around, the heap peaked at 137 MB. Moving from unscoped to request scoped variables and eliminating passing complex objects between components seems to have had a limited impact on the amount of memory used in the heap during the indexing process.

As an aide, in these later cases, I made it a point to click the Run GC button in the CF Server Monitor right after the request finished executing. In all cases, the heap dropped off to roughly 20 MB. That means that these requests used anywhere from 40 to 180 MB of memory in the heap to process the same data against the same indexing engine.

It would seem that the use of components as beans to hold data creates a serious potential performance problem for CF-based apps in cases where those beans are persisted (e.g. in the application or session scope) or where many beans are instantiated in a single, long-running request. I don't see any problem using beans in other scenarios, e.g. using beans to store a small number of records returned from the database, or using a bean to model a form in an HTML or Flex front end. I would be cautious, though, of using a large number of beans in a request or persisting beans in the session scope where they may not be garbage collected.

Potential Solutions

Adobe needs to figure out a way for garbage collection of components to be handled more efficiently. In my case, the objects sitting in memory have no further value after being used once in a loop, and they should be subject to garbage collection. My suggestion would be to implement NULLs for variables in CF, perhaps using javacast notation to allow developers to specifically mark objects for deletion.

I gave this technique a shot in my last code iteration, assigning the bean variable to javacast("null",""). (The CF docs specifically warn against  doing this, saying that unpredictable results will occur). My test demonstrated that, rather than eliminating the beans from the heap, the use of this function caused the heap to skyrocket to over 140 MB within the first 2,000 documents.

My suggestion is for Adobe to implement NULLs and allow developers to explicitly mark objects for deletion. Anyone else have a suggestion? Let's hear it. This is an issue that needs to be resolved.