Support for the generation of MIME compliant messages has been added to LISTSERV through two new file formats, MIME/TEXT and MIME/APPL. Preliminary note: the next version of the VM mailer, planned for release 4Q92, will support Netdata format. When this version and the necessary information to modify LISTSERV to support it are released, there will be no need to do anything special to mail files with lines longer than 80 bytes. Thus the reason for implementing MIME support is NOT to solve the 80 columns problem, which is a limitation of the VM mailer (and, consequently, of any software which sends files to the VM mailer in PUNCH format due to lack of support for other formats). The goal is to provide a mechanism which can cross gateways safely and will be widely implemented (I do not say 'is' here because the answers to my previous questions about MIME and the software I have seen so far make it clear that we are still at a very embryonic stage). Thus there is and will be no support for quoted printable encoding, which does not generally survive ASCII<->EBCDIC translation. 'F=MIME/TEXT' (minimum abbreviation: F=MIME for now, might change before the official release) can be specified when ordering text files which get corrupted when mailed normally. LISTSERV translates the text to ASCII, adds a CRLF at the end of each line, and encodes the message using base64 transfer encoding and 'Content-Type: text/plain'. Note again that this will not work with binary files, for obvious reasons. 'F=MIME/APPL' (minimum abbreviation: F=MIME/A) can be used as a safer replacement for F=UUENCODE. LISTSERV does NOT translate the input data or generate any kind of carriage control: it simply encodes the raw input data as a stream of binary bytes, using base64 encoding and 'Content-Type: application/octet-stream' with a 'name=' keyword. Because the data is not translated to ASCII, this will not work with text files. Again, it is a replacement for F=UUENCODE, which completely ignores record boundaries and performs no translation, under the assumption that the file being ordered is a ready-to-use binary file downloaded from a PC. In spite of what you may have heard elsewhere, MIME does NOT provide any file transfer mechanism which could replace FTP or the NJE file transfer formats (NETDATA et al). MIME can only transfer a stream of bytes, using the 'application/octet-stream' type, and the standard does not assign any particular meaning to these streams of bytes: it suggests that the user interface should offer to deposit the decoded data into a disk file, which under VM, VMS, MVS or any other non-unixish operating system simply gets you a one-record file containing a long string of binaries. Before you counter that MIME could be easily extended to provide such a functionality and that I should indeed be working full time on doing that right now, let me add that I seriously doubt that MIME would be a viable alternative to FTP and SENDFILE, for performance and usability considerations. If you think the BITNET 300k file size limit is preposterous, take a look at what most SMTP's are enforcing! 100k seems to be the norm, and many sites will limit you to as little as 20k. Granted, MIME defines a way to split messages into smaller fragments, but when your 3M package is split into 400 chunks of 20k (counting the extra 33% for base64 encoding), chances are that chunk number 294 will get lost on its way and that you will have to restart from the beginning. Furthermore mail is not precisely a high performance bulk-data mover. Unfortunately I haven't been able to make serious tests including the reconstruction time for series of 100k-messages, but what imprecise measurements I could make so far indicated a transfer rate of about 2k/sec between two pretty fast machines on the same ethernet. This is not bad at all for a "backup" mechanism, but I really can't see this becoming the "prime" file transfer mechanism and making SENDFILE obsolete. Eric