Path: utzoo!attcan!uunet!lll-winken!ctrsol!cica!tut.cis.ohio-state.edu!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.misc
Subject: Re: binmail vs MMDF mail file format
Message-ID: <8896@chinet.chi.il.us>
Date: 8 Jul 89 05:44:56 GMT
References: <8887@chinet.chi.il.us> <1597@cbnewsc.ATT.COM>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 31

In article <1597@cbnewsc.ATT.COM> gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes:

>> AT&T's PMX mailer products include a new /bin/mail that uses
>> Content-Type: and Content-Length: headers to avoid the problem.

>This is just plain gross!  Last I knew, the MTA was the one attaching
>this information.  What is the poor MUA (for their /bin/mail, the
>asnwer is...  If the text following Content-length bytes is not "From",
>seek back to Content-length and do normal "look for the From line"
>processing see, great solution :-() going to do with a file that has
>been altered by an unknowing editor (like vi or emacs)?  Once again
>another format has been chosen that absolutely solves nothing!

The MTA only attaches it if it isn't already there (i.e. with the
PMX products the MUA does attachments and adds the headers, although
the PC programs are sort-of MTA's also).

Of course you can destroy the structure by using a normal editor on
the mailbox file but why would anyone do that?  You can confuse any
other MUA by adding or deleting some From_ lines.  Why is this any
worse?  Personally, I'd like to see MTAs keep each message in a separate
file which would eliminate the problem of finding the start of the next
message and would allow links to be used for group messages.  Anyway,
the headers *do* solve two problems: (1) how to have multiple attachments
to a mail message and (2) how to identify the content of the message
or attachment in order to resolve possible conversions needed by the
recipient.  For example, text going between unix and dos machines should
have the line endings modified for the local conventions, but binary
attachments should not. 

Les Mikesell