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: Content-Length: (was: binmail vs MMDF mail file format)
Message-ID: <8914@chinet.chi.il.us>
Date: 10 Jul 89 03:12:37 GMT
References: <8887@chinet.chi.il.us> <1597@cbnewsc.ATT.COM> <114277@sun.Eng.Sun.COM>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 78

In article <114277@sun.Eng.Sun.COM> island!argv@sun.com (Dan Heller) writes:
[Re: Content-Type: & Content-Length: headers used by AT&T PMX mailer ]

>It's obvious that we know nothing about the proposed scheme right now.
>Les didn't give much information at all and I would like more -- a lot
>more.

Perhaps a more knowledgeable source can supply the details.  I only know
about the headers by observation of the technique used by the PMX-Starmail
package where the MUA is a DOS program that talks over the starlan network
to a unix server where the messages are handled by a slightly modified
/bin/mail. The MUA has a built-in editor that allows you to enter normal
message text and you can attach files with the ability to specify the type
of file (text or binary) or you can let it decide for you.  Each portion
(message text and file attachment(s)) is preceded by a Content-Type:
and Content-Length: header, followed by one blank line that is not counted
in the Content-Length.  If there is more than one portion, an additional
Content-Type: Multipart and Content-Length: that covers the entire item
is added at the beginning.  There are some additional headers used for
file attachments to specify the original filename, an optional description
and perhaps some things that would be used by AT&T's Document Exchange
program that converts among various formats.  Some other headers can be
added according to the filename extension to identify the "type" of the
file so the MUA can start the proper program if you want to view a non-text
attachment.  This scheme suffers from the usual DOS memory limitations. 

>However, I am speculating that this scheme is not intended for
>MUAs at all.  It is probably intended for MTAs that are compatible.
>If the MTAs are not compatible, then it either doesn't send the mail
>(probably the case for the 8-bit binary mode) or it tries some sort of
>conversion from its current format to a well-known one.

Actually both, since the MUA uses the headers to do the correct thing
when the user wants to detach or view a binary attachment.  The MTA
only uses them to decide if the next hop is binary-compatible.  It does
have to go to some lengths to insert the headers into messages where
the MTA did not.

>Ok, so the message goes off to the remote site and it indeed has the
>compatible MTA that understand content-length, so the messages it gets
>is deposited into the recipient's mbox.  Now, what does the MUA do with
>it?  Does this also require an MUA that knows content-length?  And if
>so, what does it do about error recovery?  Gregg points out that the
>user could have edited his messages.  What then?

If the message is handed to a /bin/(r)mail that doesn't know about
Content-Length: it will have any From_ lines munged into >From_
as usual so the MUA face of /bin/mail won't be confused (but you
also don't get the exact contents that were sent).

>I think the content-lenth: and type are fine ideas as long as they
>are restricted to the MTA and that the MTAs are compatible.  but,
>assuming that the MUA understands the MTA is a -big- mistake.  The MTA
>should also prepare itself to convert its "message" into a format which
>is RFC822 compliant in case it talks to an MTA that isn'nt compatible
>with the originating MTA.

I think messages with binary attachments are bounced if you attempt
to send to a site that doesn't understand them (there is a table of
sites known to handle them).  I see no reason why they couldn't be
automatically encoded with a human-readable header showing the format.
You can specify to the PMX MUA that all attachments should be encoded
using btoa, but this increases the size by about a third. Other than
binary attachments, the headers shouldn't affect RFC822 compliance.

>Les' original question to me was: can Mush handle that?  My response
>is the question I posed above: What should it do if content-length:
>doesn't reprepsent the content length?  I need more "spec".

In that case there has obviously been an error in storing your mailbox
file, so the proper thing to do is to generate an error message and
try to recover by finding a likely-looking From_ line.  The most likely
problem would be a line starting with "From" that an MTA changes to
">From" after you calculate the length.  If you are interested in pursuing
this, I can generate some sample headers (or perhaps someone who knows the
"spec" can comment).

Les Mikesell