Tony Field’s Blog

Hello! It seems that a bit of time has gone by since I’ve dusted off this blog. A long while, perhaps, based on the number of spam comments in the moderation queue. In any event, I’m going to start again. I’ll cover several topics, but be warned, I’m going to get technical.

Over the last few months I’ve ramped up my consulting company, Metastratus Web Solutions, quite a bit, and have taken a few steps back from FatWire Software where I’ve been parking most of my working hours over the last few years. Part of that is due to the fact that FatWire was recently acquired by Oracle. (That is a whole topic itself). Long story short, Metastratus is now an Oracle Gold partner and I’ve set out as an elite team of WebCenter Sites (formerly FatWire Content Server) specialists, to help customers with their implementations.

That’s going well. We were lucky in that we hit the ground running. Metastratus has been in operation for almost two years now and we have a team of 5 today, myself included. In the last couple of months, we’ve opened a US company, have started hiring, and began building relationships with several key partners in this small but rapidly growing community. And we’re hiring.

I must admit that getting all of this set up has been a huge amount of work, and so it’s really at the front of my mind a lot these days. Consequently, it’s going to probably dominate the blog for a bit. But besides just the whole setup topic, I’ll be posting technical topics regularly, and I won’t be able to resist the occasional personal post too. Some of you know that I’ve been pretty involved in the creation of the GST Site Foundation (”GSF”), so you can look here for posts on that topic too.

So that’s the intro for now. Watch this space, and please don’t hesitate to comment below.

As for now, its’ time to head home to prepare for a concert! The Etobicoke Community Concert Band is performing its first series concert, “From Rags to Riches”, tonight at ECI. It’s my first concert since coming back after a brief hiatus, so I’m looking forward to it. Very short rehearsal schedule though so we are hoping for some good celestial alignment (today is the Rapture (revised) after all).

Since switching to Mac OS X 10.4’s mail client, I have noticed that my email coming through my own server has been listed as “Received” four hours later than when it actually landed in my mailbox. I thought it was just some minor issue on my desktop until I heard about this from someone else using the same mail client.

I had worked around it by having Mail display the “Date Sent” field instead of the “Date Received” field, which instead shows the time the composing mail client sent the message instead of the time my POP server received the message. But with multiple people complaining about this issue, I decided to look into it.

The problem was not immediately obvious. The email messages looked as if they were properly formatted, but after consulting the Internet Message Format specification I discovered what was happening. It turns out that my mail server was using a valid but obsolete date format to indicate the time zone. Specifically, it was displaying dates like this:

Fri, 21 Sep 2007 20:07:09 GMT

When in reality it should be displaying that date like this:

Fri, 21 Sep 2007 20:07:09 +0000

This format would have been fine too:

Fri, 21 Sep 2007 20:07:09 +0000 GMT

Section 4 of the spec specifically states that applications that conform to the specification must not generate invalid dates, but must be able to interpret them. So what does that mean?

Well, it means that my mail server was not conforming, and that my mail client (Mail.app) was also not conforming. That explains why so few people ran into this issue: you have to encounter both bugs to see the problem.

So what to do? Since I run the mail server, I can at least try to configure my way out of the conformance issue. As for the Apple Mail client, well, the best I can do is report a bug (Bug ID 5503215) and hope it gets fixed. It’s a minor bug, and I assume that Apple will be able to fix it soon if it is deemed to be important enough, but it’s certainly not within my control.

Back to sendmail. Sendmail is notorious for being difficult to work with. Its configuration files are so complex that there is a second format for a “simplified” configuration file that you “compile” into the regular configuration file. A quick internet search, however, led me to the setting that controls the mail server’s time zone: You just have to define the variable confTIME_ZONE in your .mc file and set it to the right value and you’re off to the races.

Perfect, that’s just what I wanted. So what is the right value? Well, that’s another issue altogether. Sendmail documentation is not very helpful here. It provides some help but not nearly enough. Here is what I have been able to piece together:

Leaving the variable blank will use the “system’s” time zone. I assume this is what was happening on my server, but I don’t really know what this means.

Setting the variable to “USE_TZ” will cause sendmail to use the value of the TZ environment variable. The problem here is that sendmail is executed in a way that makes defining this variable in the environment a little tricky. The last thing I needed was another tricky configuration setting so I nixed this option

The last option is to set it to an actual time zone explicitly. The format for this string, however, is not very flexible. The example provided in the Sendmail Installation and Operation Guide is PST8PDT. It turns out that the format is defined like this: The first three characters are the string representation of the time zone name for standard time, the next character is a digit that represents “the difference from GMT” for the time zone, and the last three characters represent the string representation of the time zone for daylight savings time. In this case, Pacific Standard Time, 8 hours “different” and Pacific Daylight Time.

Without going on a rant about poorly conceived this particular format is, let me just say that it doesn’t quite scale very well, or apply particularly well if you want to set your server to GMT and ignore daylight savings time. RFC 2822 at least talks about several email time zone strings for Eastern, Central, Mountain, and Pacific time that conforming applications must understand, so if you’re setting confTIME_ZONE you should probably just stick to one of these values. My server is in the Eastern Time Zone so I set my value to EST5EDT.

I made those changes, restarted the server and that fixed the problem. My mail client now understands when my mail message was received properly, and my server is configured to generate date stamps properly.

To summarize, to get sendmail to emit a proper date format, add the following to your

/etc/mail/your.hostname.com.mc

file:

define(`confTIME_ZONE', `EST5EDT')

then re-save it. You will then need to recompile your sendmail.cf file and then restart sendmail by typing make install restart from your /etc/mail folder.

/etc/mail/# make install restart

At that point you will be good to go.

Happy mailing!