🚀 go-pugleaf

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