Re: [Nmh-workers] masquerade settings & spost

[Ken Hornstein]

>On the other hand, I personally don't think any of this is important
>enough to spend a lot of cycles on, this isn't an area where nmh is
>really deficient.

Well, I respectfully don't agree.  You admit yourself that your
setup is unusual; you control all of the components (including DNS)
yourself.  I would daresay that is EXTREMELY unusual across email
users in this day and age; perhaps not MH/nmh users, but it's certainly
becoming rarer and rarer.  More specifically, the defaults don't work
for me, today.

>You can't do that and remain compliant to the RFCs, it was that that
>I was trying to point out in my first message (the one with the two
>addresses in the From: header, which has been legal internet e-mail
>since forever).
>[...]

Here's my basic answer to all of this.

As far as I can tell, it's nearly impossible for nmh to know what
the "correct" value of Sender: out of the box (Lyndon has spoken
to this more eloquently than I ever could).  So I would posit it's
your responsibility to know what the right value is.  It looks like
nmh will currently reject a draft with a Sender: field.  I could
be persuaded to remove that check and let you fill in the correct
value.  I could also be persuaded to require that if you have multiple
addresses in the From: header that you _have_ to have a Sender: address.

As for the envelope from ... well, no idea what the right answer is
there.  I think it has to take it from the draft (which could default
to the Sender: address).  I lack the energy for making a seperate knob
for it, so it's going to be one or the other.

>different to the one used by %(mymbox) as I actually prefer to keep
>Sender for many of my identities, even though that are "me" (stuff like
>postmaster, and hostmaster, and list-request).

%(mymbox) actually checks Alternate-Mailboxes, so you can't really use
it that way; that's why you need a new format function.

>On the other hand, when
>I send from my academic address (the @coe.psu.ac.th) I used in the
>example with two addresses, I don't need a Sender added (and obviously
>not for my long term "normal" address as used in this message.)  That is
>"don't need" as opposed to "don't want", if one is generated, then so
>be it, it s harmless.  Similarly, for my other identities, for which I
>would prefer to make sure a Sender header is present, if it isn't, then
>that would not be a disaster.  But when I send mail for my wife, and use
>use her e-mail address in the From: header, which I do occasionally,
>then I certainly do want/require a Sender header.  And so does rfc5322:

Yeah, the problem here is I can't really think of a way for nmh to know
that your "mailbox" is different than the From: header you're using, at
least not in any way that would work sanely for everyone, or even a
reasonable proportion of people (for example, it would never work for
me based on the way I use nmh).

>  | 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.
>
>Initially, most probably not.  I guess I'm a little afraid that it
>is likely to become the most common use mode, leading to both people
>failing to appreciate the advantages of being able to use all the unix
>tools, on all e-mail, all the time (even when not connected to the
>network, like in a plane - though that restriction seems to gradually
>being lifted, at a cost...) and to eventually, the worth of features
>being judged by whether or not they work wit e-mail on an imap server
>instead of locally (we've already seen some of that with annotate).

Can't really help you there; it's clear that IMAP is the way the world
is going in terms of email.  That ship has sailed, found a new country,
and has declared their independence.

Let me put it another way: you want better MIME support.  You have a
lack of time/energy/desire to do it yourself.  So you want someone else
to do it.  But ... those other people (like me) have other priorities.
If you want better MIME support, this is what you're going to have to
put up with.  It's either that or nmh doesn't change at all.

--Ken