Created attachment 5695 [details]
Patch

The attached patch (against the CVS of Sept. 25, 2001) implements
basic support for handling of message/external-body parts in received
mails.

Basically, it shows a new "action window" if one of these parts is
selected, depending upon the access-type. The context menu (right
mouse click on icon) is not supported.

For the ftp, tftp, anon-ftp and local-file access types, an URL is
generated and passed to gnome_url_show() (use the control center to
make gnome call something useful...). The URL's look as follows
(replace <something> with the value of parameter something):

- ftp, anon-ftp: ftp://<site>/[<directory>/]<name> (Note: this does
not take care of the user and password fields, so ftp and anon-ftp are
not distinguished. Fix necessary?)

- tftp: tftp://<site>/[<directory>/]<name>

- local-file: file:<name>

For the mail-server access type, a new message is generated upon
request and sent to <server> with subject <subject> (if present). The
body of this message containes the phantom body of the received part,
but with everything up to and including the first two consecutive
newlines stripped (this is my -hopefully correct- interpretation of
RFC 2046...).

The latter method could be improved by checking the Content-ID fields
of all received messages against the value in the phantom body to
check if an external body was already transmitted. Not sure if it
makes sense...


CODE DETAILS
============

The only file with changes is src/balsa-message.c.

* define two new functions part_context_menu_call_url() and
  part_context_menu_mail() to actually do the calls (they are not part
  of the context menu, though)

* define new data types and a static array of the RFC 2046 access
  types

* [new function] part_info_init_message_extbody_url() generates the
  URL from the data of the part's parameters and displays an
  informative message plus a button to call this URL to obtain the
  data

* [new function] part_info_init_message_extbody_mail() displays an
  informative message plus a button to send the mail to obtain the
  data

* part_info_init_message() scans the paramter access-type to select
  the corresponding routine above. If the access type is not not
  present or not defined by RFC 2046, fall back to the current
  behaviour

* [new function] part_context_menu_call_url() just calls the URL
  generated above

* [new function] part_context_menu_mail() generates a new mail and
  sends it

Just out of curiosity, what about adding message/external-part to
composed message?

The patch has been commited. Thanks!

First, thanks for committing the patch.

Regarding your question if we should add support for *sending*
external-body parts from balsa: I am not sure if this makes sense... I
sometimes (actually not very often...) get mails with external-body
parts, and most of them seem to be created by scripts or list servers
and not "normal" MUA's. Maybe our "RFC guru" can add more valuable
information about that? Brian?

* access type mail-server: I don't think it makes sense to add this to
Balsa. It is clearly an administrator's task to set up a mail server
which understands the commands sent back, and my feeling is that such
parts usually come from list servers. Not balsa's scope...

* access types ftp, tftp, and anon-ftp: This is (at least for the ftp
part) covered by adding an URL to the normal text body, which is
understood my most (?) mail clients (afaik pine doesn't). It might
make sense to support it, though. However, the user must have a deep
knowledge of the system setup. E.g., it is usually not possible to
simply select a file from the browser as the ftp daemon will have a
different root directory. Again, I think this is more a task for list
servers than for a MUA. Hmmm...

* access type local-file: this might actually make sense, e.g. if
someone wants to send a reference to a file in a corporate network
which is too big for an attachment (bandwidth, rejected by mta, ..). I
remember one user wanted the file: URL to be implemented to do exactly
this. However, it will of course work only if the recipient is either
on the same machine (server) or mounted the directory by e.g. NFS at
exactly the same position (and has proper permissions, of course).

Opinions?

Yeah, probably external body sending support would not make much
sense, although I remember somebody that wanted to support file: URLs
that - I think - could be replaced by external attachments.

Yep, large attachments distributed internally have caused us some pain
in the past; the file systems kept filling up due to large mail spool
files. We aren't that many users, but still, if 20 people get the same
attachment, it means 20 times the storge requirement of what's really
necessary. We have rather a lot of storage space, too, but the disks
are nearly full all the time (as someone said, disks are binary
devices ; they have tow states - "new" and "full") anyway, and a
couple of several-megabyte movie files written simultaneously to 20
mailboxes may be just the drop you need.

With Netscape, we told everyone to send "file://" links instead as a
simple way around these problems. We could probably have used the web
or FTP server instead, but that seemed like too much hassle. With
Balsa, this causes some annoyment as there is no direct way to open
the links.

Anyhow, *some* simple way of distributing "pointers" to shared data
would indeed be very welcome. Ideally, I would want to be able to drag
a file icon or an attachment from a different message to the
attachment pane of the one I'm composing, then tell the mailer somehow
that I'd prefer to pass a reference rather than the data itself, and
have the rest automatically taken care of.

This was added to cvs on 2001-09-25

Created attachment 5821 [details]
PATCH

Here is a patch against the cvs of Oct. 12, 2001 which enables sending
files as `message/external-body;access-type=local-file' attachments
according to RFC 2046.

Usage
=====

Attach a file as usual. Then right click on the icon and select the
popup menu item "attach as reference". A dialog pops up with a warning
message. If you select yes, the icon and label change to
"message/external-body". Right clicking again, you can revert this by
selecting the "attach as file" menu item. In this case, no
confirmation is necessary.

Remarks
=======

It is not possible to send a temporary item (e.g. a forwarded
message/rfc822) as reference, and there is no menu item "attach as
reference". These items live only temporarily and are removed
automatically, in most cases before the recipient has any chance to
read them. In this case, the file has to be saved first.

When postponing a message, the attachment is saved as file, not as
reference. The reason is in a way the same as above; the file might be
deleted or moved before the message is sent. To force sending as a
reference upon continue, save the attachment first to a "real" file
and attach it again.

It is only possible to use the access type local-file. The other
access types defined by RFC2046 (ftp, tftp, anon-ftp and mail-server)
usually require deeper insight into the configuration of the system
(e.g. ftp lives in its own "jail" in most cases). Adding all the
necessary dialogs etc. IMHO would blow the scope of balsa.

I have no idea which other MUA's support receiving and reading
external-body parts. Balsa, of course, does; pine and StarOffice
don't.

The message in the dialog may be really funny for a native speaker
because my english is really bad. Maybe somone can fix that... And
there is no proper icon for the message/external-body (and other
message/...) MIME type.

Code Details ============

libbalsa/body.h: 
* add a field to the LibBalsaMessageBody struct which indicates if
  a part shall be sent as external body

libbalsa/send.c: 
* add a static routine add_mutt_body_as_extbody() which write the
  necessary parameters and a "phantom body"
* when sending a message check if it shall be an external-body, and
  call this routine

src/balsa-message.c: 
* fix a small bug which lead to a crash when trying to read an
  external-body with access type local-file

src/sendmsg-window.c: 
* expand the attachment_t structure by a gboolean indicating if the
  attachment shall be sent as external body 
* add static callback functions extbody_dialog_delete(),
  no_change_to_extbody(), extbody_attachment()and
show_extbody_dialog()
  which are used to show the dialog described above and handle its
  button and destroy signals.  
* add static callback function file_attachment() to revert from the
  external body to "real" file 
* add the new item to the attachment popup menu

Patch commited. Thanks!

balsa-1.2.2 released, closing the report.

*** Bug 69110 has been marked as a duplicate of this bug. ***