Re: Why does mh-edit-again delete "From: "?

[Bill W. <wo...@ne...>]

[If you read nothing else, read the last paragraph ;-).]

Douglas Alan <dou...@ha...> wrote:

> On the other hand, "E" works even less well when the bounced messages
> are MIME-encapsulated, and this seems to be the case most of the time
> these days, so perhaps the original complaint is more or less moot.

Hmmm, that should be working more or less. I made a quick fix a long
time ago (2001-11-28 for version 5.0.91) so that the encapsulated NDNs
were handled although the last MIME marker is still orphaned. Is anyone
else experiencing the same issues as Doug?

> The computer I send mail from is usually not at all the computer I want
> to receive mail at, and when my carefully selected "From:" address ends
> up getting deleted, and I don't notice, then replies end up going to the
> wrong place, etc.

OK.

> I've never used MH-E identities and I don't know what they are typically
> used for, but it sounds to me that I'd then have to configure this in
> two places: both in my MH config and my MH-E config, and I try to avoid
> doing such multiple configurations whenever possible.

That occurred to me after I sent my message. It is one of our goals to
avoid doing things in MH-E that can be done in MH. So I'm definitely
starting to see this as a problem.

> Bill Wohler <wo...@ne...> wrote:
> >
> > But I just had a great idea! If the message to be edited again is your
> > draft or is in your draft folder, the header does not get cleaned. If
> > the draft was copied from another folder, then the header gets
> > cleaned.  That way, we preserve the semantics of `comp -use' and we
> > avoid the incorrect inclusion of someone else's From header
> > field. Thoughts?
> 
> I'm confused about this inclusion of someone else's "From:" header
> issue.  I don't know what "e" is supposed to do, but why would I ever
> want to use a mechanism like this to resend someone else's email?
> That's what "f" and Meta-D are for, right?  If I put my own "From:"
> header on someone else's email, that would be plagiarism, which is not
> what I would want either.

I thought I had a use case for this, but I'm not remembering it now.
Like Jacob, I use `e' a lot for repurposing messages in my outbox.

> "E" (mh-extract-rejected-mail) used to "just work" for many years, and
> then one day it stopped.

If you're referring to the absence of the From header field, it's been
in mh-new-draft-cleaned-headers from the beginning of time, so something
else must be going on:

  http://mh-e.cvs.sourceforge.net/mh-e/src/mh-comp.el?hideattic=0&revision=1.1&view=markup

Jacob Morzinski <morzinski@MIT.EDU> wrote:

> Bill Wohler <wo...@ne...> wrote:
> >
> > As far as I can see, there is only a problem if you define a From in
> > your components or replcomps file, right? But how many people do this?
>
> I also define a "From" in my various components files.

Eric Jensen <je...@hv...> wrote:

> This is what I do (and thus the reason I had the problem).  At the time,
> I wasn't aware of identities, and this was the easiest way I could
> figure out to get the behavior I wanted.  Looks like it's time for more
> learning.  Bill, maybe you could point us to the right part of the
> manual for learning how to use identities?

You can read about identities in http://mh-e.sourceforge.net/manual/,
but you might not have to ;-).

Let's take a closer look at mh-new-draft-cleaned-headers:

   "^Date:\\|^Received:\\|^Message-Id:\\|^From:\\|^Sender:\\|^Errors-To:\\|^Delivery-Date:\\|^Return-Path:"

All of those are automatically inserted by MH programs and most of them
will cause post to puke if they are already present in the draft. I
think it might be that this variable should probably not contain items
that people can put in their components files. Like From.

I therefore think I'm coming around to thinking that we should remove
>From from this variable. I know I have at least three votes for; do we
have any votes against? Maybe someone can think of the use cases I'm
forgetting at the moment, or why From was in this variable in the first
place.


-- 
Bill Wohler <wo...@ne...>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD