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