Re: postpone -> attachments lost

[Brian Stafford <brian stafford uklinux net>]

On Tue, 28 August 21:51 M . Thielker wrote:
> Hi,
> 
> On 2001.08.29 00:21 Albrecht Dreß wrote:
> > IMHO there are tiny but important differences between "real" forward and
> > continue. When forwarding a message, all parts of the original message
> > should
> > be attachments to the new one. There is no reason that the user changes
> > any
> > part of the original, including text bodies.
> 
> It's completely unusual to have the text of a forwarded email be an
> attachment.

There are three ways to forward a mail:

1) Send the message verbatim, except for the addition of Resent-*: headers
   as described in RFC 822/RFC 2822.  As far as the new recipients are
concerned,
   they have received the original message with the original headers (esp.
   Message-ID:) but with extra trace information.

2) Quote it with > (or whatever) as is common. (ad-hoc, not in any standard.)
   Recipient gets a new message.

3) Send it as part of a MIME document with type "message/rfc822". (RFC 2045-9)
   The message should not be any other MIME type in this case.
   Recipient gets a new message.

Personally I consider 1 and 3 to be the superior way of forwarding a message
since neither interfere with the message structure, its character sets, etc.
Netscape allows the selection of 2 or 3 as the forwarding mechanism.

Strictly its wrong to talk about mail with attachments when referring to
a structured MIME document (unless you really were talking about an attachment
;), I can't tell from the context).  Its only an attachment if the
Content-Disposition: says so.  I'm fairly sure NS/Moz show message/rfc822 parts
inline.  Not certain about Outlook/OE though.

> With many mail readers, having text as an attachment means
> having to use an external viewer or editor, becaise most clients I'm aware
> of don't have the (IMHO neat) way Balsa offers to deal with attachments.

Its neat, mind you it could stand some improvement, like dealing properly
with multipart/related and multipart/alternative. (And of course,
multipart/signed and multipart/encrypted if anyone's listening.)

> Rather, they're displayed as either inlined images (bad) or little icons
> (worse).

Actually I like the inlined images, saves messing about to see them.  OTOH,
they can be irritating (revolting) in spam.  Hmmmm....user preference?
But never as icons - aargh!

> Double-click one and it will be saved to disk as a temp file and
> opened using the default editor. That's a nuisance for almost every user not
> using Balsa. So, the text of forwarded messages should really be the message
> body, _not_ an attachment.

Sounds like the RFC 2822 Resent-*: stuff should be implemented then ;)
Actually I've never had that problem with message/rfc822 in NS.  I just see
them in the UA.

Presuming that you really mean MIME when you say "attachment", it seems a
shame to undermine the work of the IETF's MIME working group by ruling out
the use of MIME for forwarded message within precisely the structure that
allows it to be handled elegantly.  After all, MIME is designed expressly for
use within a MUA.  NS/M$ and many others do a perfectly good job of handling
MIME, so use it.

I've participated in an IETF WG in the past, so it annoys when someone says
"we can't do this because nobody else does".  That just prevents progress.  If
its in a standard it gets adopted eventually.  A lot of hard work goes into
the production of a standards track RFC.  If the standard is not clear,
then more work needs to be done; an implementors guide might be needed.
MUA authors are particularly influential voices wrt MIME and its use.

> Common practice prepends some of the original message's headers to that
> body's text to show the origin of the message.

That is a ghastly practice.  Use message/rfc822, not an ad-hoc mechanism.
message/rfc822 is there for good reason.

> Quite often I receive messages that only need to be forwarded in part. There
> may be internal corporate information, followed by information meant to be
> read by subcontractors. There _must_ be a way to remove the confidential
> internal information before forwarding the remainder of the message, so
> there's your case for editing a message when forwarding:

Surely this is just a standard cut and paste thing into a new message?
No rules or special support needed.  Just as long as the message can be
loaded into an editor.

Brian