Re: [Nmh-workers] forw

[Ken Hornstein]

>if it's a 100MByte attachment then i rather hate having to make a copy 
>in my local file system of each (or perhaps, all) attachments as i go 
>about destructively flattening things. far better to just include the 
>enclosing message as an rfc822 attachment and let the receiver see the 
>depth and avoid an extra copy in and an extra copy out of /var/tmp.

I know it bugs you, and I understand why.  But I doubt you'd notice, in
practice, on a modern system.  Also ... you have 100 MB attachments?
But anyway ...

>how hard would it be to just preserve the submessage structure and 
>attach it as an rfc822?

That's the thing that I don't think has been adequately captured ...
that's already been done!  That's what forw -mime does!  And maybe
I'm not understanding Norm, but I don't think he's really adequately
explained if or why that's not sufficient.

Well, specifically ... if you say "forw -mime 38 40", for example, you'll
get the following in the body of your draft:

#forw [forwarded message] +inbox 38 40

As long as you "mime" that message at the What Now? prompt, you'll get
exactly what you want; those two messages will be in the draft as two
message/rfc822 parts, complete MIME structure intact.

(Currently if we get a message/rfc822 part, we don't descend into that,
but you can mhstore that message into a new message and work on it.  That's
also something I want to fix).

Now, if you're asking why that isn't the default .... sigh.  By default,
unless you know to run "mime", that message won't do what you think.  This
is the disconnect between MIME and draft composition; we don't have a good
way to tell the draft "incorporate this content".  Although it occurs to
me instead of putting a mhbuild directive, we should create a new header
in the draft called "Forward" which contains the same information; this
would make more sense.

--Ken