From xemacs-m  Thu Feb 27 19:36:32 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id TAA10856
	for <xemacs-beta@xemacs.org>; Thu, 27 Feb 1997 19:36:31 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQcety03441; Thu, 27 Feb 1997 20:36:32 -0500 (EST)
Date: Thu, 27 Feb 1997 20:36:32 -0500 (EST)
Message-Id: <QQcety03441.199702280136@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Re: Bug in vm
In-Reply-To: <97Feb27.200413edt.10827(2)@jupiter.scs.Ryerson.CA>
References: <199702271328.OAA09887@daedalus.tnt.uni-hannover.de>
	<kigene2xsje.fsf@jagor.srce.hr>
	<QQcetr02047.199702272348@crystal.WonderWorks.COM>
	<kiglo89u78u.fsf@jagor.srce.hr>
	<QQcett02558.199702280027@crystal.WonderWorks.COM>
	<97Feb27.200413edt.10827(2)@jupiter.scs.Ryerson.CA>
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

Dave Mason writes:
 > Kyle Jones writes:
 > > Hrvoje Niksic writes:
 > >  > Is this a MIME requirement, or a VM design decision?  Heiko's message
 > >  > could have been encoded quoted-printable just fine.
 > > 
 > > Mostly an accident.  There's one routine that looks at a message
 > > and decides what the non-opaque transfer encoding should be.  It
 > > returns "7bit", "8bit" or "binary".  There's another routine that
 > > uses that return value and decides what the final transfer
 > > encoding should be.  This routine doesn't get any information
 > > about NULs or anything else; it only knows that the non-opqaue
 > > encoding is "binary".  The only safe encoding for binary data is
 > > BASE64, so that's what it uses.
 > 
 > Surely not.  I don't know the whole spec, but I don't see why
 > quoted-printable can't encode a binary file.... it won't be a very
 > *efficient* encoding, perhaps.

I should have said that it would not be safe using VM's QP
encoder, which doesn't convert newlines to =OA.  If you don't
convert all newlines to =OA the newlines that sendmail encounters
will be converted to CRLF pairs for SMTP.  This will corrupt
binary data if the remote side doesn't use the same newline
convention.

