IAF File Format Specification And Field ID Assignment Table

At last, perfect replacement for Outlook Express and Windows Live Mail is available, called OE Classic - Click here to download!

IAF is a file format used for importing and exporting account information in Microsoft Outlook Express 6, Microsoft Windows Mail (Windows Vista), Microsoft Windows Live Mail and older versions of Microsoft Outlook. It can be decoded by code already available on the Internet. Here are a few links to the decoder code:

The above code works just fine however it has a problem – a good number of IAF fields are not recognized, especially for Windows Live Mail IAF file format. So here is my update on this topic and most up to date list of fields I could come up with. Also, this post contains a bit of documentation on IAF file format because I found that it is rather hard to find online and Microsoft never revealed IAF file format specification (to my knowledge – correct me if I am wrong).

Essentially, IAF comes in 2 flavors:

  • WideChar version (16-bit characters – UTF-16LE format), used by Windows Mail and Windows Live Mail
  • NarrowChar version (8-bit characters, encoded in specific charset encoding – usually the same like OS charset) used by Outlook Express 6 and older Microsoft Outlook

For NarrowChar version assignment of Field IDs is more or less known and available in the decoder code above. However, for the WideChar version, not all fields are recognized.

The above code contains a list of Field IDs with their names and assignment. The purpose of this post is to complement that list with some additional Field IDs and offer additional explanation of how the fields are organized – which can help in further reverse engineering of the IAF file format.

From what I could discover, it appears that the Field IDs are 9-digit numbers organized into sections which begin with certain 3-digit number which I will call “sections”. Between the Field IDs there are gaps, probably left intentionally for future upgrades to the file format without breaking the old format. The Field ID ranges are organized as following:

  • 305-306 – General settings section
  • 311-314 – IMAP settings section
  • 321-323 – HTTP settings section
  • 325-326 – NNTP settings section
  • 331-332 – POP3 settings section
  • 338-339 – SMTP settings section

The numbers above represent only the first 3 digits of a 9-digit Field ID, so for example, a full Field ID might be:

305464304 – belongs to “General settings” section and is Field ID for AccountName.
311952368 – belongs to “IMAP settings” section and is Field ID for IMAPServer.

The bold part of the Field ID number above represents the number from the above section range. This is similar for all other fields as defined in the list.

So, as promised above – here is full list of the Field IDs, including the ones missing from the above decoder code. You will notice that some fields are still unknown.

Unknown fields have an “UNKNOWN” in the comment and are prefixed by “GENERAL-“, “IMAP-“, “HTTP-“, and “NNTP-“. As it seems, there are no unknown fields in the POP3 and SMTP sections that I have discovered so far.

If you know what the UNKNOWN fields are used for or if you have additional ones to complement this list, please do leave a comment below this post to help in reverse engineering of the IAF file format so that a fully featured decoder can be written at last. I will of course update this post with the latest up-to-date table and share it with everyone.

The list is public domain and you are free to use in your code, for any purposes, commercial or any other (I would be happy if you notify me about it, but this is not needed).

You can also decode your own IAF files (for example, if you want to extract forgotten password) with the online decoder found here:
https://www.oeclassic.com/iaf-decoder

Another bug in Delphi PopupActionBar – Vertical menu shows no scrolling arrows

At last, perfect replacement for Outlook Express and Windows Live Mail is available, called OE Classic - Click here to download!

Today I encountered another problem with TPopupActionBar in Delphi / C++ Builder – vertical menu arrow was invisible. I was using it because it is apparently the best component to be used with ActionManager but as it seems, it is half-baked.

Here are bugs I discovered so far (with a little help from our customers):

  1. When menu is very tall, taller than screen height, PopupActionBar won’t show up/down arrows for scrolling content as first and last items, while regular PopupMenu does show them (thanks Carroll for notifying me).
  2. Furthermore, PopupActionBar is very slow and unresponsive (opening very tall menu takes visible amount of time – I did’t measure it but it looks like more than half a second) while the regular PopupMenu opens instantly. Selecting another item in PopupActionBar can sometimes be very laggy (sometimes old menu item that has subitems does not close as you move mouse over another item so you have to move around again until it updates).
  3. When menu item has subitems and it is disabled – it is still displayed as enabled during runtime.

Here is a simple C++ Builder code to generate very tall menu to demonstrate the above point 1:

And this picture show point 3 in action:

Delphi PopupActionBar Bug
Delphi PopupActionBar Bug

Obviously, we are moving away from PopupActionBar. And as it seems it is not the only thing related to ActionManager controls that has bugs – if I remember correctly – ActionToolBar also had some issues. So I might very well guess that ActionMainMenuBar might have similar problems with vertical arrows or speed.

ActionManager is very nice way to organize code but the components designed to work with it are half-finished and I wouldn’t recommend them.