On Fri, 25 Oct 1996 17:04:01 -0400 Jeff Kell <[log in to unmask]> said:
 
>I'm not sure where to point fingers here... is this a LSoft problem, the
>origin mailer, or an RFC ambiguity?
 
I see multiple problems here.
 
1. The basic premise of MIME is that you shouldn't need to have to update
   MTAs all over the  network in order for MIME to  work. This means that
   the fields you generate, which  will be interpreted as unknown/comment
   fields by MTAs which don't have any specific support for MIME, need to
   be written  in such  a way that  they still work  when treated  like a
   comment field by  a MTA, because this is exactly  what will happen. If
   you put a space in a comment  field, you have to expect that the field
   may be  folded at this  location. Comments  are defined as  '*text' in
   RFC822,  and  the  definition   of  'text'  specifically  states  that
   "quoted-strings  are  NOT recognized"  (emphasis  not  mine). So,  you
   should  not put  spaces  in MIME  fields where  you  wouldn't get  the
   correct/expected results if the field were folded at this location.
 
2. Due to #1,  most MTAs do not have any specific  support for MIME. Even
   new MTAs are likely to treat MIME fields like any other regular field,
   because they don't  need to do any special processing  on them. Indeed
   there  are a  lot  of people  who  think that  MIME is  a  MUA to  MUA
   convention and MTAs  should not get involved (and a  lot of people who
   think  otherwise). Not  treating MIME  fields in  any special  way is,
   however, clearly allowable.
 
3. Some MTAs do have specific  MIME support because their authors decided
   that it  was appropriate for  the MTA  to rewrite MIME  messages under
   certain  circumstances  (which  is  a controversial  point,  as  noted
   above). You then get errors like:
 
553 header syntax error, line "              =_0_MIME_Boundary_21244.3270e308.i
mhwt300.dcuh029.dcu.ps.net"": No such file or directory
 
   553 is a  fatal syntax error, which incidentally is  not allowed after
   DATA.  Either way  it means  that the  message will  NOT be  delivered
   because the MIME-capable  MTA has decided that the  recipient will not
   be able  to make any  use of it.  As a matter  of fact the  message in
   question was plain text and, while it might not have looked as nice as
   if the problem were not present,  it is definitely readable by a human
   being. Unfortunately the in-transit MTA  took it upon itself to bounce
   the message, instead  of letting the receiving MUA  decide whether the
   message  is usable  or not.  This seems  totally inappropriate  to me,
   especially as  the recipient might  not even have  a MIME MUA  and the
   field in question might be totally meaningless to the MUA being used.
 
  Eric