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