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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers