argv%eureka@Sun.COM (Dan Heller) (07/08/89)
In article les@chinet.chi.il.us (Leslie Mikesell) writes: > In article 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. > > > Once again > >another format has been chosen that absolutely solves nothing! > Of course you can destroy the structure by using a normal editor on > the mailbox file but why would anyone do that? 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. Consider when someone sends you a 30 page document and you just need 1 page of it; 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. > You can confuse any > other MUA by adding or deleting some From_ lines. Why is this any > worse? As I'm sure it's true with "any other MUA", Mush will allow you to edit a message and when you're done, it makes sure that you have not added any new "message separators" (e.g. From_ or ^A^A^A^A or ^C or whatever your MTA uses) --if you did, it precedes the line with a '>' (it doesn't matter what character you put there, the line must be modified). It also checks to see that you left the legal rfc-822 headers in. the point is, that you can allow message editing and keep sanity *given* the sanity of the system you've got to work with. > 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. 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. dan <island!argv@sun.com> ----- My postings reflect my opinion only -- not the opinion of any company.
les@chinet.chi.il.us (Leslie Mikesell) (07/10/89)
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