Weird email of the day

I’ve got nothing:

Hello, I visited your profile at ( and I find out that you’re the type my heart love, I believe we suit for real love, let walk that precious thing out for heart desire, I hope and believe we match for good. When contacting reply to my mail address ( I am waiting for the love. I am, Miss helen

True love is a beautiful thing.

Please don’t

A fresh cup mentions the Ruby on Rails exception notifier plugin. The idea is that every time an exception is raised in your code you get an email. This is such a horrible idea that I need to take the time to comment.

As someone who spends all his time dealing with large deployments of software, email is the worst way of reporting errors I can think of. Think about it:

  • Email is unreliable to deliver. It could get queued on the reporting server, a mail router on the network, or on your delivery server. Worse than that, it could get marked as spam, or randomly discarded.
  • Email is expensive. There are two kinds of expense here — email needs to be written to disk reliably, which means you sync() when you write the mail to a destination or a queue. For some MTAs, this can mean several syncs() per email as the mail moves between queues. There can be more than one of these MTAs on the way to the final delivery target as well. Additionally, storing email at the destination is expensive. Think of the backups, virus scanning, spam scanning, caching on clients and so forth.
  • Email is wasteful. Think of all those headers for probably only a couple of lines or actual error to report.
  • One email can result in many deliveries. To make the expense worse, your one email might get delivered many times. Think aliases, blackberries and mailing lists.
  • Email is dumb. You wont get a summary of repetition — if there are 10,000 errors, you’ll get 10,000 emails. Try wading through those trying to work out what went wrong.
  • The email could result in other outages. Most MTAs are built to handle “normal workloads”. Delivering 10,000 errors could end up with an unrelated outage taking down the mail system as well.
  • You probably don’t care anyway. An exception indicates a bug in your code which you don’t know how to handle. The server should just crash and restart at that point… There isn’t anything that the exception will really help with here. A bug should be reported instead for new instances of exceptions (you could automate this).

A better solution? Write log entries to disk when these exceptions are seen, and then provide summaries to developers and operations engineers — perhaps as email, perhaps as something else. Report on the rate of these errors, and the count of the number of errors seen recently. These are much lower volume, so email would be an ok solution here.

Very behind in email land

Excuses as to why I haven’t read email from others, or blog posts, in a while:

  • It’s the holiday season, less time on the computer
  • Having the last couple of chapters of a book due
  • Getting ready for my three or four talks clustered around the 2007 trip (the conference tutorial, one or two mini-conference talks, and a talk at SLUG)
  • A road trip to Phoenix via LA
  • Andrew being sick with something that looks a lot like Giardia for the last three weeks
  • It’s the end of the quarter, gotta meet those goals!

I’ll catch up one day.

Email subscription to comments

Hey all. Yesterday I finally got around to implementing email subscriptions to comments on posts in my custom comment module code for Blosxom. I run a custom comment module because of the static generation mode I use for the site, which helps reduce load on Andrew‘s server.

Email subscription to comments on a post that you have commented on is the default, but it is easy for the user to turn it off. If you post and opt for email, you’ll also get an email when your own post survives moderation, which might be useful for some people.

It will be interesting to see if willingness to be emailed a comment is an effective spam signal or not — so far with a sample of six spam comments, it seems to be evenly split between the two options, which is interesting because it means some spam bots are smart enough to turn the check box off. Or are they using a POST without using my form at all?

(That makes me wonder if moving the URL for the submission CGI might reduce spam…)

If there is any interest in a public release of my uber crap perl code let me know, and I might try and find the time to clean it up.