Folks: This inquiry may be more relevant to LSTSRV-L, but I am not precisely sure what the difference is and I thought it was likely that some list owners may have encountered this. It's taken me a month or so of work, but I have finally resolved procedures on storing files on a LISTSERV at a VM host that include 8-bit characters. The problem in doing it directly is that the LISTSERV in question makes some kind of translations of the 8-bit characters and so what gets stored may be accurate, but what gets sent out when the file is requested is inaccurate. I believe this problem has something to do with EBDIC codes and Eric has tried to explain it, but it soon becomes greek to me. In any case, I wrote a perl program that acts as a front end for handling incoming 7 or 8 bit files messages or ones that use MIME standard quoted-printable and base64 encoding. The program receives the message and converts it, using the 'lb64' engine that Eric sent me, into a LISTSERV-compatible form of BASE64 which is then sent on to the real LISTSERV address, retaining the From: line of the original sender. The effect is that the we can now store files sent in quoted-printable and base64 format on LISTSERV and then people can get those files. If they do a standard GET FILENAME FILETYPE command, the file they get, if it contains 8-bit characters, will not have the accurate 8 bit characters. Eric told me that we can then use this format to get the files: GET FILENAME FILETYPE F=MIME This results in the file being sent to the requestor in MIME-compatible BASE64 format. The only other current (useful) alternative is F=UUE and that sends the file as a UUEncoded file which must then be extracted and decoded by the recipient (it's not sent as an attached file). I think we can live with these limitations. Now, to the root issue. To accomodate a Gopher menu series, I had a special address set up to get all new/updated files via AFD via e-mail. The script that handles mail to this special address is on a non-BITNET host. I recently revised the program and AFD subscriptions from a normal: AFD ADD FILENAME FILETYPE LISTNAME PW=XXXXX to AFD ADD FILENAME FILETYPE LISTNAME F=MIME PW=XXXXX I tested this before I did it and it worked well. However there were some noticable differences in the message that arrived. In the standard AFD, I would get messages with a subject something like: Subject: Automated file distribution (AFD) of "FILENAME FILETYPE" With the AFD set to MIME, the subject is simply: Subject: File: "FILENAME FILETYPE" I made the program account for this difference, but I am wondering why the difference. The other, more serious, difference is that the LISTSERV where these files are stored is also a BITNET host. On more than one occasion, the AFD's have come from LISTSERV@BITNODE rather than [log in to unmask] I suspect this is happening due to some internal LISTSERV algorythm which sends the AFD via a DIST job through another LISTSERV. The key here may be that we're also running the UNIX LISTSERV on the host with the special address script and so the AFD file comes in through the 'LISTSERV network' and is shown as coming via BITNET. The method of delivery (Internet vs BITNET) would not normally be a problem except that the ones that come via BITNET do not have the MIME header stuff in the header... it comes in the BODY. I suspect this is because BITNET isn't/wasn't made for MIME and so it doesn't know what to make of that stuff, so LISTSERV sticks it in the BODY. This means that the script gets a message with this kind of break between the header and the body: Date: Fri, 17 Nov 1995 22:00:59 -0600 From: LISTSERV@BITNODE Subject: File: "FILENAME FILETYPE" To: [log in to unmask] MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain ACdwdXQga2lkY29yZSBtYXJrdGVzdCBraWRjb3JlIHB3PWR1bW1pbmcAAAAUUFJP SkVUIFRSQUZJQyAtIDE5OTUAO1NhbyBQYXVsbyAtIEJy6XNpbCAgKE1hbm9lbCBB cmF1am8gRmlsaG8gPiBtYWFmaWxob0B1c3AuYnIpABtHcm91cGUgUEFUTkVUL1NP The problem, of course, is that the receiving sendmail program sees the blank line after the To: line and determines that's the end of the header and processes the rest as the body. I hacked a fix for this header anomoly, but I wondered if this was a 'bug' that might be fixed in a future release. It essentially means that people who get AFD F=MIME via BITNET will get this raw BASE64 encoded message. Of course, I suspect it's delivered via BITNET in NETDATA format and may well be decoded by the RECEIVE or other command. I just thought someone might like to know about the apparent random nature of the delivery method that might create problems for others doing similar things. Cheers Mark Hunnibell Email: [log in to unmask] KIDLINK Gopher/WWW Coordinator http://www.connix.com/~markh/index.html