PS click here to get straight to the answer

There doesn’t seem to be any documentation on getting incoming emails into a Rails app running on Windows. I’ve tried every combination of search keywords I can think of, having just learnt a lesson on how they can determine your success in finding an elegant solution that someone put up recently. So if you know of a good guide somewhere else, please kindly post a comment.

The closest I found was this entry in the Ruby on Rails wiki. Virtually the entire page is about working with UNIXy MTAs and, to my surprise and horror, none of them has been satisfactorily ported over to Windows! There is a little section on “Receiving with ActionMailer on windows” but it involved manually saving the email in a file and sending the file to the Mailer as input, not the best thing to have our customers do!

Long story short, I eventually found two decent-looking free SMTP servers for Windows:

1. XMail - Open Source
2. MailEnable Standard Edition - Freeware

Champions of Open Source that we are, XMail just had to get first dibs. It turned out MailEnable’s scripting didn’t look very easy anyway.

So here’s how you receive email in a Rails app running in Windows:

First of all, install XMail using this forum post. The XMail Wizard step is only for setting the admin username/password, so if you cannot open the rar file that it comes in, just use xmcrypt to encrypt your admin password:

c:mailrootbinxmcrypt <password>

and write this in the ctrlaccounts.tab file:

"<username>"    "<xmcrypted password>"

BE SURE to use quotes around each token, a tab between the two, and a newline at the end of the line!!

Create a domain for your app in XMail Administrator, as per the instructions, and in this domain, add the accounts that correspond to your mailers, then for each of these accounts, uncheck the Store mail locally checkbox. Your screen should now look like this:

Now for each of these accounts, click into the Advanced tab and enter the following into the mailproc.tab settings:

"external","0","60","ruby","<RAILS_ROOT>/script/runner","-e","production","<YourMailer>.receive(File.read(ARGV[2][4..-1]).sub(/A.*?<<MAIL-DATA>>/im, '').lstrip)","$(FILE)"

substituting your own RAILS_ROOT and the mailer class that corresponds to the account. As you can see, there a little bit of massaging needed on both the file name and the email content that XMail provides.

Set the MX record for the domain to point to the XMail host and your hungry mailers will be fed!

Big thanks to Davide Libenzi for creating the amazing XMail, which combines SMTP, POP3, IMAP, Finger, an admin server for windows in one tight package, as well as to BooT on the XMail forum for the instructions that probably saved me days of suffering.

A few days ago I checked in an initial cut at multicurrency support for Coupa eProcurement. It’s based somewhat on Tobias Luetke’s Money gem, but with currency & exchange rate info pulled out into tables and amounts stored as floats for subcent pricing, among other changes. It’s available in SVN, of course, but it still needs more polishing and testing before it’ll make it into a release.

One of the main challenges in adding this support, and in extending the application in general, is to keep complexity optional and necessary maintenance to a bare minimum. Exchange rates are a good example of why this can be tricky, since they always need to be reasonably up-to-date, but companies get them from all sorts of different places and in different formats. The application integration side of the problem has even spawned aggregation & normalization businesses like Cloanto’s Currency System. While we shouldn’t rely on a particular commercial service for bringing in data, we also don’t want to leave the integration as an exercise for the implementor, as is done with many ERP implementations, so this is an area where I’d like to do more work. So far we have a CSV file loader that can import rates in the same way as all of our other loaders, but that’s not very interesting. I’ve also implemented (but not exposed) a SOAP callout to the Federal Reserve Bank of New York to automatically populate a number of rates, and that’s far more promising. Going forward I’d like to support a number of different web service-based rate sources, starting with the free/governmental ones, and let the admins configure what gets pulled in when, with the goal of enabling one-time setup and free data for all but the most demanding customers, with easy integration of commercial services for the rest. Ideas? Send ‘em to david at coupa.com.