A SPAMMER is using my cgiemail, what do I do?

Cgiemail is a program developed by folks over at MIT. It's a CGI, or server-side program designed to accept input from an HTML form, process that input against a template, and send the results as email. Recently, a vulnerability has been discovered that allows spammers to use cgiemail to send mail "through" the system on which cgiemail resides. This results in increase, sometimes overwhelming, system load, as well as the potential for spam to be sent in your name.

More details on the specifics of cgiemail's vulnerability can be found here, on SecurityFocus.com.

Step one is easy: disable the existing cgiemail on your system. Move it out of your cgi-bin directory or it's equivalent, or take away it's execute status. Forms using it will now no longer work.

There is no official, or at least timely, support from MIT for cgiemail. However various folks have patched or fixed the exploit individually. One example for those that have the source code (it's part of the distribution available at MIT) is provided here.

Aside from replacing cgiemail with a patched or updated version, the only real alternative is to find or build ... an alternative. One of the more popular is called FormMail.

I wanted something that was a little closer to a plug-in replacement for cgiemail, to minimize changes to either the forms that use it, or the templates used. I wrote tmail.pl, which while not quite as full featured as cgiemail, tackles common cgiemail-like templates with more of an eye to security.

The major differences that tmail.pl introduces are:

• Template parameters are required by default. Unless explicitly stated otherwise, it generates an error if a parameter is used in a template but not present in the form's input.
• A new type of parameter has been created: "email". When a template indicates that a parameter is of type email, some rudimentary checks are made to ensure that the entered data is, in fact, somewhat like a valid email address.
• Additional restrictions can be placed on a parameter. Specifically the value can be scanned for newlines (the source of the current exploit). If one is found, an error results.

In addition, tmail.pl is a Perl script, and takes an additional form parameter which is the name of the template. The template is typically found relative to the location of the Perl script, so they can be moved to the cgibin directory where they are not directly readable by site visitors.

tmail.pl can be downloaded here.

Why can't I open attachments in Outlook?

Recent versions of both Outlook and Outlook Express have been changed to prevent access to attachments by default. You need to take some additional steps to allow you to access those attachments again.

Microsoft has the perception of designing many of its products with lax security, the most common example being that default settings impose little or no safety restrictions. As security issues have become more of a focus, Microsoft has slowly been making changes to make applications more secure by default. The Outlook's are two examples.

Remember that Outlook and Outlook Express are two different programs. Because of this, what's needed to get access to your attachments is dramatically different, depending on which you are using.

Outlook Express users have it easy. In the Tools menu, select Options, and then in the Options dialog, select the Security tab. In that dialog will be a checkbox labeled "Do not allow attachments to be saved or opened that could potentially be a virus". It is checked by default. Uncheck it to regain access to your attachments.

Outlook 2002 users have a bit more of a challenge. Warning: getting Outlook 2002 to open potentially unsafe attachments requires editing the registry. As always, backup the registry before you do so.

Microsoft's knowledgebase article that deals with this issue in detail can be found here. Among other information, it details the specific registry keys that need to be added and/or modified to allow access to specific types of attachments.

Personally, I find it somewhat interesting that they suggest having the sender of the attachment resend it under a different name, before they present modifying the registry as an option. I'll also admit that if you're at all squeamish about playing in the Windows registry, that's my recommendation also.

How do I move my Moveable Text web log?

I asked myself this question earlier this week. Ask Leo! and Puget Sound Software both moved from one server to another, and moving the blogs had me worried. But it turned out that moving Moveable Type (MT) was one of the easier steps.

Ask Leo! had been housed on an Windows 2000 server running IIS, as a branch off of the Puget Sound Software web site. It's new home is a Linux box running the Apache web server. And not only was I moving both sites and their blogs, but at the same time I moved Ask Leo! into its own, separate, top level domain.

Step one was easy: install Moveable Type on the new Linux box. (Those instructions are here, by the way.) The next steps were to transfer my custom templates and graphics. That involved both hand-copying the images and an additional style-sheet, as well as updating the templates via the MT interface. Since I was also changing the directory layout and web log home page somewhat, I spent some time tweaking and correcting at this point until I had a proper looking, but empty, blog.

The next question was how to move the content of the blog. Ask Leo! has a bunch of content I wanted to make sure to preserve. It turns out that MT has a reasonably functional export / import ability. By "reasonably functional" I mean that while it may not have a pretty UI, and includes some hard coded directory locations - get past that and it just works. Even though as we'll see in a moment I could have left it alone, because the directory structure was also changing I decided to clean up the links within the blog entries to reflect the new layout. Once done with that I had a functioning blog with all my old content at my new location.

That left one last remaining question. Since the site's gotten some publicity over the past couple of months, people have naturally taken bookmarks to the site or to blog entries of particular interest. With the move, I wanted to keep those working as much as possible.

In the blog's old home, http://pugetsoundsoftware.com/askleo-blog, and in places that used to redirect there, I simply placed a redirection to the new home at http://ask-leo.com.

Preserving links to individual pages, however, proved a little more of a challenge. Enter URL re-writing. I've written before about the availability of URL rewriting on IIS. The new host is Apache based, and thus supports URL rewriting it natively. Old URLs of the form:

http://pugetsoundsoftware.com/s/archives/000013.html

are now transparently transformed into their true location:

http://ask-leo.com/archives/000013.html

The most important of these might well be the RSS feed for the blog. What used to be http://pugetsoundsoftware.com/askleo-blog/index.rdf is now transparently transformed into http://ask-leo.com/index.rdf the feed's correct location. Details of Apache's URL rewriting can be found here.

Each step a bit of a learning experience, but the results are worth it. Both of the Ask Leo! and Puget Sound Software websites have a fatter internet connection, a lot of space to grow, and hopefully a fast and bright future.