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