[comp.mail.elm] Attached Documents

dougw@fdls.odag.or.gov (Doug Walker) (04/26/91)

I have been asked if a document (both ASCII and binary) can be attached to a
piece of elm mail.  I don't see any references to this feature in the elm man
pages, but I'm hoping I've missed the feature reference.

If not, can anyone point me to any other software products that might work
with elm to accomplish this task.

Thanks for the assist.


-- 
-----------------------------------------------------------------------------

Doug Walker               uunet!fdls!dougw  -or-  dougw@fdls.odag.or.gov
Oregon Department of Agriculture, Salem, Oregon           (503) 378-3790

chip@osh3.OSHA.GOV (Chip Yamasaki) (04/29/91)

In <354@fdls.odag.or.gov> dougw@fdls.odag.or.gov (Doug Walker) writes:

>I have been asked if a document (both ASCII and binary) can be attached to a
>piece of elm mail.  I don't see any references to this feature in the elm man
>pages, but I'm hoping I've missed the feature reference.

Well, we are using Elm here and had wanted to do the same.  No, Elm
doesn't support it, but they don't stop you from doing it either.

The approach I would take would be to say that included files will be
supported only in your own mail system.  Then define your mail system as
being whatever MTA you use, and as the UA, specify Elm, a programmable
editor like Emacs, and a customized (hacked) version of any of several
pagers for which you have the source.

You could support attached files much the same way Elm supports encoded
sections in files.  That is with [encode] and [clear] lines.  For your
application you could insert a [attachment]-[end-attachment] pair using
a syntax similar to:

[attachment] <decode command>
...
attached file
...
[end-attachment]

The attachment would introduce the attached data to your customized
portions of the UA.  The decode command could be virtually any command
you wanted to use to make the file suitable for inclusion in an RFC 822
format message.  I would recommend sticking with something basic like a
compressed shar or maybe an encoded-compressed-tar.

Then you take your pager, something well written, tested, and flexible
like Larry Wall's less, and insert code to make it handle this
attachment.  You could have it collapse that part of the message and
simply display something like:

--- Attached files ---

And if you stuck to one very strict standard for encoding the files to
be attached like the encoded-compressed-tar you could even add an option
to list the attached files by name and size using:

(uudecode <att | compress -d | tar tvf - | sort [flags])

Now that your pager supports displaying the attachments, you have to
support extracting them.  You add a command to extract the attachments
to the pager.  This command would just chop that portion between the
markers and send it to the <decode command> in the [attachment] marker
(or to the standard decoding sequence if you make a fixed sequence like
decode-decompress-untar).

Finally, you write the scripts for the editor.  You will want a highly
programmable editor like Emacs for this.

You write a script to be executed on entry to the editor.  This script
would strip any [attachment] blocks from the message buffer and leave
just a temporary marker (maybe with the name of another buffer where you
keep the attachments). 

Write another script to be executed on exit from the editor.  This would
rebuild the message by removing the temporary markers and replacing them
with the attachment.

Finally, you write any attaching scripts and user interfaces you want. 
If you just want a simple command that prompt for a filename, pack the
file, store it in a buffer, and place a temporary marker in the message,
fine.  If you want a fancy menu that will let the user select multiple
files and pack them all that is good too.

To the best of my knowledge that would do it.  I may actually do this
myself "someday" if a freely available mail UA does not support it.  The
problem is it would have to be better than Elm and that's (IMHO) a tough
act to follow.

There would still be a few things to watch out for.  Bouncing a message
should not cause a problem, but when forwarding a message your editor
script that is run on entry would have to strip the "included text"
markers (I mean the > character at the beginning of each old line) from
the attachment section.  Another thing would be message size.  Many mail
MTAs specify that there is a definite limit to the size of the message
that will be transferred.  In some HORRIBLE but rare situations it is as
small as 10K, but most are 64-100K at least.  This would take a serious
workaround.

>If not, can anyone point me to any other software products that might work
>with elm to accomplish this task.

I don't know of any.

If anyone out there does actually implement something like I'd like to
hear about it.  Likewise, if someone has already implemented something
like this I'd like to hear about it even sooner :-).  Also, if there are
ano major problems with this solution, please follow-up, I'd like to
know.
-- 
--
Charles "Chip" Yamasaki
chip@oshcomm.osha.gov