From xemacs-m  Fri Apr 11 14:41:56 1997
Received: from master.control.att.com ([135.205.52.13])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id OAA11930
	for <xemacs-beta@xemacs.org>; Fri, 11 Apr 1997 14:41:55 -0500 (CDT)
Received: from i.control.att.com by master.control.att.com with esmtp
	(Smail3.1.29.1 #3) id m0wFm27-002ixCC; Fri, 11 Apr 97 15:30 EDT
Received: by i.control.att.com (Smail3.1.29.1 #1)
	id m0wFm27-000mUTC; Fri, 11 Apr 97 15:30 EDT
Message-Id: <m0wFm27-000mUTC@i.control.att.com>
Date: Fri, 11 Apr 97 15:30 EDT
From: Larry Auton <lda@control.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Kyle Jones <kyle_jones@wonderworks.com>
Cc: bug-vm@uunet.uu.net, xemacs-beta@xemacs.org
Subject: Unsupported MIME version ?
In-Reply-To: <QQckvr04971.199704111854@crystal.WonderWorks.COM>
References: <m0wFlFy-000mUTC@i.control.att.com>
	<QQckvr04971.199704111854@crystal.WonderWorks.COM>
X-Mailer: VM 6.24 under 20.1 XEmacs Lucid (beta14)

Kyle Jones writes:
> Larry Auton writes:
>  > Several of the messages that I've received from xemacs-beta contain
>  > headers that look like this:
>  > 
>  > Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.75)
>  >  boundary="Multipart_Mon_Apr__7_14:04:13_1997-1"
> 
> Solaris MTA bug (burn in hell, burn in hell).  I think I've seen
> enough of these reports to just default vm-mime-ignore-mime-version
> to t in 6.25.

I (setq vm-mime-ignore-mime-version t) and sure enough it works,
but if it's such a common problem why not retain the "sanity check"
and fix the parsing of the Mime-Version header?

-lda

