nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] masquerade settings & spost


From: Ken Hornstein
Subject: Re: [Nmh-workers] masquerade settings & spost
Date: Tue, 07 Feb 2012 09:36:10 -0500

>I don't understand that, I've used multiple identities, without any
>particular difficulties, for a long time now (> 20 years), and MH (and
>later nmh) just works as it is.  That is, to say, in this area I see
>no need for any changes, and consequently no need for any code to be
>developed.

Well, there are really two different things here that are sort of conflated.
Let me seperate them out:

- Code simplification.  That's what removing support for turning off
  draft_from is about (I have to touch that code anyway, and making
  it simpler would help me out).  The options for controlling draft_from
  just make the code hairier, and I'm not even sure it makes any sense
  given the changes coming.  So far no one has made any reasonable argument
  why this code should stay; I'm open to hearing some reasons, so if you
  want to keep this selectable it's time to speak up.

- Reasonable defaults.  The discussion that has been hashed out over the
  last month on this has resulted in the following consensus view:

  - All drafts have to have a From: line in them; if they don't, post will
    reject them.
  - The default components files will have From: lines in them.
  - There will be a configurable hierarchy as to where the default From:
    information will come from (see the mailing list archives).  This here
    is the part that is requiring the majority of new code.

  In my view, this part has been settled; if people had objections to this,
  they should have made them back when this was under discussion.

As you point out, nmh has let you use multiple identities for a long time
now.  This isn't so much about that part (although, see below), but more
about being able to do it in a more logical way.  But ... based on
what you're saying, nothing I'm proposing is going to change how you
use nmh.  Well, except that post probably isn't going to generate a
Sender: header anymore (not sure about this part ... I was going to
wait until I get in there to figure that out).  But assuming you have
draft_from turned on, you probably haven't been generating a Sender
header anyway.

>From what I can figure out, the thing people most want to add is some
>magic to have nmh choose which identity it should use, rather than needing to
>be told.  Personally, that is exactly what I don't want - automation
>like this gets addictive, and we start to assume it always works
>correctly, and so don't bother to verify it every time - but in this
>area, it is almost impossible to be perfect, that way can lead to
>embarrassing mistakes.

I respect your opinion, but as someone who's replcomps now selects
the "right" email address to use in From: headers ... man, I can't
go back now (I'm lucky in that the heuristic I use is relatively
simple).  And I'm not the only one who would make use of this
feature.  But of course you are still free to use nmh in the way
you use it now.

>And I absolutely understand that, and for whatever my opinion as to how
>you should allocate that limited time is worth, and I understand that is
>not much, I'd prefer you use it in the areas where it is clear that MH
>does need work, of which the most obvious is MIME handling (particularly
>for replies, the rest of it might be clunky, but kind of works).

As we've discussed ... fixing THAT problem is not easy.  It's being
worked on (slowly), but it's going to be tough.

>useless to me, and should be just as useless to any true MH user. (nb:
>this is not to denigrate IMAP.  For people whose needs it serves, it is
>just fine, it is just that those needs, and MH's requirements, aren't
>compatible.)

Well, people have made what I consider reasonable arguments in terms of
use cases for IMAP support in nmh.  Of course when nmh has IMAP support
(I'm an optimist!) it shouldn't affect you in any way.

--Ken



reply via email to

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