On Fri, 15 Nov 1996 14:51:22 -0500 Jeff Kell <[log in to unmask]> said: >I don't know if Listserv, Worldtalk, Netscape, or HP Sendmail is >broken/non-conforming/whatever, but I thought those of you affected >might want to be aware of the problem. One of the cornerstones of MIME is that existing mail servers do not need to be changed in order to allow MIME-capable mail readers to exchange MIME messages. Actually, this is probably THE cornerstone of MIME's design. When a mail server that doesn't know anything about MIME gets a message with one of the new MIME fields, it treats the MIME fields as (obviously) unknown tags, or "user-defined field" as the standards call them. The proper way to treat an unknown field is (RFC822, 4.7.5): 4.7.5. USER-DEFINED-FIELD Individual users of network mail are free to define and use additional header fields. Such fields must have names which are not already used in the current specification or in any definitions of extension-fields, and the overall syntax of these user-defined-fields must conform to this specification's rules for delimiting and folding fields. I'll spare you the details, but the rules for folding fields is that wherever there is white space, you can fold the field by inserting CRLF followed by one or more white space characters. So, this is what mail servers that have no specific MIME support will do to a MIME message, and a lot of time and effort has been spent designing MIME so that this sort of thing would work, for the simple reason that waiting until ALL mail servers were updated was felt to be unacceptable. Since this has yet to happen :-), it is difficult to challenge the wisdom of this decision. To achieve this goal, there are a couple of things the mail program cannot do. One of them is to create MIME fields which do not survive the standard RFC822 folding rules because they use white space in a manner where the number and type (SPACE vs TAB) of white space characters is significant. Boundaries are random, computer-generated strings that are extremely unlikely to occur in normal text, and there is no technical need to use the SPACE character in the alphabet the random boundary generator uses. In correct English, this is called "asking for trouble without the beginning of a reason". There are also things that mail servers that choose to implement specific support for MIME must not do. One of them is to refuse to process messages which (they think) contain incorrect MIME fields. Such a design raises a number of serious problems: 1. Standards change all the time. Perhaps something which is not a valid MIME construct today will become one tomorrow. This might require a new mail reader in order to take advantage of the new functionality, but now it suddenly requires a new mail server as well. This may be good for the vendors, but it certainly isn't good for the users. 2. Software can have bugs. Perhaps the mail server is just plain wrong and the header is perfectly valid. 3. Even if the MIME message IS broken, there may still be something that can be saved. Actually, in most cases the message will contain a majority of plain ASCII text, which can be viewed without MIME processing. At the very least, the sender's e-mail address (which is never MIME encoded) will be available, and it will be possible for the recipient to contact this person and ask what is going on. Besides, the recipient might not even have any kind of MIME suppport. The MIME fields, valid or invalid, might be "random computer garbage" to the recipient in the first place. The correct behaviour when a MIME error is detected in the message would be to abort any special MIME processing and revert to the normal, generic, non-MIME message forwarding/relaying function. In other words, act like the hundreds of thousands of mail servers that don't even know what "MIME" stands for. Given MIME's design, this guarantees that the message will be processed properly if it was valid in the first place. In the worst case, a human will still be able to read the message and figure out what went wrong. It is difficult to find a valid justification for simply throwing the message on the floor. The most likely explanation is that the programmer either did not think about the implications, or was, ah, working on too tight a deadline to implement things correctly :-) Eric