[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] forw

From: Paul Vixie
Subject: Re: [Nmh-workers] forw
Date: Sun, 09 Oct 2016 21:14:16 -0700
User-agent: Postbox 5.0.3 (Windows/20160930)

Ken Hornstein wrote:
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 ...

as i've explained to the KDE "KMail" team, assume 100 MByte attachments. don't keep them in memory, and don't make copies unless you have to. MH is generally smarter. for example, deleted files are just rename()'d. on KMail, it's copied, in its entirety, to Trash, which means if you're on low-BW WiFi, you spend 200MByte of WiFi dragging the message to your laptop and then pushing it back to a different folder.

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.

what those of us who loved and used burst(1) in the RFC 934 era, and i may be speaking for Norm here but i don't know, is that "f" "o" "r" "w" "\n" at the shell prompt just does the right thing. telling me that i have to pay attention to how the message i received was encoded toward me so that i can use the appropriate command line option to ensure that it is forwarded in its entirety as it would have been in the RFC 934 era sounds like crazy talk.

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.

here's what i think you're forgetting. MH's user base is aging. we are not attracting new 20-somethings. i am 53 now. old enough to learn new tricks? maybe. i'm learning GoLang, for example. but am i going to remember that "forw" works for RFC 934 format but that i have to invoke it differently and also answer whatnow(1) differently if MIME is involved? no. sorry, but no. brain cells die every day, and i have to conserve the ones i have left for things which matter more to me than this.

i think what i'm suggesting is that forw needs a -auto option, which ought to be made the default, which will detect that MIME was used instead of RFC 934 on the message i'm forwarding, and DTRT ("do the right thing") or perhaps even DWIM ("do what i mean").

(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).

as long as forw(1) picks up the message hierarchy in the forwarded message, regardless of whether it's in RFC 934 or MIME format, then i really don't mind if forw(1) lacks the ability to select specific attachments and that i have to use mhstore(1) instead.

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.

yes indeed.

P Vixie

reply via email to

[Prev in Thread] Current Thread [Next in Thread]