New Features of MM 0.91 Frank da Cruz Wed Sep 18 19:17:32 2002 CONTENTS 1. BUG FIXES AND PORTABILITY 2. USING 8-BIT DATA 3. DOWNLOADING MESSAGES This is the first release of MM since 1990; I did this mainly because it was constantly truncating my outgoing messages when I returned from GNU EMACS, which drove me nuts (not an MM bug -- more likely an NFS one); I didn't want to give up MM and nobody else had to the time to work on it. Well, neither did I. But as long as I was in the code, I did a couple other things too. I guess that makes me the new MM maintainer? 1. BUG FIXES AND PORTABILITY All patches to version 0.90 from the original developers, mainly Howie Kaye, are incorporated; most importantly, the Y2K and Y2K1 fixes. Then come numerous bug fixes and file reorganization from Ken Harrenstein , including new simplified makefiles and conversion of many files to the "new" (1990) OS-dependent (or feature-dependent) structure that started in version 0.90. Ken's changes are documented in work/notes-klh.txt. I carried this forward a bit in getting the new version to build on Linux (with help from Chiaki Ishikawa and Adam Sampson , so now the Makefile automatically links config.h to the right OS-dependent config.h-blah file. The main "functional" bug fix is a lot of code to check for, protect against, and allow recovery from truncated outgoing messages upon return from the editor. Users will notice that .mm-xxx temporary files are no longer deleted immediately upon return from EMACS or whatever your editor is, so if "display" should reveal that some or all of the outgoing message text is missing, you can rescue it from the .mm-outgoing- file, whose name is announced to you each time you return from the editor. This feature is enabled only in Solaris and SunOS, because those are the only platforms where the problem was observed, but can be compiled in to any other platform too (-DFDC_EDITFIX). In any platform that has this feature, the new command: SET USER-TEMP-FILES-KEEP { ON, OFF } can be used to turn it on and off. See work/notes-fdc.txt for details. As of this writing [Tue Sep 24 16:58:16 2002] version 0.91 builds and runs on Solaris 2.5.1 (and presumably later), SunOS 4.1.3, Linux (Red Hat 7.1, but presumably any other reasonably recent Linux version), OpenBSD 3.0, and NetBSD 1.5.2. All others (AIX, HP-UX, Tru64, etc) untested. 2. USING 8-BIT DATA MM knows absolutely nothing about character sets, which is good because this lets you have control, and therefore use any character sets you wish without interference. Although I had been using MM forever, I always believed it could not handle 8-bit text messages, and therefore used some other mail client to send or reply to mail in Spanish, German, or Russian (etc) that was encoded as Latin-1, KOI8-R, UTF-8, ... It turns out MM can be used for this purpose after all, but it needed some new headers for outgoing messages. 2.1. Reading Mail. MM displays incoming messages literally and saves them literally into your mail file. It doesn't strip the 8th bit and it doesn't intepret the message content in any way. If an incoming message contains 8-bit data, MM sends it directly to your screen when you read it. For this data to be intelligible, you need a terminal emulator (or xterm window, console screen, etc) that either uses the same character set or knows how to convert from the message character set to the terminal character set. I use MM on a Unix host through a Telnet or SSH session (or other kind of connection) from Kermit 95 on Windows, which understands nearly 100 different character sets: the ISO 8859 Latin Alphabets, the ISO 646 7-bit national sets, various Cyrillic KOI encodings, numerous PC code pages and other proprietary sets such as HP-Roman8 and DG International, as well as Unicode UTF-8, the latter including thousands of characters in dozens of scripts (Latin, Greek, Cyrillic, Hebrew, Japanese, you name it -- even Runes). A properly formatted e-mail message identifies its text characer set in a header like this: Content-Type: text/plain; charset=xxx where xxx is the MIME standard name of the character set. If a message arrives and looks like garbage, you can change Kermit's character set to match (you can do this on the K95 2.0 toolbar) and redisplay the message. When using Kermit to access MM, you should be aware that Kermit's character-set names are not always the same as the names shown in the Content-Type header (because Kermit predates MIME). For example: MIME Name Kermit Name Remarks ISO-8859-1 Latin1 West European Latin ISO-8859-2 Latin2 East European Latin ISO-8859-3 Latin3 Mainly for Turkish ISO-8859-4 Latin4 Mainly for Sami ISO-8859-5 Cyrillic-ISO Cyrillic + Latin ISO-8859-6 Arabic-ISO Arabic + Latin ISO-8859-7 Greek-ISO Greek + Latin ISO-8859-8 Hebrew-ISO Hebrew + Latin ISO-8859-9 Latin5 ISO 8859-9 is Latin Alphabet 5 ISO-8859-15 Latin9 ISO 8859-15 is Latin Alphabet 9 (has Euro) UTF-8 UTF8 Unicode UTF-8 2.2. Sending and Replying to Mail. When you give MM a SEND or REPLY command, it normally enters "direct text input mode", collecting characters straight from your keyboard. When it does this, it strips the 8th bit of each character. This is unfortunate but unavoidable; it occurs at such a low level in the command parser that it could not be changed without breaking everything else. Luckily if you tell MM to: set use-editor-always true the command parser is bypassed and the 8th bit is not stripped. If you are replying to a message and including the original message, its 8-bit characters are preserved. You can enter 8-bit characters yourself using any method allowed by your editor and/or terminal emulator (e.g. Kermit's Compose key). Then before sending the message, you should tell MM to include the headers that identify the character set. This requires a new command that was added in MM 0.91: content-type xxx where xxx is a MIME character-set name (the default, if you give a CONTENT-TYPE command without an argument, is ISO-8859-1). When you give this command, MM writes out a full Content-Type header including the character-set name you gave, e.g. CONTENT-TYPE UTF-8 results in: Content-Type: text/plain; charset=UTF-8 When you give a CONTENT-TYPE command, MM also inserts two other headers that are required by the recipient to properly interpret the message: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Should it be necessary for you to specify other values for these headings, you can do so with the following commands (also added in MM 0.91): mime-version transfer-encoding The MIME-Version value would be something like "1.0" and the Transfer-Encoding value should be something like "8bit" or "7bit", but no verification is done. 3. DOWNLOADING MESSAGES Version 0.91 of MM has the following new commands for downloading messages. They work exactly like the PRINT command, but download rather than print. SET DOWNLOAD-FILTER [ text ] Sets the download filter (program) to the one give by "text". This program is run when you give a DOWNLOAD command. The default download-filter is "kermit -Ts - -a %s"; that is, send standard input (which is fed to Kermit by MM) in text mode under the name given by the replacement string; the default replacement string is "mm_msg". The download program must be able to send from standard input (as Kermit does with its "-s -" command-line option). XYZMODEM programs (e.g. Omen rzsz or GNU lrzsz) don't seem to allow this, but you can work around them as follows: set download-filter cat > %s; sz -a %s; rm %s You can have up to four %s's in the download-filter; each one is replaced by the same string. DOWNLOAD [ /FILENAME:name ] In Read or Send mode, downloads the current message. Headers are treated according MM's DONT-PRINT-HEADERS and ONLY-PRINT-HEADERS settings. If you specify a filename, and if MM's DOWNLOAD-FILTER contains "%s", the "%s" is replaced by the given name. So for example, with the default download filter ("kermit -Ts - -a %s"): DOWNLOAD (by itself): Sends the message as "mm_msg" ("kermit -Ts - -a mm_msg"). DOWNLOAD /FILE:foo.bar Sends the message as "foo.bar" ("kermit -Ts - -a foo.bar"). DOWNLOAD /FILE:~/Mail/msg.txt The filename can include a path, which will be used if the file-transfer software knows what to do with it (Kermit does). You should be able to include almost any printable character except Space in the filename; however, backslashes must be doubled: DOWNLOAD /FILE:c:\\some_directory\\some_subdirectory\\some_file.txt DOWNLOAD [ /SEPARATE-PAGES ] [ /FILENAME:name ] [ message-sequence] At top level, downloads the given message sequence (default = current msg). /FILENAME: works as in Read Mode. If the /SEPARATE-PAGES switch is included, multiple messages are separated by formfeeds. If you specify a message sequence indicating more than one message, the entire sequence is downloaded as one file. You can also prefix the DOWNLOAD command with LITERAL (as with TYPE, PRINT): LITERAL DOWNLOAD [ /SEPARATE-PAGES ] [ /FILENAME:name ] [ message-sequence] Includes all the message headers, regardless of DONT-PRINT-HEADERS and ONLY-PRINT-HEADERS settings. When accessing MM from any reasonably modern version of Kermit (such as Kermit 95 on Windows or C-Kermit 7.0 or later on Unix), Kermit's "autodownload" feature kicks in (yes) automatically -- as soon as the MM's download-filter program starts sending with either Kermit or Zmodem protocol, the terminal program switches to file-reception mode, and then back to terminal mode when the transfer is complete. Thus the DOWNLOAD command does the entire job -- no "escaping back" or re-connecting is needed. If you are accessing MM from Kermit 95 on Windows, you can download MIME messages that contain enclosures directly into your Windows mail agent. This is dangerous and is not recommended unless you know what you're doing and have inspected the message carefully in MM to ensure its payload is not lethal (further explanation is beyond the scope of this document). Tell MM to: DOWNLOAD /FILE:xxx.eml Then escape back to the K-95> prompt and tell K95 to: RUN START xxx.eml This tells Windows to start whatever program is associated with the .EML (e-mail) extension (Outlook, Netscape, whatever) and feed the xxx.eml file to it so you can experience it in all its multimedia glory. The fact that you saw it in MM first allowed you to prescreen it for safety, an opportunity you would not have if you used a PC-based mail client to begin with. (End)