This new version is the result of a complete overhaul of the program. Older versions performed all the necessary decoding and conversion of Internet messages at import. This was done to reduce the payload on the GEM module and to speed up the actual display of messages on screen. But speed considerations of this kind are no longer valid on modern machines. Besides, once converted and decoded, it becomes very difficult, and in some cases impossible, to retrieve the original sources. And some modern features - PGP-MIME, for instance - require access to the original form of the message as it was sent over the net. This new version, therefore, writes the messages into the database exactly as they were received, and converts and decodes them each time they are loaded and written to screen.
The consequence is that you cannot use this version with your old data-base files. Messages other than plain US-ASCII would be garbled. Moreover, to enhance the flexibility and power of the program, the structure of the index files had to be changed as well. So I'm afraid you have to start afresh with this version.
Okami 3.0 boasts the following new features:
A warning for SOUP users. Although it is possible to use other compression/decompression programs than zip, it is recommended that you use only zip. If you do use zoo or lharc, make sure to include a "silent" command on the option line when compressing and decompressing under GEM. With zip, the "silent" option is automatically added by Okami. All this caution is due to the fact that especially MagiC has trouble with Pexec() and redirection of stdout and stderr. So be warned!
Another caution for SOUP users is that when exporting from the GEM module, any existing reply file in the upload directory will be deleted. You could apply some precaution by adding a date format to the reply file name and only exporting once a day. Be sure to add a "silent" option to the upload parameters as well (again: this is done for zip automatically).
Completely new handling of MIME multipart messages. The old routines for
MIME multipart messages were hacks built upon hacks, so I rewrote them
completely to rationalize them and make them flexible enough to deal with the
full range of exigencies, including (in principle) infinite inclusion. If a multipart
message is opened, the main part in text/plain is displayed in the window. The
other parts can be called by clicking on the paperclip icon on the message
status line, or by clicking on "View attachments" under "Message" in the
menu. If the part is an attachment, the supplied file name is shown, otherwise
the content type. The parts are displayed on screen in the form of a vertical
row of buttons, or a scrollable window if the number of parts exceeds the
number of possible buttons on the screen. After clicking the buttons a
dialogue box appears asking what you want to do with the file. You can
either view it, or save
it (for the time being). On saving, the necessary decoding will be performed.
You can also walk through the parts of a multipart message in the "classic"
way. Click on "Multipart" in the message status line (and/or keep on clicking
it in case of embedded multiparts), and use "next" and "prev" to view the
different parts.
uuencode replaced by MIME base64. Okami doesn't support uuencoding anymore. All binary files (attachments) are sent using MIME base64 encoding. Okami does however support uudecoding. If the body of a message contains uuencoded parts, you can decode (all of) them by clicking on "uudecode" under "Message" in the menu. You can view and decode the individual parts by clicking on the paperclip icon that appears in the message status bar. The uuencoded parts are not shown on screen anymore.
PGP-MIME support. Okami now offers full support for PGP signed or
PGP encrypted messages in PGP-MIME format (see RFC 2015). In addition,
"classical" PGP encrypted and/or signed messages can also be generated. For
"classical PGP" click on "PGP" in the menu in case of an encrypted and/or
signed message, or deselect "PGP-MIME" in the PGP dialogue window. Public
keys are always sent in MIME format (i.e. as an attachment in a MIME
multipart message). Sign and encrypt are postponed to the export phase,
so you can always re-edit your messages.
It is recommended to use PGP 2.6.3ia with Okami, because that is the only
version I have tested it with. It has one nagging flaw: its return codes
aren't always logical. If PGP can't find a particular key in your public
key ring, it returns 0, which in all other cases means "success". The consequence
is that if someone you don't know sends you a signed message, PGP will return 0 when checking
the signature (because it can't find the public key), and Okami will say that
the signature is OK. The same could happen when you try to send a public
key other than your own, or to encrypt a message for someone who's public
key you don't have. There isn't a good remedy for this flaw, other than to
fix the
source code and compile a new executable. I used to have the source code to
version 2.6.3ia, but I lost it and can't find it again. If someone can
deliver it to me, I will try to fix the return code handling.
To use PGP from within the GEM module, you MUST have TOS2GEM installed (for
the time being).
PGP-MIME messages are indicated by a PGP icon in the message list window and
by a PGP icon in the message status bar. You can click on the last icon to
view the status of signed messages.
New menu bar in message list windows. The menu bar in message list windows is now indented to make room for icons to the left of it. The following icons are available:
Disposition notification for "Return-Receipt-To:" or
"Disposition-Notification-To:" messages. If a message has a
"Return-Receipt-To:" or "Disposition-Notification-To:" header with a viable
Internet address, the user, on opening the message, will be asked to send a
receipt message to indicate that he has received and opened it. You can either
say "yes" and send the notification, or say "no" and handle the case as you
see fit. You won't get a second chance to send the receipt message
The receipt message has the form of a "disposition notification" as
specified in RFC 2298. You cannot re-edit it.
"Priority" or "Importance" indication. If a message is marked "high priority", an exclamation mark will appear before it in the message list window. The exclamation mark will also appear on the message status bar, and as part of the message flags string in the info bar of the message window.
New menu items under "Message": "View header", "View source", and "View
attachments". The header is not a part of the message window anymore to
which you can scroll to. You must rather view it in a different window.
Messages in the Outbound folder have no header. If the message in question
is a part of a multipart message, the part header is shown.
In addition you can view the source of the message as it was sent over the Net.
"View attachments" has the same effect as clicking on the paperclip icon in
the message status bar.
"Save" function changed. There are now two ways to save messages: "As email" or "As news", meaning the complete source of the message, or "As text", meaning a selection from the header, followed by a blank line, followed by the plain/text part of the message. In addition, the message id and the address of sender can be saved independently.
Names of months in local language. The file "language.inf" has changed to include not only the names of the weekdays in your local language, but also the names of the months. The groups must be bracketed by "begin" and "end" statements. A sample file is included. For the time being this feature is only applied in the header of messages saved "As text".
Please test and give me feedback!
Bug fixes