1994-08-30 - Re: Statistics on remail message sizes

Header Data

From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
To: cypherpunks@toad.com
Message Hash: 0b85be35f1f6f71f5f98d7d3e219235198dd5d8d527bcd711617a5b50cc5087b
Message ID: <9408300718.AA21999@anchor.ho.att.com>
Reply To: N/A
UTC Datetime: 1994-08-30 07:22:09 UTC
Raw Date: Tue, 30 Aug 94 00:22:09 PDT

Raw message

From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Tue, 30 Aug 94 00:22:09 PDT
To: cypherpunks@toad.com
Subject: Re: Statistics on remail message sizes
Message-ID: <9408300718.AA21999@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text/plain


> I think you are;  My point was much more trivial than that;  I'm just
>  suggesting that the 1,4,16,64 be extended to 256, 1024, 4096,...

I agree with this; one of the reasons that 64K tends to be a max is
that a non-trivial number of mailers choke on messages larger than that.
In the future, when there's more competent mail software (:-),
I wouldn't be surprised to see 1MB being common (or 1.44 MB, if that
stays the popular floppy disk size for a few years...), though I suspect
there's not much need for 256KB messages.

One approach suggested by several other people is for fragmenting mail
into packets before remailing and reassembling on delivery.
Some variants on this suggest having the remailer network do it,
but I suspect it's more reliable on an end-to-end basis.


-- end of real contents

My comment about "competent mail software" is partly prompted by
having to use Microsoft Mail which can handle large attachments
to messages, but chokes on displaying simple ascii messages over 64K...

> L. Todd Masco  | "Which part of 'shall not be infringed' didn't
> cactus@bb.com  |   you understand?"

Let's see - "shall" is future tense, right - why are there predictions
of the future in a political document ?  :-)

----

		Bill





Thread