MIME quoted printable vs. 8-bit ------------------------------- Sending mail is a two-stage process. The user interacts with a software package called a "Mail-User-Agent" (MUA) to compose a message. Examples of MUA's are Pine, Elm, and Eudora. Often these MUA's are simply called "mailers". Different users on the same machine can choose to use different MUA's. The MUA then passes the message to another piece of software called a "Mail-Transfer-Agent" (MTA) which delivers it to the recipient machine. Examples of MTA's are Sendmail (used on danann.hea.ie, ann.indigo.ie and tarbh.smo.uhi.ac.uk) and PMDF (used on mailhub.ucd.ie). Normally only one MTA is used on each machine. This software acts behind the scenes and users are not normally aware of it. So the situation is like this: Sender's Sender Recipient Recipient's MUA ---> host's -----------------> host's ----> MUA MTA Internet MTA The basic cause of the problem is that the protocol used on the Internet to exchange messages between MTA's, "Simple Mail Transfer Protocol", was defined, probably more by accident than design, to use "ASCII" - i.e. 7-bit characters, unlike almost everything else on the Internet which is 8-bit clean. When MIME was devised about seven years ago, two solutions were proposed to this problem, corresponding to the two types of software agent involved. On the one hand it was proposed that SMTP standard be extented to "Extended SMTP" (ESMTP). This was backward compatible with SMTP - It didn't upset old MTA's - but it allowed some important improvements. It allowed the MTA's to negotiate and agree to send and receive 8-bit data. It also allowed the receiving MTA to tell the sending MTA in advance what its limit was on the size of messages, something very important for multimedia Email. Previously the receiving MTA just had to go ahead and try it and find that it failed after a megabyte or so, wasting a lot of bandwidth in the process. The alternative proposal was that the solution should be placed at the MUA level. The sender's MUA should encode 8-bit characters as "quoted-printable" (i.e. with hexadecimal thingies like "=E1") and that the recipient's MTA should decode them to 8-bit on display. That way accented characters could be sent over 7-bit data paths like SMTP. Both proposals had their merits. Obviously the ESMTP solution was best in the long run. It was simpler and it saved some bandwidth, CPU time and storage space which would otherwise be used in 7-bit encoding of 8-bit data. There are far fewer different MTA's around than there are MUA's. Only one piece of software had to be changed on each machine and this was usually in the control of someone who was knowledgeable about computers. The ESMTP solution was easier to interface to old pre-MIME software which was known to be 8-bit clean, as most of it was. The quoted-printable (QP) proposal also had its merits. This solution was close to the two people who most wanted a solution, the sender and the recipient, rather than involving system managers of intervening machines who might have no interest in the problem of accented characters. There was less danger of software being passed 8-bit data. (Examples were found of software which actually crashed if it was presented with 8-bit data, although it would be amazing if there was any such software left seven years on.) Many people felt that even if the recipient's mailer wasn't MIME capable it was better for him or her to see thingies like "=E1" than to risk having accented characters deleted or having their eighth bit stripped. So BOTH proposals were accepted. It is legal MIME to have messages headed with: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable and it is just as legal to have messages headed with: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit It is important to realise this, because many people first learn about MIME when they see QP thingies like "=E1" and wrongly assume that MIME is synonymous with QP. The future seems rosy, though, with the transition being aided by cleverer MTA's which look inside the message body and convert MIME transfer encodings on the fly. Sendmail version 8.7, which was released a year ago, sends 8bit messages unchanged if the recipient host announces that it is prepared to accept 8bit, and converts them to QP otherwise. Thus it gives MUA's on that host the liberty to compose 8bit messages with the assurance that any problems will be taken care of by the MTA. Sendmail version 8.8, released a month ago, does the reverse conversion, QP to 8bit, of incoming messages if it is set up to do so. Sendmail and GAELIC-L --------------------- Sendmail 8.7.5 was installed on Danann a month or two ago, replacing the old non-ESMTP-compliant version of Sendmail. So Danann is now being very helpful. It is passing 8bit messages unchanged if it is safe to do so and is converting them to QP otherwise. (This can be unfortunate for people who are on systems which are 8-bit clean but which don't anounce it, but such people should increasingly be in the minority.) What would be better still is if Danann was upgraded to Sendmail 8.8 now that it is available. This would mean that when GAELIC-L moves MIME, members on systems which declared themselves able to accept 8bit would receive GAELIC-L messages in 8bit even if they had originally been posted in QP. It would make "value-added" processing of GAELIC-L messages simpler. e.g. The "GAELIC-L -> GAELIC-S" program which I should be writing right now to convert MIME to slashes would be very much simpler if it only had to deal with 8bit instead of both 8bit and QP. GAELIC-L messages would appear correctly on systems such as the University of the Highlands and Islands Project's FirstClass system which are 8-bit clean but not MIME compliant. Caoimhín 1996-10-29