Setting Up a Fake SMTP Server

I finally got around to setting up a simple “fake” SMTP server on a development system, making it simple and to develop and test email generation logic in Web applications.

On my team’s various development boxes (which are almost always laptops and therefore not always connected to our corporate intranet and sometime not on any network), we have typically configured our ColdFusion and Railo application servers to use our internal mail servers. Many of our Web applications send user-composed, automated, or process-based email messages, in addition to security-related event notifications. We’ve been bitten a couple of times in developing this mail-related logic, with messages being generated and sent to real system users from our development servers which, as you can imagine, has significant potential for generating concern and/or confusion on the users’ part. This hasn’t happened recently, in part because we are collectively more careful and in part based on our approach to how email gets addressed depending on whether the app is running on a development, testing, or production server.

I’ve long believed that a safer approach would be to configure our non-production servers to use something other than a “real” mail server. I’m in the process of standing up a new development system for myself, and decided I was going to poke at this a bit. For this first foray, I wanted something

  • simple to set up, configure, start, and stop
  • free
  • preferably available cross-platform (my team develops on Mac OS, Linux, and Windows systems based on developer preference for platform)
  • completely local (because of the need to be able to run without being on a network)

A solution would need to support SMTP, as both the ColdFusion and Railo application servers are configured to talk to an SMTP server. Anything beyond that set of basic requirements would be a bonus.

After a bit of looking, I decided to use FakeSMTP. It ticks all of the above boxes, and is implemented as a single Java JAR compatible with Java 1.6 and above. It has a simple UI for watching activity and  “outbound” mail handed to it, and can easily be configured to store transmitted mail messages to disk as .eml files for review (making developing email-related content fairly straightforward).

I use a bash shell script to start and stop my Tomcat instances for ColdFusion and Railo, so I added logic to that script to optionally start and stop my local mail server, as follows (wrapped here only for presentation):

# Start our fake SMTP server:
if [ "${3}" = "mail" ]; then
  java -jar ~/opt/fakesmtp/fakesmtp-1.13.jar -s -b -p 2525 \
    -o ~/opt/fakesmtp/out/ -a \
    >> ~/opt/fakesmtp/logs/fakesmtp-`date +%Y%m%d`.log &


# Stop our fake SMTP server:
if [ "${3}" = "mail" ]; then
  kill `ps -a > /tmp/ps.out && grep -i fakesmtp /tmp/ps.out | \
    cut -f 2 -d ' ' -`

The start logic runs the mail server in the background (as I really don’t intend to use the UI), listening on address and port 2525 (to avoid needing to run with elevated privileges on the default SMTP port of 25). It dumps mail messages to a folder for review, and logging server activity to a log file with a date-based name. The stop logic finds the mail server process and kills it.

I’ve tested it with both ColdFusion and Railo application servers, and it works. I will probably add some shutdown-related logic to do a bit of cleanup to make sure neither the log files or the saved email files get out of control.

Final thought: If it weren’t for my desire to be able to run completely standalone at times where I either do not have access to or do not want to use a network connection, I probably would have gone with something like Debug Mail. I have not used it, but it looks excellent. Given Railo’s ability to configure multiple mail servers, I may still play with it a bit as part of my solution.

New Dev Boxes

It is time: I’m standing up a couple of new development systems, so I am using Tomcat 8 and Java 8 as the basis for deploying Railo and Adobe ColdFusion 10. It started as smooth sailing, but I ended up dropping back to Tomcat 7 and Java 8.

It is time: I’m standing up a couple of new development systems, so I am going to use Tomcat 8 and Java 8 as the basis for deploying Railo and Adobe ColdFusion 10 on them. This is the first time I’ve done anything with either Tomcat 8 or Java 8 as the base for the application server stack but with Java 7 set for EOL this (I first wrote “next”) year, the timing for moving seemed appropriate.

I have Railo deployed and running without issue on the first of the two systems, and have encountered no issues at all to this point.

I will blog a bit in the near future to describe my approach and a couple of minor Tomcat differences I have found.

Updated 2014-01-02: Well, that didn’t take long to go sideways… I spent several hours this afternoon trying to deploy ColdFusion 10 on Tomcat 8, and so far have been unsuccessful. I can get the WAR to unpack, but the application simply refuses to start with a very non-specific error in the Catalina log file that (I’m guessing here) appears to indicate an incompatibility with Tomcat 8 in ColdFusion 10. More to come, but my next run at this will probably be to drop back a step or two and try deploying on Tomcat 7 and Java 8.

Updated 2014-01-03: Moving forward again. As of this morning, I now have both Railo 4 and ColdFusion 10 deployed against Tomcat 7 and Java 8.

Komodo-CFML: A quick status update (2014-11)

It’s been a bit since I’ve said anything here about Komodo-CFML, and thought a quick update would be appropriate. I’ve finally been able to get support for Komodo v9 (currently in early alpha) to work, and can now move on to a couple other items that will go into a 0.2.4 release late this month.

It’s been a bit since I’ve said anything here about Komodo-CFML, and thought a quick update would be appropriate.

As of last weekend, I finally was able to get a version of Komodo-CFML to work successfully on the version 9 alpha builds of Komodo IDE ActiveState has made available beginning earlier this year. I had hoped this not be a big deal, but it ended up taking quite a bit more time and effort than I had hoped. In the end, I resorted to rebuilding the plumbing for the language extension from the ground up in order to get it to work. So, that’s done (and I am currently using v9 with Komodo-CFML as my primary CFML editor on a daily basis).

With that hurdle out of the way, my intent is to get back to implementing tag/attribute support for both Adobe ColdFusion 11 and Railo 4.2. I’m also including a handful of useful (to me, anyway) macros with the language extension. I’ve made a small handful of minor tweaks to the language syntax highlighting, most of which are in the handling of CFSCRIPT syntax as I use it more and more rather than tag-based coding.

I’m hoping to have a version 0.2.4 with all of this available by the late November timeframe, shooting for something around Thanksgiving. If you are using Komodo-CFML and want to use it with the early versions of Komodo IDE v9, let me know in the comments below and I will send you my current working version with v9 support.

OS X Yosemite: First thoughts

I upgraded my MBP to OS X Yosemite on Friday morning, and at this point am closed to being finished with getting software installed, etc. As I have worked through getting software installed and getting the system ready to use, I’ve developed a few initial impressions of the changes to the user interface.

I upgraded my MBP (a 15-inch, early 2011 model) to OS X Yosemite on Friday morning, and at this point I am closed to being finished with getting software installed, etc. I typically move between versions of OS X with a clean install and then re-install software and restore files (as needed). It’s not necessarily an approach that would work well for everyone, but it works for me and helps ensure I have a reasonable clean system.

My first thoughts, in no particular order:

  • Helvetica Neue as the primary UI font is going to take some getting used to. My MBP is a couple years old, and is not a Retina device; that has a big impact on how it renders. I particularly notice the difference in the menu bar and in context menus. It simply does not render as clearly and legibly as the font OS X has historically used there.
  • The flat UI will also take some getting used to, but I think I like it, in general, for window decorations, UI controls, icons, etc.
  • I am not crazy about the shift to brighter colors for UI elements and icons. I would characterize many of them as close to garish. I tend to like understated UIs (the theme of my blog will attest to that) and while the flat aspects of the UI head in that direction, the colors most certainly do not. The blue used for UI elements, folder icons, etc., is particularly bad in this regard. The second UI tweak I made was the shift to graphite for basic UI appearance (which unfortunately does nothing for the blue folder icons); the first was to shift the dock to the right side of the display and to have it auto-hide to slide the mass of bright colors out of sight. I hardly ever use the dock (thank you, apps like QuickSilver and Alfred!), so this is something I would do anyway, but I don’t miss the explosion of bright colors from the dock.
  • Transparency and effects: I haven’t decided about these, but in general they feel like a bit much to me. What benefit, for example, is there to having the blue of several selected files in a Finder pane bleed through the context menu when I right-click on them? There are places where I like a bit of window transparency but some of the transparency implemented here feels gratuitous.

My overall general impression: a mixed bag. This is the first OS X version I’ve installed (going back to when I started with OS X Leopard) where I have not had an overwhelmingly positive reaction to the UI evolution.

I’ll follow up a bit after I’ve been on Yosemite for a couple weeks with additional impressions. I’m curious to see how/if these impressions evolve with the passage to time and usage. The other aspect of this is that the system I updated is my own laptop; I have two other MBP’s I use for work and I don’t have any near-term plans to update them… I will be switching between 10.10 and 10.9 on a daily basis, which will likely bring the differences into sharp contrast.