Geoff Chappell - Software Analyst
Windows 95 includes a Microsoft Exchange client (also called Windows Messaging and shown on the desktop as the Inbox) for sending and receiving messages through a wide range of mailing services. Microsoft supplies a MAPI service provider called Internet Mail so that the Exchange client can “send and receive mail directly on the Internet or other networks using the Simple Mail Transport Protocol (SMTP) and the Post Office Protocol 3 (POP3) over TCP/IP.” (This quoted description is from the Microsoft Windows 95 Resource Kit, Chapter 26.) This Internet Mail service for the Microsoft Exchange client is implemented in the file MINET32.DLL.
Internet messages received through the Internet Mail service for Microsoft Exchange may show the wrong time of receipt.
For instance, when a message received by a user’s Internet Service Provider (ISP) in Sydney at 15:17 on a fine summer day is downloaded through a modem a few hours later in Brisbane (where the weather is typically even better), the entry in the Inbox may show the message as having been received at 01:17 the next day.
Coding errors may induce MINET32.DLL to ignore time zone information in a Received line of an Internet message’s header. The problem is not seen by all users. It occurs only if the first Received line in the Internet message header is formatted in a way that the MINET32 code does not anticipate.
In the example given above, the ISP receives the message and adds a Received line to the front of the header. This particular ISP’s practice—and it is by no means an unusual practice—is to follow the usual time zone information with a comment. Specifically, the time zone indicator “+1100” (which is correct for Sydney in summer) is followed by the acronym “EST” in brackets. When the user downloads the message from the ISP, the MINET32.DLL code interprets the time zone indicator correctly but then tries to interpret the comment as new time zone information. On finding that the comment is not valid as time zone information, MINET32 proceeds as if there is no time zone indicator at all. In consequence, the message received by the ISP at 15:17 in Sydney’s summer time is deemed to have been received at 15:17 GMT. This is 01:17 the next day in Brisbane (which is 10 hours ahead of GMT)—hence the obviously silly outcome in which the message is displayed as having been received in the future.
Note that the RFC822 Standard for ARPA Internet Text Messages allows for a comment as “a set of ASCII characters, which is enclosed in matching parentheses and which is not within a quoted string.” (See Section 3.4.3.) The MINET32 code for interpreting a Received line in an Internet message header simply doesn’t allow for comments—and if a comment follows a time zone indicator, the MINET32 code simply loses the time zone.
The problem appears in several versions of the MINET32.DLL file. Details such as file sizes, dates and known distribution packages are given in the following table.
| Version | Size | Date and Time | Package |
|---|---|---|---|
| 4.40.41084 | 289,792 | 09:50, 11th July 1995 | Windows 95 |
| 04:40, 14th July 1995 | Windows 95 Plus! Pack | ||
| 4.40.41086 | 289,792 | 01:00, 22nd November 1995 | Internet Explorer 2.0 |
| 10:40, 15th October 1996 | Internet Explorer 3.01 | ||
| 17:44, 22nd March 1997 | Internet Explorer 3.02 | ||
| 4.40.41097 | 293,376 | 09:50, 1st April 1996 | EXUPDUSA.EXE supplement |
| 09:50, 2nd April 1996 | INETMAIL.EXE supplement | ||
| 00:00, 23rd May 1996 | Windows 95 Service Pack 1 |
Although the Internet Mail service for the Microsoft Exchange client is not part of the ordinary Windows 95 package, it is included with at least some versions of Windows 95 that are prepared by Microsoft for distribution with new computers. Microsoft itself distributed the Internet Mail service as part of its Internet Jumpstart Kit in the Microsoft Plus! pack.
Windows 95 users were eventually able to obtain the Internet Mail service from Microsoft as a free supplement, typically by downloading from the Microsoft web site. See Microsoft Knowledge Base article Q148228 titled Microsoft Internet Mail Service Available for Download.
Although the Internet Mail service for Microsoft Exchange has no direct role to play in the use of Microsoft Internet Explorer, the MINET32.DLL file has been included with releases and updates of Internet Explorer.
Microsoft has issued Exchange Service Packs, each with directories named WIN95 and which are presumably intended for updating installations of Microsoft Exchange on Windows 95. Service Packs 2 and 4, dated 15th July 1996 and 27th March 1997 respectively, have been examined for this note. However, neither contains an MINET32.DLL file.
When MINET32 parses a Received line it skips to the time stamp, which it understands to be all the characters that remain on the line after the first semicolon. Provided the time stamp is no longer than 81 characters, it is parsed as a sequence of tokens separated by spaces or tabs. Tokens may represent:
These fields may be filled in any order, except that a token cannot represent a time zone or distinguish am from pm unless a valid token for the time of day has already appeared in the time stamp.
Fields for the month, day of week, time, day of month and year may be filled only once. For instance, once the parser has accepted a token as representing a month, it does not attempt to interpret any subsequent token as representing a month.
Once fields for the month, day of week and time have been filled, any token that does not begin with a digit is tested for interpretation as a time zone indicator—even if the time zone field has also been filled from an earlier token. To compound the problem, when the parser attempts to interpret a token as a time zone indicator, it discards any time zone that it has already deduced. If the token is not valid as a time zone, the parser checks whether the token matches the AM or PM symbols (independently of case)—again, even if the am/pm qualification of the time has already been deduced from an earlier token.
For MINET32 to accept a token as representing a time zone, the token must have one of the following forms:
The general format, with a plus or minus sign and four digits, is remarkable because of another coding error. The four digits are in pairs, two digits for hours and two digits for minutes. Thus, +1000 means ten hours ahead of GMT. Not many populated areas of the world work to time that is not a whole number of hours different from GMT. However, if the time-zone bias does include a non-zero number of minutes, the MINET32 code will count those minutes as seconds. For instance, someone whose Internet messages are stamped +0930 by an ISP in Adelaide, South Australia, will find that Internet Mail treats the time of receipt as if Adelaide is nine hours and thirty seconds ahead of GMT rather than nine hours and thirty minutes.
Inspection of the MINET32 code for parsing time stamps is thus seen to uncover the following problems with the handling of time zones. The MINET32 code:
The first of those problems, i.e., the one that prompts this article, can be corrected by patching two sets of two bytes in the MINET32.DLL file. If a comment follows a time zone indicator, then although the MINET32 code still attempts to parse the comment as a time zone indicator, the effect of the patch is that the code does not lose the time zone information that has already been interpreted correctly.
The patch is not ideal. It is not what one would change in the source code. It is just a work-around to defeat the practical consequence of something that the relevant code ought not to do.
The locations of the two sets of two bytes vary with the version number of the MINET32.DLL file. In the following table, the patch sites are given as offsets in bytes from the start of the file.
| Version | File Offsets |
|---|---|
| 4.40.41084 | 00019312h 00019317h |
| 4.40.41086 | 00019323h 00019328h |
| 4.40.41097 | 0001971Dh 00019722h |
Both patch sites are two bytes long. At the first patch site, the expected bytes are 89h and 32h, being the opcode bytes for the instruction mov [edx],esi. At the second patch site, the expected bytes are 89h and 31h, representing the instruction mov [ecx],esi. At each of the two patch sites, replace the two existing bytes with 90h (so that four bytes in the file get changed to 90h).
If you are at all uncertain how to patch a file, do not try it.
Microsoft Corporation does know of this problem and can presumably advise further. Indeed, wider investigation has revealed that at least some programmer at Microsoft has full knowledge of the circumstances in which the Windows 95 versions of the Internet Mail service for the Microsoft Exchange client may misread time zone information.
The Internet Mail application that accompanies Microsoft Internet Explorer 3.0 is implemented in the file MAILNEWS.DLL, which also supports the Internet News application. The version of MAILNEWS.DLL inspected for this note is
| Version | Size | Date and Time |
|---|---|---|
| 4.70.1155 | 1,148,176 | 09:10, 7th August 1996 |
It does not exhibit any of the time zone problems discussed above—even though the MAILNEWS code for parsing an Internet message’s time stamp is clearly an adaptation of the code used for MINET32.DLL. Notable changes are that the MAILNEWS code:
Note that these correspond one-to-one with the earlier summary of coding errors in MINET32’s handling of time zones. Microsoft’s knowledge of errors in the code that MINET32 uses for interpreting time zone information in Internet messages is therefore seen to date from at least as far back as August 1996.
An MINET32.DLL is also distributed with Windows NT 4.0. The version examined for an amendment to this note in November 1997 is:
| Version | Size | Date and Time |
|---|---|---|
| 4.40.8371374 | 224,528 | 01:38, 14th October 1996 |
The code in this version of MINET32.DLL fixes the main problem presented in this note. In particular, instructions are added so that only one token can ever be tested for validity as a time zone indicator. Also, when given a time zone whose bias is not a whole number of hours, the Windows NT version of MINET32.DLL does count the spare minutes as minutes, not as seconds.
However, there are no modifications to recognise time zone signatures such as UT, GMT and EST independently of case, and there is no support for LOCAL and UNDEFINED as aliases of TZ. It seems likely therefore that the time zone problem at the centre of this note was fixed first in the natural development of the source code for MINET32.DLL and that this source code was adapted even further when used for Internet Mail and News.
Since Microsoft has corrected the time zone problems before including the relevant source files in another program for Windows 95 and in the Windows NT version of the same program, it is inescapable that the problems described above are understood in detail by at least some programmer at Microsoft. Moreover, this understanding was gained no later than mid-1996.
Even if the problem is not thought serious enough to warrant including an update for Windows 95 among the various Service Packs that Microsoft has since issued, where is the Microsoft Knowledge Base article that might at least notify users of the problem’s existence and of how Microsoft proposes to treat it? That is perhaps a moot point, however. Microsoft has had its opportunities to make a corrected MINET32.DLL available to users, but has not taken those opportunities. Since mid-1996, Microsoft has distributed updates that contain MINET32.DLL, but in a form with the problems uncorrected. Conversely, it has distributed Service Packs for Microsoft Exchange, but without any form of MINET32.DLL, corrected or not.
Incidentally, this article would not exist at all except that when the observed problem was presented to Microsoft by telephone, the reaction was that Microsoft had never heard of it, that it was not described in the company’s extensive database and that it would therefore only be investigated as an alleged bug if permission was first given to deduct a fee from a credit card account. This was in late-1996, when Microsoft had not only heard of the problem but had fixed it in the latest versions of the relevant source files.