Date: Fri, 11 Jun 2021 14:04:36 -0400
From: Ken Hornstein <kenh(_at_)pobox(_dot_)com>
Message-ID:
<20210611180437(_dot_)3B854C2698(_at_)pb-smtp1(_dot_)pobox(_dot_)com>
| As I understand your question ... no, that is not true (with a few caveats).
I believe you understood the question correctly! Thanks.
| We finally decided, I think around nmh 1.5 (or 1.6),
It could easily be that far back, or further, that, for reasons I no
longer recall, I used to frequently end up attempting to send messages
with MIME fields in the header (MIME-version in particular, though I
know of no good reason for anyone to ever want to manually insert that
field ... but usually at least one more) and message sending would fail
(so I'd have to delete the things).
Somwehere along the way I have simply stopped getting myself into the
situation where that occurred (whatever I was doing, wherever that draft
was coming from, clearly wasn't working well, so I changed the way I work).
| to automatically run "mhbuild" on all drafts because nmh users had
I recall that happening I think - I suspect it never was an issue for me,
as I have (still have, and have had for a LONG time) the -mime switch for
send (and push) in mh profile.
| Now PRIOR to that, if you had the AUTOMHNPROC environment variable set
That I don't recall ever having, in fact, I don't recall ever knowing it
even existed.
| (I think), send would also run mhbuild (back then, mhn). _If_ you did
| that AND your draft contained a MIME header like Content-Type, you'd get
| an error.
The -mime switch would do the same? In any case, I saw plenty of the
error (for a while).
| AND if mhbuild sees a MIME header, it silently exits without error.
| The assumption there is if the outgoing draft already
| has MIME headers then either the user knew what he/she was doing
I need to ponder all this more (05:xx in the morning isn't the best time
for clear thinking - and I am *not* an early riser!) but I think this
might be exactly what I don't want. I don't want to manually (or
via calling mhbuild manually, via one path or another) have a fully
constructed MIME message in the draft (or not usually), what I want
is to be able to provide explicit info about things I know to be true
about the draft, and have nmh (mhbuild or whatever) use that info rather
than guessing, which most probably just means the content-type field.
That is, should I for some bizarre reason have a need to send an HTML
format message, I could use an HTML editor to compose the body, in some
appropriate character set, and save that in a file. The I do "comp"
and add, or change the Content-Type field to text/html; charset=whatever
whatever isn't necessarily anything related to my locale settings, if I
had any) and read the file after the ---- line in the draft, to provide
the body of the message. Then if I need it I can go add some Attach
(pseudo-)fields in the header to add some photos, PDF files, or whatever
I need to also include. Then nmh takes the draft, knows what form it
is from the Content-type field (no guessing it is HTML based upon <p>
type constructs in the body, etc) and what charset that body was encoded
using (again no guessing) and builds a multipart-mixed with that initial
text/html plus the image/jpeg (or whatever) that is to be attached.
| and then your favorite editor will understand the characters in the
| reply message.
I suppose it might...
| This obviously works best if your local character set is UTF-8.
Yes.
| I am aware that some people, for reasons I cannot comprehend,
| want to run in the "C" locale
I do that, not so much because I want to, but because that's what happens
when no LC_* env variables (nor LANG) exist at all. That's me. I believe
you understand that locales aren't exactly first class objects in NetBSD...
(Or not yet anyway).
The usual problem I encounter is people who insist on using "fancy" quote
characters, rather than the ascii ones, in an otherwise ascii message. When
I include that as a quote in my reply, the UTF-8 encodings of those things
appear in the draft - with my C locale. That's how I suspect the appearance
of "pretending to be UTF8 with a C locale" comes about. But it isn't
something I want to happen - it is all just imposed upon me (if the
draft contained '?' instead of the quote, it would be easier to fix, one
simple global substitute (and then put back any real question marks, but
usually there are none). I however don't have an input method to type
the UTF8 chars, so I can't do a substitute command for them, and instead
have to move to each one and replace it. Tedious. But if I don't I end
up sending a message containing UTF8 without a content-type field that
indicates that.
All something of a mess (but if "repl" noticed it was including the body
of the message in the reply - and clearly it does - and could then look at
the Content-type of that message (or what that was converted into) and
add that to the draft (to be used as above) I suspect there would be far
less problems.
kre