Mentor:
 
>  Can someone tell me what does the "=" sign translate to when trying to put
>  the content of a file in the filelist?
>  I try to put a file that has 8 bit encoded characters (like e with two
>  dots on it, the Albanian language, the ISO-8859-1 code page) and tells
>  me that invalid password has been supplied.
>  Now, if i know what the "=" translates to, I can make my pass to have
>  these characters as the first few characters and then add some more
>  after it. So, when I try to put a file that contains the ISO-8859-1
>  codepage characters, I can supply ONLY the rest of the characters in the
>  pw= . That is I assume that the "=" translates to "= plus some other
>  things here"
>
>  Or does anyone else have any other idea how to put files that are not plain
>  text?!
 
I know what the problem is and I have developed a local solution to
address what I feel is becoming an increasingly important weakness in
LISTSERV.  The problem is that many mail programs will not send 8-bit
characters in their raw form.  They translate them into one of two common
coding methods using MIME standards.  The two methods most commonly used
by mail programs are QUOTED-PRINTABLE and BASE64.
 
The quoted-printable method takes the all 8-bit characters and turns them
into and equal sign followed by the upper-case HEX code for the character.
These are generally in the range =AA to =FF.  Obviously, if you start
using the = sign as a flag for a coding standard, you will have troble if
your text has actual = signs in them (such as a password=blahblah
specification).  So the quoted-printable standard also translates the =
signs in the original text to =3D.  The idea is that the mail program on
the receiving end will be MIME-compliant and will understand and decode
these things without you ever knowing.
 
The problem is that LISTSERV does not understand the MIME header
information that tells it the message has quoted-printable characters in
it and, hence, thinks that you are trying to put a file with
'password=3Dmypassword' which is of course, not the right password.
 
The other common alternative means of coding text with 8-bit characters is
called BASE64.  This encodes the whole message into strings of illegible
code; not just the 8-bit characters are coded.  This is most commonly
selected (automatically) by mail programs when they see that the number of
8-bit characters is high enough that the resultant size of the
quoted-printable-coded file will be larger than if the entire file was
coded using a different standard. Bear in mind that quoted-printable
increases the size used by each 8 bit letter by 2 letters. If a file
contained all 8-bit characters, the quoted-printable encoding would be
three times larger than the actual text.  BASE64 encoding is about 30%
larger than the original text, so it doesn't take a lot of 8-bit
characters to cross the efficiency threshold requiring BASE64
translations.
 
Again, the problem is that LISTSERV does not understand the MIME header
information that tells it the message is BASE64-encoded and and, hence,
will not recognize anything about it and you'll get back a bunch of error
lines that stop when the LISTSERV has decided that it doesn't want to
listen to any more of your garbage :-).
 
So... that's the problem in getting the 8-bit files *to* LISTSERV.
 
You *can* get them there, but even when you do, the only reliable way that
I have found in getting them via normal e-mail is to use the F=MIME option
at the end of the GET line.  Example:
 
   GET FN FT F=MIME
 
This will send the file to you in BASE64 format. Until just recently, I
found the files arrive in perfect order, with all appropriate characters
intact.  However, I discovered one anomoly in that the ASCII code 28 gets
converted to the ASCII code 130 by the LISTSERV when sending the BASE64
encoded message.  This should not be a huge issue for anyone, but I
mention it, because it goes to the heart of the problem; on VM machines
LISTSERV actually stores these files using EBDIC code tables.  Eric tells
me that MIME ignored EBDIC when developing their standard.
 
However, this is a minor problem... not too many people have code 28's in
their files.
 
Because it was important for me and because I knew that LISTSERV *could*
store these files, I forged ahead with a means of supporting our needs to
store the files.  Eric sent me the C code for a small program called
'lb64' that takes the input file and creates a // JOB whose bulk is a form
of BASE64 encoding that LISTSERV *does* understand.  What I did was to
write a perl program that people send files to (via an address alias) and
then the perl program acts as a front end for the lb64 program.  My
program interprets any MIME header and correctly DEcodes QUOTED-PRINTABLE
and BASE64 nessages and then runs the lb64 program on the message to
ENcode it into a form LISTSERV will understand. It then sends the // JOB
on to LISTSERV with a 'forged' From: line of the original sender of the
message, so that the replies from LISTSERV go to the original sender of
the message rather than the program.
 
The program runs well on our Unix host and should be easy to adapt to send
its output to the LISTSERV of your choice.
 
Obviously, I think the solution is to make the next version of LISTSERV
capable of understanding files sent to it in BASE64 and QUOTED-PRINTABLE
format, but in the mean time, I am happy with our hack.
 
On a somewhat related issue, I think that in addition to the SHORTHDR and
FULLHDR options for list subscriptions, there should also be a MIMEHDR
option in between that will include the three important lines of MIME
information in the header in the header of the messages sent to
subscribers.  FULLHDR settings increase the volume of each message and, in
some cases, result in the message having a header that exceeds the maximum
hop count for the reciving mail systems, causing non-delivery.  I think
that if LISTSERV wants to be able to provide support for dialog in
languages other than English, they should address these two issues in the
next version
 
If you'd like me to send a copy of my hack to you, let me know.
 
Cheers
 
Mark Hunnibell                  Email: [log in to unmask]
KIDLINK Gopher/WWW Coordinator  http://www.connix.com/~markh/index.html