Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.misc
Subject: Re: More PMX mail (was: binmail vs MMDF mail file format)
Message-ID: <8915@chinet.chi.il.us>
Date: 10 Jul 89 03:35:45 GMT
References: <8887@chinet.chi.il.us> <1597@cbnewsc.ATT.COM> <8896@chinet.chi.il.us> <114439@sun.Eng.Sun.COM>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 40

In article <114439@sun.Eng.Sun.COM> argv@sun.com (Dan Heller) writes:

>I don't subscribe to the policy of editing email messages, but it's
>done all the time, you you can't do anything about it.

The PMX MUA's allow you to edit the body of the text and some of the
headers.  The Content-Length is adjusted automatically as necessary.
The messages are stored in individual files as they are retreived from
the mailbox anyway, though, so there is no need for the length information
after retreival except for multiple attachments.

>or when someone sends you a phone number and you edit the message to
>change the subject to have the phone number in it so you can see it
>when you display headers... the list goes on.

Content-Length: refers only to the body of the message and attachments.
Headers are not included in the length.

>In my opinion, the resolution to this problem will be determined by the
>MTA that is shipped -off the shelf- with a unix system.  And I should
>probably amend to that: any "popular" unix system.  That is, if BSD4.4
>and/or AT&T S5R4 came out with a new MTA that did things differently,
>we might see some changes.  But until that happens, the world will change
>very little for most of us.  The introduction of the Content-* headers
>is something entirely different from this -- once those messages get to
>a system that doesn't use that MTA, then those headers have as much value
>as pesos in Canada.  Even with those new headers, the folder format that
>the MTA uses appears to be as it currently is.

I'll have to look at a text-type attachment to see if it disallows
lines starting with "From".  If so, multi-part messages with text
attachments would be compatible with standard mailers, you would just
see them as a single message with extra headers inserted if you
use an MUA that doesn't understand them.  Since AT&T is probably the
only one that can get away with providing a new /bin/mail along with
a MUA, the only way for anyone else to provide a compatible binary
file transport would be to emulate the btoa-encoded mode (I'll have
to try that to see how it works).

Les Mikesell