[9fans] 64KB wall for sendmail

[9fans] 64KB wall for sendmail

[forsyth]

there will be a problem sending email larger than 64k whether
utf or not if you don't
	chmod 777 /mail/tmp
so that upas can drop the remainder of larger messages there.
after that, you can send and receive megabytes happily, until you get the phone bill.
the only restriction (i think) is that the header must fit in the first
64k.  that's usually not a problem even with chatty rfc822+mime.

[9fans] 64KB wall for sendmail

[okamoto]

>utf or not if you don't
>	chmod 777 /mail/tmp

Yes, you are right.
I noticed this through to get it work, although I forgot to metion it
in my boddle file.

The problem I had was I could not end the cat_mail() after it must
have done the work.  Then, I put a line at its end to write a dummy
character ('\n') to the file "/mail/tmp/mtxxxxxx", which solved the
problem.
However, I don't know why.

Kenji

[9fans] 64KB wall for sendmail

[okamoto]

Thanks Dave.

I had, fortunately, success to deal with larger Japanese JIS coded files
than 64 K bytes with upas system with 64K bytes virtual memory version.
I put the boddle file to our usual home page
(http://basalt.cias.osakafu-u.ac.jp/plan9/p9index.html), which is written
in UTF-8.  In additon, the libtcs has also been updated.

I noticed, this is my first time, the larger file problem occurred when I
wrote an introductory article on Plan 9 and tried to send/receive that text
with a magazine publisher. :-)  The article exceeds 80Kbytes in its file size
with a figure. ^_^

Kenji

[9fans] 64KB wall for sendmail

[presotto]

This is a multi-part message in MIME format.
--upas-mleuiqdgkckspadxueufqpumdy
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

not really.  it probably wouldn't even affect speed much.

--upas-mleuiqdgkckspadxueufqpumdy
Content-Type: message/rfc822
Content-Disposition: inline

Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Nov  4 21:29:04 EST 1999
Received: from cse.psu.edu ([130.203.3.50]) by plan9; Thu Nov  4 21:29:03 EST 1999
Received: from localhost (majordom@localhost)
	by cse.psu.edu (8.8.8/8.8.8) with SMTP id VAA11353;
	Thu, 4 Nov 1999 21:10:29 -0500 (EST)
Received: by claven.cse.psu.edu (bulk_mailer v1.5); Thu, 4 Nov 1999 21:09:16 -0500
Received: (from majordom@localhost)
	by cse.psu.edu (8.8.8/8.8.8) id VAA11282
	for 9fans-outgoing; Thu, 4 Nov 1999 21:09:10 -0500 (EST)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from granite.cias.osakafu-u.ac.jp (granite.cias.osakafu-u.ac.jp [157.16.91.52])
	by cse.psu.edu (8.8.8/8.8.8) with SMTP id VAA11278
	for <9fans@cse.psu.edu>; Thu, 4 Nov 1999 21:09:02 -0500 (EST)
From: okamoto@granite.cias.osakafu-u.ac.jp
Message-Id: <199911050209.VAA11278@cse.psu.edu>
To: 9fans@cse.psu.edu
Date: Fri, 5 Nov 1999 11:08:28 +0900
Subject: [9fans] 64KB wall for sendmail
MIME-Version: 1.0
Content-Type: Text/Plain; CHARSET="UTF-8"
Sender: owner-9fans@cse.psu.edu
Reply-To: 9fans@cse.psu.edu
Precedence: bulk

The upas system has 64Kbytes trick for sending/receiving files
fast.

However, it's designed for UTF-8 files, and pain to apply the
same method to other code set, such as ISO-2022-JP.

What  a serious problem could arise, if I remove this 64Kbytes
cache system,?

Kenji
--upas-mleuiqdgkckspadxueufqpumdy--

[9fans] 64KB wall for sendmail

[okamoto]

The upas system has 64Kbytes trick for sending/receiving files
fast.

However, it's designed for UTF-8 files, and pain to apply the
same method to other code set, such as ISO-2022-JP.

What  a serious problem could arise, if I remove this 64Kbytes
cache system,?

Kenji