Wow, I take a day off to get some Christmas stuff done, and this discussion
explodes. To summarize a bunch of emails ...
Paul Fox wrote:
if "mhbuild -auto -nodirectives" can still process Nmh-Attachment
directives at this point, then why can't "attach" after a "mime" still
work? couldn't running "attach" after a "mime" simply do
the same thing that makes the "send" case work?
I think this was explained correctly; you can only run mhbuild once (it
turns a "mhbuild draft" into a MIME message), and basically everyone
explained that even in "auto" mode Nmh-Attachment headers would still
be processed (I'm fine with -auto; I didn't care for Ralph's -skipmime
suggestion, but I'd be open to others). And Paul, your rephrased
description is correct.
Ralph writes:
if the mhbuild-directives need
improving and "mime" run again, one must undo the "mime" manually by
looking for the backup file in the drafts folder as there's no
"undomime" command.
Should we create a "unmime" command? You would think it wouldn't be
hard, actually.
Jon writes:
Oh! Just looked at the file man page, and someone has added a --mime
option that does the right thing and recognizes messages in ascii text.
That's not part of POSIX, actually, so we can't rely on it. It seems
most people use file suffixes. Also ... if you really want to forward
a message as message/rfc822, we HAVE forw -mime already.
Jon writes:
David Levine writes:
The movtivation behind all this is to always produce MIME
messages. An easy (well, not quite) way would be for post(8) to
run mhbuild on every message.
Ah. I guess that I just don't get the need/motivation for taht.
Sigh. I kinda thought this was obvious, but to restate it ...
Right now a user can sit down, compose a message that happens to contain
8-bit characters, and send it out ... and nmh will happily blast it out,
with no MIME headers at all. This is super-wrong. And it's not a
theoretical problem either:
http://lists.nongnu.org/archive/html/nmh-workers/2012-05/msg00141.html
Also, we want nmh to be a MIME-conformant MUA, right? Well, take a look
at RFC 2049, Section 2, to see what that entails. The short answer is that
in this day and age, you're supposed to be sending all email with the
basic MIME headers. mhbuild is the tool we have that does that.
Now, you're objecting to the work; sure, you admit that you don't have to
do it, so it's not a huge objection. The problem is ... I think you would
admit that your implementation has a number of warts, and one obvious one
is it has a lot of MIME knowledge in "send" which feels wrong to me.
Moving this to mhbuild makes more sense from a long-term architectural
standpoint.
This isn't really about making mhbuild directives and Nmh-Attachment
headers work together in the same message ... Ralph had the correct
point that really, attach and mhbuild directives are two different ways
of doing the same thing, so why aren't they converging more? That logic
is unassialable. Being able to support both in the same file is, to me,
just a side benefit. If it's trivial (and it looks like it is), why not
make it work?
Just doing nothing is, unfortunately, not an option, not in this day
and age. This is all about making nmh a real MIME-compliant MUA, which
I hope is something we all want.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers