Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!sun-barr!newstop!sun!eureka!argv From: argv%eureka@Sun.COM (Dan Heller) Newsgroups: comp.mail.misc Subject: Content-Length: (was: binmail vs MMDF mail file format) Summary: need more info Message-ID: <114277@sun.Eng.Sun.COM> Date: 7 Jul 89 17:48:18 GMT References: <8887@chinet.chi.il.us> <1597@cbnewsc.ATT.COM> Sender: news@sun.Eng.Sun.COM Reply-To: island!argv@sun.com (Dan Heller) Lines: 47 In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > From article by les@chinet.chi.il.us (Leslie Mikesell): > > AT&T's PMX mailer products include a new /bin/mail that uses > > Content-Type: and Content-Length: headers to avoid the problem. > .. 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! 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. 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. For example, if I were to mail myself a folder using this new /bin/mail program, then I'm sure it would count the number of bytes in the folder, add the Content-Lenth: header and then send it off to the other site. Note that the folder I sent has other messages in it that also have Content-Length: headers. But the -real- content-length header will be the only one read. 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? 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. 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". dan ----- My postings reflect my opinion only -- not the opinion of any company.