tmoore@coss.Dayton.NCR.COM (Tom Moore) (09/20/90)
I am looking for a way to attach one or more items in a mail message. Such attachments could be arbitrary, binary data. The intent is to provide the functionality in a UA to implement a command such as attach filename ... and have the UA append the properly formatted attachment to the message. Properly formatted implies any processing needed to convert the specified file(s) to an ascii format if necessary and then delimit it in some fashion to show the bounds of the attachment. The information that should be included as part of the attachment would be what it is (word processor file, spread sheet, etc) and what was used to process it for mailing (uuencode, compress + uuencode, nothing, etc). The recipient UA would have a command such as detach [attachment_identifier] which would examine the information describing the attachment and then extract and store it as a separate file in its original form. As a matter of implementation, the above functionality would not need to be contained within the UA itself. A stand-alone command called from the editor during message generation and a similar command to which the recipient could pipe the message would do nicely. I am considering the use of the message encapsulating scheme proposed in RFC934 as a way to delimit the attachments and providing headers within each attachment to convey the necessary information about the attachment. The Content-Type header of RFC1049 is being examined as a standard header that could possibly be used but it appears more suited for providing information on how to post-process and display textual data than on how to unpackage and store it. I would appreciate any assistance in implementing this in a standard manner. If an existing standard implementation of this functionality already exists, I would happily use it. If not, I would like to implement a procedure that is useful to as large a community as possible. Please respond via news or mail as you deem appropriate. -- * Tom Moore NCR Corporation PCD-6 (513) 445-1373 * * Consulting Analyst 1700 S. Patterson Blvd. VOICEplus 622-1373 * * Network Applications Dayton, OH 45479 Tom.Moore@Dayton.NCR.COM *
les@chinet.chi.il.us (Leslie Mikesell) (09/21/90)
In article <637@coss.Dayton.NCR.COM> Tom.Moore@Dayton.NCR.COM writes: >I am looking for a way to attach one or more items in a mail message. >Such attachments could be arbitrary, binary data. The intent is to >provide the functionality in a UA to implement a command such as > attach filename ... Please look at the AT&T PMX-mailer products for an implementation of multi-part messages that is reasonably compatible with standard mailers (address handling is a whole different story...). I'd love to see something like this standardized. It is extremely handy in an office automation environment, especially if the users are running PC applications that tend to use proprietary file formats. They use an optional Content-Type: header and a required Content-Length: header where the length is the number of characters after the blank line that seperates the header and body. If the Content-Type is Multipart, then the first Content-Length: refers to the entire message which is broken into pieces, each with its own Content-Type:, Content-Length:, and optional additional headers of Content-Name:, Content-Abstract:, Encoding-Type: and Encoding-Algorithm. >and have the UA append the properly formatted attachment to the message. >Properly formatted implies any processing needed to convert the specified >file(s) to an ascii format if necessary and then delimit it in some >fashion to show the bounds of the attachment. It would be nice it the MTA knew about hosts that could handle straight binary attachments and perform automatic btoa or uuencoding only when necessary. AT&T's product knows (i.e. you have to make a list) but it just bounces anything binary sent to a non-binary host instead of doing the simple conversion. Being able to handle straight binary or compressed data is important in a widely distributed environment (LD phone calls but not enough to a single point to justify Trailblazer modems). >As a matter of implementation, the above functionality would not need to >be contained within the UA itself. A stand-alone command called from the >editor during message generation and a similar command to which the >recipient could pipe the message would do nicely. I'd recommend putting it in the UA if at all possible. If you ascii-fy everything it could be done inside the editor. Otherwise an editor front-end could be used, running the editor for the text portions and doing the attachments directly (that part is pretty trivial). Also, you would want the detaching command to be interactive to allow choosing each piece of a multipart message seperately. Most current UA's won't deal with binary attachments anyway. Everyone likes to make tmp copies using fgets() and fputs(). So, you either need to modify the UA or encode everything. And, if you are going to modify the UA, you might want to add FORMS mode as well. >I am considering the use of the message encapsulating scheme proposed in >RFC934 as a way to delimit the attachments and providing headers within >each attachment to convey the necessary information about the attachment. >The Content-Type header of RFC1049 is being examined as a standard header >that could possibly be used but it appears more suited for providing >information on how to post-process and display textual data than on how to >unpackage and store it. No, you need to know the difference between text and binary types in order to detach them if your machine happens to have a different concept of text files. The Content-Length: header is the critical one, though, and the MTA's involved need to be coaxed into leaving the body of the message alone (i.e. don't change lines starting with From into >From, etc.), and where possible, handle the binary portions without unecessary expansion. >I would appreciate any assistance in implementing this in a standard >manner. If an existing standard implementation of this functionality >already exists, I would happily use it. If you can't get information about the AT&T PMX-mailers, I can send you some sample headers. I also have some hacks (working, but by no means elegant) for Smail 3.1 to make it insert the Content-Length: headers for local deliveries and a few other things to make it cooperate with the PMX UA's. Les Mikesell les@chinet.chi.il.us