João Prado Maia’s Weblog

Go get it here.

A few security problems were found on previous releases, so upgrade as soon as possible.

Eventum has a feature to provide RSS feeds of custom filters, which is basically a way to save advanced search parameters into a special URL that you can call out to check on results. Pretty useful feature, and a lot of people use that. However, we can’t simply have an open window into a potential confidential database of issues/bugs/tickets, so the RSS feed script authenticates the user with HTTP Auth, with the usual PHP way of doing things:

<?php
if (!isset($_SERVER['PHP_AUTH_USER'])) {
header('WWW-Authenticate: Basic realm="My Realm"');
header('HTTP/1.0 401 Unauthorized');
echo 'Text to send if user hits Cancel button';
exit;
} else {
echo "Hello {$_SERVER['PHP_AUTH_USER']}.";
echo "You entered {$_SERVER['PHP_AUTH_PW']} as your password.";
}
?>

Everything works fine most of the times, but we started getting reports of problems from Microsoft IIS users. It turns out that PHP doesn’t automagically sets up the PHP_AUTH_* variables for you in some cases, and there’s even a quick mention of that on the documentation:

Another limitation is if you’re using the IIS module (ISAPI) and PHP 4, you may not use the PHP_AUTH_* variables but instead, the variable HTTP_AUTHORIZATION is available. For example, consider the following code: list($user, $pw) = explode(‘:’, base64_decode(substr($_SERVER[‘HTTP_AUTHORIZATION’], 6)));

However, that wasn’t true for a Microsoft IIS 6.0 that had configured PHP as a ISAPI module. Instead of getting a $_SERVER[‘HTTP_AUTHORIZATION’] variable like that, he would get this when doing var_dump($_SERVER):

array(30) {
["ALL_HTTP"]=> string(985) "HTTP_CONNECTION:keep-alive
HTTP_KEEP_ALIVE:300
HTTP_ACCEPT_CHARSET:ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_ACCEPT_ENCODING:gzip,deflate HTTP_ACCEPT_LANGUAGE:en-us,en;q=0.5
HTTP_AUTHORIZATION:Basic ********************************************"
}


So instead of simply using the $_SERVER variables, I had to manually handle the HTTP environment variables and get the proper value:

if ((!empty($_SERVER['ALL_HTTP'])) && (strstr($_SERVER['ALL_HTTP'], 'HTTP_AUTHORIZATION'))) {
preg_match('/HTTP_AUTHORIZATION:Basic (.*)/', $_SERVER['ALL_HTTP'], $matches);
if (count($matches) > 0) {
$pieces = explode(':', base64_decode($matches[1]));
$_SERVER['PHP_AUTH_USER'] = $pieces[0];
$_SERVER['PHP_AUTH_PW'] = $pieces[1];
}
}


That will do the trick.

Back when Eventum was still a commercial product of mine, I tried to create some banner ads to try to promote the product. I just found some old copies lying around on my web server:

And some vertical banners that I would use on my weblog:

Isn’t that adorable? :)

So here’s the deal: Outlook 2003 doesn’t include the Message-ID header if you are sending email through a mail server other than Microsoft Exchange. There are other rants about this:

1. from Peter Pentchev
2. from Terry Frazier

And they both point to this priceless news bulletin, which contains this gem:

According to Mark, Microsoft apparently had a few complaints from people using Outlook that their machine name was “leaked” in the Message-ID header. Instead of ignoring the complaint or making the host name used in the Message-ID header configurable, Microsoft chose to remove the Message-ID header.

Technically, Outlook 2003 is still RFC-compliant, if Microsoft accepts the fact that messages sent from Outlook 2003 may be marked as spam. Most spam filters that look at Message-ID use that as only one of many factors weighted to determine if a particular message is likely to be spam. Administrators may want to check the weighting for that particular factor and lower it to avoid having too many incoming Outlook 2003 messages marked as spam by mistake.

Mark says that, as he understands it, Microsoft’s position that they expect all mail servers to whitelist outgoing mail from Outlook 2003 users and add a Message-ID header to fill in the one that Outlook omits. To me, that seems a bit much to ask. Why couldn’t Outlook itself add its own Message-ID header that doesn’t reveal personal or computer information?

Stay tuned. I don’t think we’ve heard the last of this issue.

No, that was really the last of this issue. Microsoft did indeed change the behavior in Outlook 2003, and there’s nothing we can do about it. Well, besides add yet another level of hatred here, of course.

So what does one need to do to uniquely identify messages if this is happening? Eventum uses the value on the Message-ID header to decide whether it should download a message from a POP3/IMAP server or not, so if there’s no value on that header, all hell breaks loose.

All I can think of right now is to generate some sort of checksum for each message and check the database when downloading messages to see if we already have a copy or not.

But deep down, I personally blame Peter W. Resnick (the editor of RFC2822) for using SHOULD instead of MUST for the Message-ID header. Here’s some love, Pete.

I had no idea about this, until I noticed a new section on our Wiki page that describes the installation notes for FreeBSD:

You can alternatively take the easy way and install Eventum from FreeBSD’s ports collection. At first, you need to update your ports collection using cvsup (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html). Once you updated your ports directory, use: cd /usr/ports/www/eventum && make install clean

Pretty cool :)