From xemacs-m  Thu Feb 27 20:29:27 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 UAA11004
	for <xemacs-beta@xemacs.org>; Thu, 27 Feb 1997 20:29:23 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQceub04174; Thu, 27 Feb 1997 21:29:24 -0500 (EST)
Date: Thu, 27 Feb 1997 21:29:24 -0500 (EST)
Message-Id: <QQceub04174.199702280229@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.211615edt.10829(3)@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>
	<QQcety03441.199702280136@crystal.WonderWorks.COM>
	<97Feb27.211615edt.10829(3)@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:
 > > 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.
 > 
 > How about 3 levels:
 > 1) when you currently use QP:
 > 	the QP encoding that you currently use,
 > 2) <1/6 needs quoting:
 > 	use QP encoding, but you add \n -> =0A=\n so it is still
 > 	readable but safe,
 > 3) >1/6 needs quoting:
 > 	use base64

We're talking about bodies with NULs in them.  How often does
that happen in textual data?  I don't have a problem with these
bodies being unilaterally base64 encoded, since such bodies are
usually images, audio, Word for Windows gobbledegook files, etc.
The rare text file will be base64 encoded, true, but wasting time
counting characters just to avoid this doesn't seem worth it.

