Re: Failing to extract text/html part of message with show

[Laura Creighton]

What does mhstore get you?  (If you are lucky, a part that has exactly what you 
want).

Laura

Re: automatic decode mime in repl

[Laura Creighton]

In a message of Fri, 11 Feb 2022 18:37:28 +, David Levine writes:
>Laura wrote:
>
>> I would really like to have this.  The workaround I have made is really > 
>> ugly, and doesn't always work.
>
>Does this produce a result that seems at least as good?
>
>  \repl -filter mhl.replywithoutbody -convertargs text/html ''
>-convertargs text/plain '' -editor mhbuild [msg]
>
>Where [msg] is the usual optional message argument to repl.
>
>David

I will have to find a suitable piece of mail to check it on, but
I already have a working solution for replying to html mail.  It's
the people who send me mail as pdf and mail as encoded base64 that
are hard to reply to.  But it's not a common occurrance these days,
which is why I don't have something handy.  Will look tomorrow after
I have had some sleep.

Laura

Re: automatic decode mime in repl

[Laura Creighton]

In a message of Fri, 11 Feb 2022 16:52:34 +0100, Philipp Takacs writes:
>[2022-02-11 02:55] David Levine 

>But to decode mime messages there is a feature in nmh which was there
>before convertargs: mhshow. All my patch does is call mhshow and pipe
>the mail through it. Nothing more and nothing less. By this way you
>get mhshow to decode mime and all of it's features.

I would really like to have this.  The workaround I have made is really ugly, 
and
doesn't always work.

>This patch doesn't handle URLs at all. mhshow will print them as is to
>stdout. After that mhl will add the '> ' and linebreaks. As said in the
>other mail, this is the default behavior of repl. This has nothing to do
>with my patch. There where already two ways mentioned in this thread how
>this could be fixed.

and I don't care about urls.

>Philipp

Laura Creighton

Re: How to give Thomas Dupond the date in his replies.

[Laura Creighton]

Try replacing your mhl.reply with:

date:nocomponent,nonewline,\
formatfield="In a message of %(pretty {text}), "
from:nocomponent,formatfield="%(decode (friendly{text})) writes:"
body:nocomponent,format,nowrap,formatarg="%(trim{content-type})%(putstr)",formatarg="%(trim{content-
transfer-encoding})%(putstr)",formatarg=">"

Alternatively, I got my Comments: line above to do what you want in replcomps.
The last lines of my replcomps are:

Comments: In-reply-to \
%<{from}%(void{from})%?(void{apparently-from})%|%(void{sender})%>\
%(trim)%(putstr)\n\
   message dated "%<(nodate{date})%{date}%|%(tws{date})%>."

Laura Creighton

Re: mhbuild: extraneous information in message

[Laura Creighton]

In a message of Wed, 12 May 2021 16:29:37 -0400, Ken Hornstein writes:
>>> There's no HARM in you putting entries there.  But nmh doesn't read that
>>> file either.
>>
>>Which raises the question - what is getting into the path so when Laura
>>adds entries to /etc/mailcap, things start working for her?
>
>That's ... a good question.
>
>First, it's not that I don't believe Laura.  But ... I have some questions
>about this.  Like, exactly WHAT MIME types could you not view until you
>added them?  Were they text types?  I ask because there are simply NOT
>that many text types.  There actually aren't that many MIME types in
>general, and I'm wondering what ones you couldn't view and how long ago
>you had to add them.
>
>Secondly ... I knew this had come up before.  Here's the earlier
>message where this came up:
>
>   https://lists.nongnu.org/archive/html/nmh-workers/2015-03/msg9.html
>
>The short answer is FOR DEBIAN ONLY, the distribution of nmh was at the
>time configured in mhn.defaults to use a program called "run-mailcap",
>and I guess that uses the mailcap file.  This had a poor interaction
>with some types and nmh 1.6, but Alexander Zangerl (who is the Debian
>nmh maintainer) said he was going to improve that, so I don't know what
>the situation is under 1.7.  Ralph suggested that there weren't any
>Debian-specific changes in that regard, but you'd need to look at the
>mhn.defaults file on your system to see the details.
>
>--Ken

It's very likely that when I was doing this it was nmh 1.6 that was
running here.  And the things I remember needing to add was a
different mimetype for pgp signatures and a whole host of mimetypes
for things that that supposedly generated 'internet business cards,
and calendaring information', a bad idea whose time I think has come
and gone.  But for a while everybody seemed to be sending me one,
and everybody had their own idea as to what the name of the mimetype
was.

Laura

Re: mhbuild: extraneous information in message

[Laura Creighton]

In a message of Wed, 12 May 2021 12:25:30 -0400, "Valdis Klētnieks" writes:
>On Wed, 12 May 2021 18:16:28 +0200, Laura Creighton said:
>
>> Oh goodness.  I had no idea.  And here I have been happily editing 
>> /etc/mailcap
>> every time somebody sends me something I cannot read, adding a rule about 
>> how to
>> read it, and smiling contentedly when nmh starts being able to read it 
>> properly.
>>
>> Where should I have been adding such rules, if not there, then?
>
>$HOME/.mailcap
>
>Among other things, that way your personal entries are safe from operating 
>system
>upgrades.

Thank you.

Laura

Re: mhbuild: extraneous information in message

[Laura Creighton]

In a message of Wed, 12 May 2021 07:55:56 -0400, Ken Hornstein writes:
>>Manjaro is based on Arch linux, and Arch linux is based on debian.
>>My debian distro looks for such things in /etc/mailcap.  I'd look there first.
>
>Just for the record  nmh (and MH before it) has never directly used
>the mailcap file.  Arguably, it SHOULD, but it does not (I am aware
>there are some distribution bundles of nmh which are configured to call
>programs which use the mailcap file to try to figure out which helper
>program to use, but in my experience none of those work very well).
>
>--Ken

Oh goodness.  I had no idea.  And here I have been happily editing /etc/mailcap
every time somebody sends me something I cannot read, adding a rule about how to
read it, and smiling contentedly when nmh starts being able to read it properly.

Where should I have been adding such rules, if not there, then?

Laura

Re: mhbuild: extraneous information in message

[Laura Creighton]

In a message of Wed, 12 May 2021 10:12:06 +0100, Ralph Corderoy writes:
>Hi Laura,
>
>> Manjaro is based on Arch linux,
>
>Yep.
>
>> and Arch linux is based on debian.
>
>No, I don't think so.  I run Arch Linux here and one key reason is it
>packages upstream releases directly without much tinkering or delay by
>doing a ‘rolling’ release, unlike Debian which has a comprehensive set
>of patches and a periodic release schedule.
>
>> My debian distro looks for such things in /etc/mailcap.  I'd look
>> there first.
>
>However, I have one of those, owned by the mailcap package.  :-)

I think I could have phrased that better.  What I meant by 'based on
debian' was historically, and to do with filesystem layouts and the
like -- as opposed to 'based on SuSe or based on RedHat', not
dependent on the technical and political machinations of the debian
community.  Also .deb files just install on Arch, no? (been a long
time since I had one.)

At any rate whenever I have the sort of problem that Steven mentioned, I just
add a line to /etc/mailcap telling it how I want to process the new thing I
am being sent.  But other distros keep this stuff other places.

Laura

Re: mhbuild: extraneous information in message

[Laura Creighton]

In a message of Wed, 12 May 2021 04:20:24 -0400, Steven Winikoff writes:
>I'm quite sure this isn't nmh's fault, but rather an error in the MIME
>configuration on my Manjaro Linux machine.  I'm hoping for a hint about
>where to look for the config file responsible for "audio/mpegapplication;".
>
>   Thanks,
>
> - Steven

Manjaro is based on Arch linux, and Arch linux is based on debian.
My debian distro looks for such things in /etc/mailcap.  I'd look there first.

Laura Creighton

Re: check if message is in a particular sequence?

[Laura Creighton]

In a message of Sun, 02 May 2021 14:11:44 -0400, Ken Hornstein writes:
>> > I confess I don't LOVE -terse/-noterse, but I cannot think of anything
>> > better right now; I say go for it.
>>
>>I thought of using "curt", and "nocurt", but that didn't seem right
>>either.  ;-)
>>
>>But maybe you're not fond of the concept, rather than just the name?
>
>Oh, no, the CONCEPT is fine, I just didn't love the name.  I like
>-range/-norange slightly better, but I still don't find it great.
>Something like -compress/-nocompress MIGHT be better, but again, I'm
>not loving it.

-noexpand/-expand ??

Laura

Re: [nmh-workers] mhshow: invalid BASE64 encoding in --

[Laura Creighton]

I didn't know about the built-in iconv.  But this behaviour seems a
lot better than 'just drop the problems on the floor silently'.  The
reason I was interested in a louder error reporting was that, for a
certain chunk of time if there was an encoding error, then chances
were that the person who had broken things was me ...

Laura


-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] mhshow: invalid BASE64 encoding in --

[Laura Creighton]

With  irony, in a discussion about how to handle bad encodings in mail, I
found that I could not read this message by Valdis Klētnieks
https://lists.nongnu.org/archive/html/nmh-workers/2019-03/msg00023.html

Something bad seems to have happened to his encoding of a '§'.

Now, my .mh_profile says (all one line, but I made it more readable).

mhshow-show-text: iconv -f "$(charset=$(echo %a | 
sed -n -r 's/.*charset="?([-a-zA-Z0-9_]*).*/\1/p');
if [ x$charset = xunicode-1-1-utf-7 ]; then echo utf-7;
else echo ${charset:-iso-8859-1}; fi)" | less

(I used to get lots of utf-7 mail.  Haven't seen any for man years now.)

and iconv is very picky.  It says, quite correctly, 
iconv: illegal input sequence at position 507 and then stops.

So my experience is seeing:
>Date:Sun, 17 Mar 2019 18:12:49 -0400
>To:  Ken Hornstein 
>cc:  nmh-workers@nongnu.org
>From:"Valdis Klētnieks" 
>Subject: Re: [nmh-workers] mhshow: invalid BASE64 encoding in --
>
>
>iconv: illegal input sequence at position 507On Sun, 17 Mar 2019 17:29:16 
>-0400, Ken Hornstein said:
>
>> >My reading of RFC2045 says a conforming base64 decoder is allowed to toss 
>> >out
>> >the blanks and the '!' char and decode the rest.
>> >
>> >   Any characters outside of the base64 alphabet are to be ignored in
>> >   base64-encoded data.
>> >
>> >Yeah.  That's pretty definitive. :)
>>
>> Oh, hm, you know you learn something new every day, and this is my new
>> thing for today.  As much as I've read RFC 2045 over the years, I missed
>> this!  (This is in -- 
>nmh-workers
>https://lists.nongnu.org/mailman/listinfo/nmh-workers

I can see how this might be behaviour you might want, but mostly I don't.


You can give iconv the -c flag "Silently discard characters that cannot be
converted instead  of terminating when
encountering such characters."

But since it is silent, there is no way for me to know that it encountered a
problem.  

But the behaviour I want is one that iconv doesn't give you.
Scream informatively about the problem and then continue on as if it 
never happened.  I want the message that I get without the -c flag and then
the -c behaviour.

When my mail blows up, I just pop into .mh_profile, add the -c flag, and then
find out what it was that Valdis wanted to tell us.  Then I take it out again
so I can be informed when iconv next runs into problems.

I just thought that while we were discussing what we should do, I would
mention this because it is the middle ground that I want most of the time.

Laura

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Microsoft hockeyapp doesn't care about 2045 RFC (6.4)

[Laura Creighton]

In a message of Tue, 17 Oct 2017 09:44:36 +0100, Ralph Corderoy writes:
>Hi Ken,
>
>I wish you were a betting man.  ;-)
>
>> Ken wrote:
>> > and that's the answer I usually get (if I get an answer at all).
>...
>> Speaking of which, I've emailed Corey.
>
>And Laura and I heard back from Thomas Dohmke, HockeyApp's co-founder,
>today saying a fix had been deployed.  He's also keen to find out where
>Laura hit a wall so he can get a route created through Microsoft's
>defences to the HockeyApp team in future.
>
>-- 
>Cheers, Ralph.
>https://plus.google.com/+RalphCorderoy

My mail went through  Cory, whose name has no 'e' and I am in the hospital so
it will be some time before I can find out exactly what happened.  Cory will
know better, but he is on the last stae of making a KS promised release which
already has had a 3 month delay --- and I am not pulling my weight, at all
due to being ill.

But thank you very much Ralph.

wonderful.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Microsoft hockeyapp doesn't care about 2045 RFC (6.4)

[Laura Creighton]

In a message of Sat, 14 Oct 2017 19:40:40 -0400, Ken Hornstein writes:
>>Also, while the department of Zoology and the dept of Medicine may
>>indeed have well figured out that it would be a good idea to share
>>software, they in no way informed me, or
>>Marcus-whose-last-name-I-forget (Wall? Wald?), the two of us being the
>>ones that wrote the software in the first place.  I do not think that
>>any 'set this up' was ever done, aside from handing over a copy of the
>>software.  Which was really general purpose AD and DA conversion
>>routines in the first place  unlikely to get you in trouble
>
>I know this was over 30 (!) years ago, but there is one thing about this
>story I have a question about.  We've got the brain wave sensors on the
>monkey caps, which are connected to A->D converters and then piggybacked
>onto the VAX disk drive.  The part I am missing is ... why would WRITING
>to the disk drive cause voltage to be output to those devices, thus zapping
>the monkeys?  That's the part I never really understood.
>
>--Ken

I didn't do that part, but there really were experiments where you would
embed the sensor in an experiemental subject and then apply voltage as part
of an attempt to map what parts of the brain were actually good for, and
what is an epileptic seizure, back in the days when this was much less
well understood.  So somebody out there really might have had the idea that
the capability would be a good thing to have.  But the only software I had
that was doing anything like that was being used by people studying
the behaviour of certain pests that bothered the tobacco crops.  Worms.  I
cannot remember exactly why the researchers wanted to give elecrtical shocks
to the worms, but it was probably part of figuring out how certain
pesticides worked, and thus whether they were likely to pose a risk to
other life.

You couldn't get in trouble with the ethics committee for mistreating
worms, even if you killed lots of them via electical shocks, especially
since the whole point of the research was to figure out better ways to
kill the things.

However, there was a huge complicated procedure for dealing with any
sort of vertebrate, and it got more restrictive for mammals and even
more for primates.  So what happened shouldn't have been possible.  At
the time I thought that what must have happened was that the people
doing the research got somebody to cobble something together, based on
stuff we had written, who didn't quite understand what he or she was
doing well enough to realise that this was possible.  This should have
been caught in the review, but looks like that was also done by
somebody who wasn't clued in.

Nobody ever asked Marcus or I  to come over, explain what we had written,
how it worked, and more importantly what parts still didn't work properly.
I suspect that the fact that both of us were under 18 at the time we wrote
the stuff may have influenced that decision.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Microsoft hockeyapp doesn't care about 2045 RFC (6.4)

[Laura Creighton]

In a message of Sat, 14 Oct 2017 15:34:22 -0400, Ken Hornstein writes:
>>I've been in discussion about this with Microsoft, and their position
>>boils down to 'don't give a damn, get a new mailer that is more permissive'.
>
>If it makes you feel any better, I share your pain, and that's the
>answer I usually get (if I get an answer at all).  You will find a gamut
>of opinions on this subject in the nmh community; personally I think we
>should let this one pass because so many people get this wrong, but not
>everyone agrees.
>
>David has already pointed you to his excellent mhfixmsg program which
>solves this for you.  But ... if you want to run this to ground, there
>might be another avenue.  In my experience very few programs actually
>generate the MIME output themselves, they call another library to do it
>for them.  Maybe you could figure THAT out and file a bug with the library
>authors; the authors of libraries tend to care more about standards and
>in my experience are less asshole-ish than application authors.  We
>actually did that for one library and they were kind enough to fix it
>(I admit, I was surprised as well):
>
>  https://lists.nongnu.org/archive/html/nmh-workers/2014-04/msg00242.html

>And, SINCE I have you, I've been meaning to ask you for a while ... is
>this you?
>
>   http://edp.org/monkey.htm

Yes, that is me.  I actually think that Medicine had an 11/something-or-other
dual space machine that was running Berkeley 2.98 bsd, not an 11/780 vax, but
otherwise, seems correct enough to me.

Note that the brains have no nerve cells, so the pain the zoo rats underwent
that had the department shut down was not because there were sensors in
their brains, but more that to measure them they were bolted to trays so that
their heads did not move.  And other more grisley things.

Also, while the department of Zoology and the dept of Medicine may
indeed have well figured out that it would be a good idea to share
software, they in no way informed me, or
Marcus-whose-last-name-I-forget (Wall? Wald?), the two of us being the
ones that wrote the software in the first place.  I do not think that
any 'set this up' was ever done, aside from handing over a copy of the
software.  Which was really general purpose AD and DA conversion
routines in the first place  unlikely to get you in trouble
 The first I heard of the trouble we had was when somebody ran my
diagnostics on the dead and dying monkeys and spit out my phone number
as a place to call if things were not working.

The real rule was not 'always mount a scratch monkey' but 'always
mount them read-only'.  Which was violated with catastrophic results.
But, yeah, the story is more or less correct.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Microsoft hockeyapp doesn't care about 2045 RFC (6.4)

[Laura Creighton]

In a message of Sat, 14 Oct 2017 14:37:09 -0400, David Levine writes:
>Laura wrote:
>
>> could we have a switch that just edits the wretched mail for you
>
>mhfixmsg(1) should do exactly what you want.  Specifically, its -fixcte
>switch, but that's enabled by default.
>
>Its man page has examples of integration with inc and procmail.
>
>David

Aha, now I need to learn this thing, thank you.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] Microsoft hockeyapp doesn't care about 2045 RFC (6.4)

[Laura Creighton]

Hockeyapp is a program that was developed somewhere else but then
purchased by Microsoft, or so I am told.  You can probably do a lot of
things with it, but what we are doing is coordinating an alpha and now
beta test of a game that runs under IOS, android and via steam for
Linux, Mac and Windows.

Every time Cory sends out a notification about a new release from
inside the app we all get mail like this:

   Date: Fri, 13 Oct 2017 19:24:47 + (UTC)
   From: "Cory Trese (via HockeyApp)" 
   Reply-To: cory.tr...@gmail.com
   To: l...@openend.se
   Message-ID: <59e112fe7b2ee_5f6d3fc193089078187...@ip-10-238-166-240.mail>
   Subject: New Version of Star Traders 2 Available
   Mime-Version: 1.0
   Content-Type: multipart/alternative;
 boundary="--==_mimepart_59e112fe7854b_5f6d3fc193089078187456";
 charset=UTF-8
 Content-Transfer-Encoding: base64
 X-Auto-Response-Suppress: All
 X-SG-EID: 
 
 ==_mimepart_59e112fe7854b_5f6d3fc193089078187456
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: base64

-
The sharp-eyed among you will have noticed that this is in violation of RFC 
2045.

nmh catches this, and spits out this message when I try to read the mail:

> show
> (Message inbox:673)
> mhshow: "multipart/alternative" type in message 673 must be encoded in
> 7bit, 8bit, or binary, per RFC 2045 (6.4).  One workaround is to
> manually edit the file and change the "base64"
> Content-Transfer-Encoding to one of those.  For now, continuing...

I've been in discussion about this with Microsoft, and their position
boils down to 'don't give a damn, get a new mailer that is more permissive'.
The workaround works, but I am getting sick of editing my mail by hand --
(or semi-hand, this looked like a job for sed to me, which also works).

I realise that there is something wrong-headed in taking out my frustration
with Microsoft on the fine folks here, but could we have a switch that just
edits the wretched mail for you, or asks if you would like to have it edited,
or something?  Maybe there are other times when being wrong but permissive
would be convenient?

Laura



___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] scan doesn't appear to understand language encodings

[Laura Creighton]

In a message of Fri, 02 Jun 2017 09:10:42 -0400, Ken Hornstein writes:
>>Show prints things perfectly, of course.  But it caused me to wonder.  If
>>scan can understand how to print 'Hallén' then surely it could understand
>>how to print 'Södermannagatan' as well?
>
>Sigh.  Technically the problem is with CHARACTER set encodings, not language
>encodings (we handle language encodings as well as any other MUA, in the
>sense that we ignore them).

>I suspect it would display properly IF the encoding was 8-bit and the
>character set matched your native character set; I'm guessing by what
>you showed your local character set is UTF-8, but it was encoded in
>ISO-8859-1 (or something close to that).

Got it in 1.  Thank you for the explanation.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] scan doesn't appear to understand language encodings

[Laura Creighton]

In a message of Fri, 02 Jun 2017 11:40:40 +0100, Ralph Corderoy writes:
>Hi Laura,
>
>> 374  06/01 Jacob Hallén   Fang Yuan Shi Wu<>
>
>I would guess the `From' header encoded `Hallén' and nmh was happy to
>decode.  Judging by the single question mark, I think the body has a
>single byte for the `ö', but that isn't valid for its stated encoding,
>e.g. UTF-8.
>
>It would be useful to have these headers,
>
>From
>Content-Type
>Content-Transfer-Encoding
>
>and the start of the body from the email's file, i.e. without nmh's
>interpretation.  That may need a `cat -A' or similar to have the odd
>byte be representable.
>
>-- 
>Cheers, Ralph.
>https://plus.google.com/+RalphCorderoy

cat -A (indented one tab) follows.  The entire text of the mail was the
address, Södermannagatan 37.  (and yes, the food was good there, too.)
Laura


Return-Path: $
Received: from jacob.localnet (c83-251-50-145.bredband.comhem.se 
[83.251.50.145])$
^I(authenticated bits=0)$
^Iby theraft.openend.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 
v51LnwAN028750$
^I(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 
verify=NO)$
^Ifor ; Thu, 1 Jun 2017 23:49:59 +0200$
From: Jacob =?ISO-8859-1?Q?Hall=E9n?= $
To: l...@openend.se$
Subject: Fang Yuan Shi Wu$
Date: Thu, 01 Jun 2017 23:49:51 +0200$
Message-ID: <2804100.3QMpKmKeAn@jacob>$
User-Agent: KMail/5.2.3 (Linux/4.9.0-3-amd64; KDE/5.28.0; x86_64; ; )$
MIME-Version: 1.0$
Content-Type: text/plain; charset="iso-8859-1"$
X-Greylist: Sender succeeded SMTP AUTH, not delayed by 
milter-greylist-4.5.11 (theraft.openend.se [82.96.5.2]); Thu, 01 Jun 2017 
23:49:59 +0200 (CEST)$
Content-Transfer-Encoding: 8bit$
X-MIME-Autoconverted: from quoted-printable to 8bit by 
theraft.openend.se id v51LnwAN028750$
X-DSPAM-Result: Whitelisted$
X-DSPAM-Processed: Thu Jun  1 23:50:00 2017$
X-DSPAM-Confidence: 0.9997$
X-DSPAM-Probability: 0.$
X-DSPAM-Signature: 59308c08287566178311967$
$
SM-vdermannagatan 37$
$


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] scan doesn't appear to understand language encodings

[Laura Creighton]

One of the nice things about scan is that, if the subject line is short,
you get something like this:

nnn  06/01 Mail SenderSubject<>

I got this today.

374  06/01 Jacob Hallén   Fang Yuan Shi Wu<<S?dermannagatan 37 >>

(This is a restaurant in Stockholm where we will meet for lunch.)  All
fine and good but why did scan choke on the second letter of
'Södermannagatan'.  (Which some of you Americans may be choking on
right now, if your encoding is ascii.  It looks like a lower case 'o'
with two dots over it.)  Interestingly enough the 'é' in Hallén was presented
properly (that is an 'e' with a rising accent above if you are in ascii).

Show prints things perfectly, of course.  But it caused me to wonder.  If
scan can understand how to print 'Hallén' then surely it could understand
how to print 'Södermannagatan' as well?

Laura Creighton

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Segfault in post from mime quoted names in aliases

[Laura Creighton]

In a message of Thu, 13 Apr 2017 09:04:11 +0200, Johan Viklund writes:
>Ken Hornstein (>):
>>I'll be looking at this ... but it looks like to me the encoding isn't
>>necessary for this user, because no characters are actually encoded in
>>that name?
>
>Well that's not a name I have in my alias file anyway, I was just trying to
>figure out whether it had anything to do with decoding non ascii characters or
>not.
>
>
>>Johan didn't say what his operating systems was, but I had guessed a Linux
>>system.
>
>Sorry about that, it's OS X.
>
>
>>It occurs to me that a group cannot start with '?', so a simple solution
>>would be to just treat '=?' as the start of literal text; that would take
>>care of any RFC-2047 encoded addresses.
>
>I would be very happy for this. Besides, does anybody use this unix-group
>feature as it's supposed to be used?
>
>-- 
>Johan Viklund

I have piles of Swedish names that would benefit, though mine would all be
encoded UTF-8

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] OT: Content-Type boundary Matching /^_av-/.

[Laura Creighton]

In a message of Fri, 03 Feb 2017 10:57:05 +, Ralph Corderoy writes:
>Hi,
>
>I've noticed an increase in spam I get over the last couple of months.
>I normally get quite a bit, but it shot up for a good few weeks and has
>only recently come back down as, presumably, the bullet found its home.
>But what struck me as odd is the vast bulk of the spam received has a
>MIME boundary that starts "_av-".
>
>Content-Type: multipart/alternative; boundary="_av-Pq8nHjSyZNgotR7Q4uzLwA"
>
>I've looked for this in my ham, but don't find any, e.g.
>
>pick --content-type _av-
>
>Presumably, some PHP email library beloved by spammers slaps on such a
>boundary for if it were the spam-producing software itself it would make
>detection rather trivial in most cases.
>
>So, my off-topic question is does anyone here have an idea what produces
>_av-, perhaps by having ham with a Mailer, etc.  I've tried the various
>code-search engines, but they're all useless;  electing to ignore and
>not index characters in "=-+_...".  Russ Cox's Google Code Search is
>much missed.
>
>-- 
>Cheers, Ralph.
>https://plus.google.com/+RalphCorderoy

I have piles and piles of legitimate mail from Patreon that use this boundary
marker.  Want me to send you some?

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

>Really, the safest thing to do for Laura's case is to use the MH environment
>variable to point to a new .mh_profile that has it's own Path that doesn't
>stomp all over your personal mail directory.

Which, undoubtably, is why I have never run into this before.  However,
if the whole machine with your personal mail directory isn't accessible,
you might just decide to ssh over to a machine that _is_ working as you
send mail to the rest of the company outlining the extent of our
hardware misery due to the power blackout.  The script you wrote so
that your friend can have Polish Language digests read to him is not
on the top of your mind, as such a time, alas.

Sounds like more of Charles Perrrow's Noral Accidents to me.  Sorry again
for griping to you all.

Laura

>--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Tue, 03 Jan 2017 04:42:19 +0700, Robert Elz writes:
>Date:Mon, 02 Jan 2017 15:45:36 -0500
>From:Ken Hornstein 
>Message-ID:  <20170102204537.c39325a...@pb-smtp1.pobox.com>
>
>
>  | Based on what you describe, I suspect what happened is that your digest
>  | bursting program overwrite your draft file between "repl" and "send",
>  | and your "send" sucessfully sent the digest.
>
>I was thinking the same, almost - my suspicion is that the digest burst
>and transmit destroyed the draft (as you suggest) and the the lack of the
>draft file is what caused Laura's send to fail/abort.   By the time that
>happened (even if nmh were capable of doing anything rational at that point)
>the draft was probably already gone.
>
>I would suggest using -draftfolder in all automated sending programs/scripts,
>it avoids any problems of this nature, but can also make it easier to debug
>any problems with the automated script.
>
>kre

Okay, will do.  Apologies for the complaint; I had forgotten all about
the automated script (not only that it existed, but that it was running
on the machine where I don't usually read my mail, but was using at the
time).

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 14:59:02 -0500, Ken Hornstein writes:
>>I checked.  Yes, he did receive a digest at about minight my time.
>>So, yeah, that was happening at that time.  I still think that 'found
>>an error trying to send something --> SAVE THAT DRAFT!!' would be a good
>>thing to have.
>
>Perhaps we didn't explain it very well, but nmh _does_ that.  But if one of
>the nmh programs crash (which maybe happened because something messed up the
>draft file?) then we don't really have the opportunity to do anything at
>that point.
>
>--Ken

But I am correct that nmh saved the file as something that I could have
overwritten later using a comp, reply or something like that?  What I was
suggesting was that, at the point where send (I think) failed, it would
be good if nmh made a super-special copy of the draft which, due to its
naming wasn't going to be overwritten.  Am I asking for the impossible?

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 13:00:15 -0500, David Levine writes:
>Laura wrote:
>
>> formatproc: /u/lac/bin/replyfilter
>>
>> could that be to blame?
>
>I doubt it.  I don't think you would have reached the whatnow prompt
>if it failed.

As far as I can tell, all it does it set up the annotation properly.
And that was the part that worked 

>I also doubt that procmail would bother anything in your drafts
>directory, but you might want to verify by looking in your .procmailrc.

There is one bit that takes an incoming message, always from a digest,
always arriving as 'text only, no-html' and arbitrarily bursts the
digest and then resends the messages out crudely repackaged as individual
html mail to a friend of mine who has become blind and who needs to
read his mail in a browser.  I'm using mh commands to resend this lot
out because sometimes there are attachments.

I checked.  Yes, he did receive a digest at about minight my time.
So, yeah, that was happening at that time.  I still think that 'found
an error trying to send something --> SAVE THAT DRAFT!!' would be a good
thing to have.

Laura

>
>David
>
>___
>Nmh-workers mailing list
>Nmh-workers@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/nmh-workers

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 17:32:49 +, Ralph Corderoy writes:
>Hi Laura,
>
>Ken wrote:
>> It would be interesting to make sure that in your drafts folder there
>> exist a bunch of old messages with backup prefix.
>
>And that they linger, undisturbed.  You could even deliberately create
>one with a high number that's unlikely to be used in practice to see it
>remains, e.g. `touch mail/drafts/,3141'.

They go back to 2011.  And yes, one created that way remains.  So I am
leaning towards blaming procmail.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 12:23:04 -0500, Ken Hornstein writes:
>>There was time for me to go to the kitchen, pour me a drink, come back
>>and 'ohhh.  What's this on my screen?', so plenty to time for something
>>to munge things beneath me.  Alas.  I was hoping that a smarter send could
>>understand that the hassle involved in removing an unwanted draft is minor,
>>and so cautiuously bump the draft number for subsequent messages so that
>>there was no chance of reusing the draft number if it ever detected a
>>problem, or, alternatively making an emergency backup from outside the
>>draft sequence altogether.  Too hard?
>
>AFAIK, this is what is supposed to happen (and does, in my experience).
>Nothing in nmh deletes the draft; as Ralph pointed out, it always
>renames the draft, so 42 becomes ,42, no matter what your rmmproc does.
>If send fails, 42 is left around and the next time you run repl/comp,
>you should get 43.  So I'm really at a loss as to what happened here.
>
>It would be interesting to make sure that in your drafts folder there
>exist a bunch of old messages with backup prefix.

more than 100 of them.
>
>--Ken

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 16:27:54 +, Ralph Corderoy writes:
>Hi Laura,
>
>> But my real query is about this 'apparently successful send'.  Why
>> wasn't it apparent that the send wasn't successful?  Shouldn't a check
>> of return codes have discovered the problem?
>
>What happens to successfully sent emails?  Passed to a local MTA?  A
>remote one?  Does that leave a log trace in those third parties?  Is
>there any sign the missing email reached them?  Could it be stuck
>somewhere?

Local, this happened to the nmh that is running on the mailserver.
There are logs, and no trace of the missing mail in the logs.  Nothing
is stuck.

Laura
>-- 
>Cheers, Ralph.
>https://plus.google.com/+RalphCorderoy

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 11:10:03 -0500, Ken Hornstein writes:
>>But my real query is about this 'apparently successful send'.  Why wasn't
>>it apparent that the send wasn't successful?  Shouldn't a check of return
>>codes have discovered the problem?
>
>That is checked, and certainly if there is a problem I've always been
>returned to the whatnow prompt.  And I can't find a code path where the
>draft gets deleted by send or repl.  So it's not that I'm doubting what
>you say happened, but it sounds like some time elapsed between when you
>got this error and when you went looking for the draft.  I'm forced to
>conclude that something else came along and deleted or overwrote that
>draft.

There was time for me to go to the kitchen, pour me a drink, come back
and 'ohhh.  What's this on my screen?', so plenty to time for something
to munge things beneath me.  Alas.  I was hoping that a smarter send could
understand that the hassle involved in removing an unwanted draft is minor,
and so cautiuously bump the draft number for subsequent messages so that
there was no chance of reusing the draft number if it ever detected a
problem, or, alternatively making an emergency backup from outside the
draft sequence altogether.  Too hard?

Laura

>--Ken


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 10:11:06 -0500, Ken Hornstein writes:
>>I was replying to somebody and got:
>>*** Error in `/usr/bin/mh/repl': free(): invalid pointer: 0x08080547 ***
>>/u/lac/bin/ra: line 2:  5931 Aborted/usr/bin/mh/repl -group -format
>
>I know we've had a number of double-free errors and other memory-management
>related issues that we've stomped out over time; if you can provide us
>with a reproducible test case (I know you said that it didn't happen
>again), we'll track it down.

Thank you, but since I have never seen this before, and use mail all the
time, I suspect that debian will come out with 1.7 before I see another
one.

>--Ken

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 10:06:50 -0500, David Levine writes:
>Laura wrote:
>
>> I think _after_ the whatnow(1) prompt, as well, but it has long since
>> scrolled away.  I don't remember the shell complaing about receiving an
>> unwanted 'send', so I think that whatnow received it.
>
>So it sounds like you did tell whatnow to send.
>
>Was the draft renamed to a backup file?  That would be in your
>drafts directory and named with the draft message number prefixed
>with a , (by default).  And there might also be a similarly named,
>but with a .orig suffix, earlier draft file.
>
>If you use repl -annotate, was the message that you replied to
>annotated?

Yes.

>Did you use send -push, either from the keyboard or in your profile?

No.

>So many things have changed since 1.6 that I won't try to guess at
>the cause.  But I would expect to find a backup draft file if the
>draft is gone:  the draft is renamed to the backup file immediately
>after an apparently successful send.  The backup would have been
>overwritten if you then created and sent another message, using a
>draft with the same message number.

It's possible.  But the symptom wasn't 'I found a file with approximately
the correct timestamp, but it wasn't the one I was looking for, but something
I wrote later, or something that procmail could have written later' but
rather, 'went looking and found nothing with the correct timestamp.

But my real query is about this 'apparently successful send'.  Why wasn't
it apparent that the send wasn't successful?  Shouldn't a check of return
codes have discovered the problem?

>David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 14:56:33 +, Ralph Corderoy writes:
>Hi Laura,
>
>> emacs.
>>
>> > What does `mhparam draft-folder' give?
>>
>> drafts (which seems to be working just fine -- drafts are indeed being
>> created here)
>
>So emacs will have been editing drafts/42, say.
>
>> > Did repl die after you quit the editor and before the whatnow(1)
>> > prompt?
>>
>> Definitely after I quit the editor.  I think _after_ the whatnow(1)
>> prompt, as well, but it has long since scrolled away.  I don't
>> remember the shell complaing about receiving an unwanted 'send', so I
>> think that whatnow received it.
>
>That shell's history might show any unexpected `send'.

But it, too, is irrevocably lost.

>rmmproc, if set, isn't used in the deleting of drafts.  When drafts/42
>is finished with, any existing drafts/,42 is unlinked and then 42
>renamed to ,42.  Do you see these old drafts in your drafts directory
>from general use?

Yes.

>Could another draft composition have occurred, taking the same message
>number in the drafts folder, between repl's failure and you realising it
>hadn't been sent and looking for your lost work?

Maybe, if procmail went and did something automatic with incoming mail.
I don't do a lot of that, so I would have to be very unlucky.

>-- 
>Cheers, Ralph.
>https://plus.google.com/+RalphCorderoy

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In a message of Mon, 02 Jan 2017 13:01:34 +, Ralph Corderoy writes:
>Hi Laura,
>
>> /usr/bin/mh/repl -group -format
>...
>> I was replying to somebody and got:
>> *** Error in `/usr/bin/mh/repl': free(): invalid pointer: 0x08080547 ***
>> /u/lac/bin/ra: line 2:  5931 Aborted/usr/bin/mh/repl -group -format
>
>I get similar looking malloc corruptions with nmh 1.6-3 on Arch Linux
>when mhshow(1)ing the minority of spam emails.  It doesn't happen with
>the git version.

I'm using debian linux, so perhaps the problem is upstream of arch linux?
repl -version says:
repl -- nmh-1.6 [compiled on binet at Sun Jul  6 03:51:09 UTC 2014]

memory and disk tests around here haven't found a problem.

>> But I expected to find my draft of the message still around so that I
>> could resend it.  Nope.  All gone.  Nothing there.
>
>Did repl start an editor, e.g. vi?

yes.  emacs.

>What does `mhparam draft-folder' give?

drafts (which seems to be working just fine -- drafts are indeed being created
here)

>Did repl die after you quit the editor and before the whatnow(1)
>prompt?

Definitely after I quit the editor.
I think _after_ the whatnow(1) prompt, as well, but it has long since
scrolled away.  I don't remember the shell complaing about receiving an
unwanted 'send', so I think that whatnow received it.

The mail did not go out to the person I was replying to, and the
copy cc'd to me also did not arrive.

Laura

>Cheers, Ralph.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] nmh should be more careful about when it unlinks draft files

[Laura Creighton]

In my bin I have a trivial shell script, called ra, reproduced here in
its entirity.

stty echo icanon crterase
/usr/bin/mh/repl -group -format

(I was having problems at a particular site with a program that kept
dying on me and leaving me in an unpleasant mode, so I added the first line.
It's not needed now, but I never thought about it again, so this cruft
endured.)

I was replying to somebody and got:
*** Error in `/usr/bin/mh/repl': free(): invalid pointer: 0x08080547 ***
/u/lac/bin/ra: line 2:  5931 Aborted/usr/bin/mh/repl -group -format

I cannot reproduce this error.  Maybe our disk is going bad, will run some
tests for that, next.  But I expected to find my draft of the message still
around so that I could resend it.  Nope.  All gone.  Nothing there.  Can
we be a little more careful about this?

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] reply attribution?

[Laura Creighton]

In a message of Wed, 19 Oct 2016 23:22:08 +0200, Laura Creighton writes:
>In a message of Wed, 19 Oct 2016 13:30:00 -0400, Paul Fox writes:
>
>The above line is what you want, right?
>
>>i looked briefly at adding that support, but quickly realized it would
>>be beyond my meager perl skills to do so.
>>
>>so:  is reply attribution something that people that use replyfilter
>>miss?
>>
>>paul
>
>I have this one line in mhl.reply
>
>from:nocomponent,formatfield="%(decode (friendly{text})) writes:"
>
>which is all I think it took for it to do it.
>
>Laura

ah, well, the line before is:
formatfield="In a message of %(pretty {text}), "

As yours is likely different 

sorry about that.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] reply attribution?

[Laura Creighton]

In a message of Wed, 19 Oct 2016 13:30:00 -0400, Paul Fox writes:

The above line is what you want, right?

>i looked briefly at adding that support, but quickly realized it would
>be beyond my meager perl skills to do so.
>
>so:  is reply attribution something that people that use replyfilter
>miss?
>
>paul

I have this one line in mhl.reply

from:nocomponent,formatfield="%(decode (friendly{text})) writes:"

which is all I think it took for it to do it.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Laura Creighton]

In a message of Wed, 19 Oct 2016 11:38:45 -0400, David Levine writes:
>I'll do 1), but the other steps would be up to you.

Thank you very much.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Laura Creighton]

In a message of Wed, 19 Oct 2016 11:46:31 -0400, David Levine writes:
>OK.  I'm not going to add a -locale switch, that seems to me to move this
>too close to nmh.  I like the locale profile component.  Let me ask those
>who might use it:  do you also want the NMH_LANG environment variable?  I'd
>rather not add a feature that won't be used.
>
>David

I don't think I would be using it.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Laura Creighton]

And, of course, I do use attach at the What Now? prompt.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Laura Creighton]

In a message of Tue, 18 Oct 2016 15:13:49 +0100, Ralph Corderoy writes:
>There's a mechanism for telling a hierarchy of programs their locale;
>environment variables.  You're using it, but you're telling some of them
>a different locale to what you really want them to use.

People do this a lot around here.  Due to the extremely poor placement
of the '{' and '}' keys, right-alt-shifted-7 and right-alt-shifted-0
(yuck!) people who need to type braces at speed pop in and out of
us-ascii all the time.  I suspect these days there are less invasive ways
to say 'change my keyboard layout' but this is what people have become
used to.  

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Laura Creighton]

In a message of Tue, 18 Oct 2016 14:17:24 +0100, Ralph Corderoy writes:
>Hi Tom,
>
>If you just have one long-running Emacs then can't that be in the UTF-8
>locale?  Or is your C-needing ls(1) run from inside that?
>
>Have Emacs highlight non-ASCII characters in that mode wherever they
>come from, e.g. paste from web browser?  Have a function that maps the
>common ones to ASCII, perhaps using recode(1)?  Filter the buffer when
>writing the file, erroring if it can't be written?  Then you can send
>valid US-ASCII emails.
>
>-- 
>Cheers, Ralph.
>https://plus.google.com/+RalphCorderoy

I don't know about Tom, but my problem isn't that I want to send valid
US-ASCII emails, but that I _never_ want to send valid us-ascii emails.  Even
when replying to mail that is encoded us-ascii, or when sitting at
a workstation that isn't mine, which has that as its locale, or, has
no locale set and is defaulting to C or however else you can get nmh
to conclude you want us-ascii ...  And the last thing I want to
happen is for nmh to not be able to tell what I want, stick in us-ascii
(because the thing needs a content header, and that's the default), and
then give me grief because the mail I assembled with some script somewhere
contained lots of invalid us-ascii.  This, I thought, was what was happening
to Tom, or whoever it was who had the bad emacs-nmh experience.

I thought that mh_profile would be a good place to send a love letter to
nmh.  "Dear nmh. I see that you cleverly concluded that I wanted
us-ascii.  Alas, you were wrong.  Just be a good chap and give me utf-8.
Thank you."

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Laura Creighton]

In a message of Mon, 17 Oct 2016 17:21:18 -0400, Ken Hornstein writes:
>I agree that we can't reasonably know what the character set is supposed
>to be in that case.  But I would say that given the choice between
>sending 'something wrong' and 'erroring out', 'erroring out' is the more
>correct option.  But I would be interested in hearing what other people
>think.

I believe that nmh users are sophisticated enough that they actually
know what a Locale is, and an encoding, and if they google for more
information they will understand what they read.  I think that they
are going to want a way to specify what they want in their mh_profile
though.

We have a terminal room with shared workstations that all have a
very restricted number of Mathematica licenses.  I haven't been there
for a few years, but it used to be the case that Mathematica wanted
LC_ALL=C which had the result that people couldn't send mail from
those terminals using some of their favourite mailers, and moreover
had absolutely no clue as to what was wrong.  One thing I do not
know is how common it is, these days, for people to share computers.

A long time ago it was common.  Then it became uncommon, as everybody
used their own personal laptop.  These days, at least around here, there
is a sizable segment of the population which doesn't own  anything
larger than a cell phone or a tablet, so the demand is on, again
for shared spaces.

True where you are?

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Laura Creighton]

In a message of Mon, 17 Oct 2016 21:41:08 +0100, Ralph Corderoy writes:
>Hi Laura,
>
>> Just giving them utf-8 even though that wasn't what they asked for has
>> fixed a huge number of headaches when running mailing lists around
>> here.
>
>Does that mailing-list software check that what they're sending out is
>valid for the encoding they claim, UTF-8?  Or when replying to an ISO
>8859-13 do they send invalid UTF-8 back?
>
>-- 
>Cheers, Ralph.
>https://plus.google.com/+RalphCorderoy

It does some checking.  I'm pretty sure that I could construct some cases
that would break it, but there was no great demand for that.  While, on
the other hand, mail that claims to be US-ASCII but is really UTF-8
happens all the time.  The weekly report from the Python bug tracker,
for instance, insists that its mail is US-ASCII no matter how many bug
reports that I send about the fact that people are signing their bug
reports with their non-ASCII names.

Things may be different where you are, but around here, when there is a
difference of opinion between what the encoding says, and what the
content has inside it, and the encoding is US-ASCII, the encoding is
always wrong.  "You got an 8-bit char in your mail by mistake" is not
a common problem here, and, when it does occur, it's not a problem that
people care about, or rather they care about it just as much as they do
about any other typo in their mail -- if they didn't run the thing
through a spell checker, then it wasn't one of those important pieces
of mail where perfection in content matters, but more like this one,
where if I make a typo, I will trust that you will suffer through
it with no long term ill effects.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Laura Creighton]

In a message of Mon, 17 Oct 2016 13:42:37 -0400, Ken Hornstein writes:
>Also, it kind of strikes me as the wrong solution, and not just because
>of the additional complexity.  The locale setting is supposed to
>indicate to utilities which character set you're using.  So we (rather
>reasonably, I would argue) use that in nmh to determine the character
>set for input and display.  If you're putting an 8-bit character into
>a message when you've told us that you are always going to be sending
>US-ASCII ... well, what are we supposed to do?  That seems like an error
>condition to me.  You can explicitly override the character set in your
>draft for a single message (see mhbuild(1)) if you want to do something
>different for individual messages, but absent that I think going with the
>locale character set is the only solution.
>
>--Ken

The problem is that most of the time people who have the locale US-ASCII
set do so when what they want is 'English, US or Brit doesn't matter,
but keep all the extra characters that other people are using when,
for instance writing their names'.  They don't want their mail to fall over
because they are replying to Åsa Krigström in Nyköping.

Just giving them utf-8 even though that wasn't what they asked for
has fixed a huge number of headaches when running mailing lists
around here.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Laura Creighton]

In a message of Mon, 17 Oct 2016 13:09:35 -0400, Ken Hornstein writes:
>>So I updated to the new RHEL6 package of nmh 1.6 (had been on 1.5).
>>I've found that it now wants to mime-ify outgoing mail and among
>>other things attaches
>>  Content-type: text/plain; charset="us-ascii"
>>Apparently, it's also trying to enforce that by rejecting any
>>non-plain-ASCII content.  This is a real pain, mainly because whatever
>>it's doing isn't playing well with exmh: the post simply silently doesn't
>>happen.  That's several notches below the already pretty awful handling
>>of post errors that I was used to.
>
>AFAIK, when send doesn't happen you should always get an error, and an
>exit with a non-zero error code.  Certainly when a send fails for me
>with exmh I always know about it.  This is assuming you don't use -push.
>So if this is failing, then that's a bug.  If you're using -push ... well,
>then what is happening is exactly what is supposed to be happening :-/
>
>Hm, in theory I see that you're supposed to get email back when push
>fails.  I'm not sure that's been tested in like forever.  I'm not actually
>sure what is supposed to do that.  Ah, alright ... I see there's an alert()
>function in uip/sendsbr.c.  I suspect we're not calling that if mhbuild
>fails.
>
>>I don't usually compose mail that isn't straight ASCII, but I've already
>>been burnt twice this morning by trying to forward text that included
>>a stray UTF8 character or two.
>>
>>Any suggestions on how to improve this?  Ideally I'd like it to pass
>>through what it's told to, perhaps changing the charset marking to
>>utf8 when necessary.
>
>Well, that's what supposed to happen, and that's what happens for me.
>
>I have a strong suspicion that if you were to get the error back (e.g.,
>not use -push if you are), it might show something like this:
>
>Text content contains 8 bit characters, but character set is US-ASCII
>
>Which would happen if (a) you put an 8-bit character in your draft, and
>(b) your locale is set to US-ASCII.  Nmh takes the character set to use
>out of the user's locale.  If you're forwarding an email without using
>MIME forwarding, then nmh doesn't have any idea what the character set
>should be; that might be a problem because it could guess wrong.
>
>Solutions include:
>
>- Using MIME forwarding (forw -mime)
>- Setting an 8-bit locale, but you might get the character set wrong there.
>
>If things are really crapping out with no error and you're not using -push,
>clearly that's a bug we need to fix.  Also, I guess we should probably send
>an error email if -push is being used and mhbuild fails.
>
>--Ken

Since us-ascii is a perfect subset of utf-8, is there any reason that nmh
couldn't take a look at the locale, and if it is us-ascii just use uft-8?

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Starting the final call for features for 1.7

[Laura Creighton]

In a message of Sun, 25 Sep 2016 14:05:15 -0400, Paul Fox writes:
>david wrote:
> > Paul wrote:
> > 
> > > any reason we couldn't in principle have a separate git tree on
> > > savannah just for "compiled" man pages, and other docs?
> > 
> > Is there really a need?
>
>true, i wondered that too.
>
> > 
> > And a separate tree is more likely to get out of sync.
>
>i figured it would only be built at "new release announce" time.
>
>paul

Problem:  I didn't know that replyfilter and docs/contrib/replyfilter existed.

I'd like a solution where  -version pointed me at something
that told me that this existed.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Starting the final call for features for 1.7

[Laura Creighton]

In a message of Sun, 25 Sep 2016 12:57:19 -0400, David Levine writes:

>How about this, in nmh(7) and the output from install-mh(1):
>
>BUGS
>   Send bug reports, questions, suggestions, and patches to nmh-
>   work...@nongnu.org.  That mailing list is relatively quiet, so user
>   questions are encouraged.  Users are also encouraged to subscribe.
>
>   If problems are encountered with an nmh program, they should be
>   reported to the local maintainers of nmh, if any, or to the mailing
>   list noted above.  When doing this, the name of the program should be
>   reported, along with the version information for the program.
>
>   To find out what version of an nmh program is being run, invoke the
>   program with the -version switch.  This prints the version of nmh, the
>   host it was compiled on, and the date the program was linked.
>
>   New releases and other information of potential interest are announced
>   at http://www.nongnu.org/nmh/ .

This looks good to me.

>> This is one place where I would like a link to documentation, at some
>> master site, (so you can read it even if the docs never made it to
>> where they are supposed to be for your distro.)
>
>Unfortunately, there isn't such a site.  If the man pages didn't get
>installed, that's a packaging problem.  Modern nmh should be easier for
>packagers to deal with than older versions.

Ah, I was talking about the case where there is a man page, but no
user documentation.  Lots of places I go don't install the documentation
everywhere, just some places.

If we have a git page, and this for browsing the source
http://git.savannah.gnu.org/cgit/nmh.git

then we ought to find it easy to make the docs as git-browsable as
the code, no?

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Starting the final call for features for 1.7

[Laura Creighton]

In a message of Sun, 25 Sep 2016 12:15:40 +0100, Ralph Corderoy writes:
>Hi,
>
>Laura wrote:
>> For instance, I was blissfully unaware of this mailing list and that
>> nmh was ever under active development until a few years ago, and I
>> suspect that there are quite a few others out there who are still in
>> this position.
>
>Consisdering very long-term users, and new users, nmh(7) says, right at
>the very end,
>
>BUGS
>If problems are encountered with an nmh program, the problems
>should be reported to the local maintainers of nmh.  When doing
>this, the name of the program should be reported, along with the
>version information for the program.

For what it is worth,

I interpreted this to mean local sysadmins at the site where you are
running nmh, i.e. somebody at Chalmers University, not you people.  If
you want to hear from people, I think you need to be a whole lot more
welcoming.

>
>To find out what version of an nmh program is being run, invoke
>the program with the -version switch.  This prints the version
>of nmh, the host it was compiled on, and the date the program
>was linked.

This is one place where I would like a link to documentation, at some
master site, (so you can read it even if the docs never made it to
where they are supposed to be for your distro.)

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] TLS certificate validation

[Laura Creighton]

Be aware of this problem with windows:

https://bugs.python.org/issue20916
If you just ask Windows to enumerate the certificates it knows about, it
won't pull anything down.  I think this is since Vista, but I could be
wrong about that.

It's not a new problem.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Starting the final call for features for 1.7

[Laura Creighton]

In a message of Sat, 24 Sep 2016 16:44:38 -0400, David Levine writes:
>Laura wrote:

>I don't think you need that with nmh 1.6, and you shouldn't with 1.7,
>assuming your locale (LANG, LC_ALL, or LC_CTYPE environment variable)
>is set to a utf-7 or utf-8 (preferred by some) locale.

Yes, but I need my .mh_profile to work _everywhere_ including on machines
that are purposely not set to utf-8 so we can test software there.

>> The problem is that you typically get your new nmh one day when you, or
>> maybe the sysadmins at work, do a system-wide update.  Since you never
>> asked for it to get changed, you never noticed that you have a new
>> version (unless things stop working for some reason). I am not sure what
>> the best way to handle this is,
>
>Build your own nmh?  If you want to give that a quick try:
>
>$ git clone git://git.savannah.nongnu.org/nmh.git
>$ cd nmh
>$ docs/contrib/build_nmh -div

I can do this, but the problem I am talking about is not 'how do I get
my own nmh, should I need to build one' but 'how to inform users whose
nmh has changed out from under them, because the package just was updated
on their distribiution that this has occurred', with the added proviso
that the person doing the update may not be the person using nmh.

For instance, I was blissfully unaware of this mailing list and that
nmh was ever under active development until a few years ago, and I
suspect that there are quite a few others out there who are still in
this position.  We just didn't give it any thought, like all things that
quietly go on working without needing any effort on our part.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Starting the final call for features for 1.7

[Laura Creighton]

In a message of Sat, 24 Sep 2016 15:52:41 -0400, Ken Hornstein writes:
>>I think this may be an advantage of living in a part of the world
>>where ASCII is too small.  Once I got unicode up and working as text,
>>that is pretty much all I have to worry about.  iso-8859 is finally
>>dying around here, though I still have this mouthful in my .mh_profile
>>to handle it.
>
>I am still kind of surprised that you don't see more; it seems to me
>that a lot of programs want to base64 anything if they see anything with
>the high bit set.  The mailing list software used here is one example;
>it will automatically reencode the message as base64 if it sees any
>8-bit characters.

Hmmm.  You are right about that.  And of course I see mailman mailing
lists with the default charset as unicode all day long.  So I have
likely misunderstood my problem.  Next time I get one I will make sure
to save it for forensic analysis.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] EAI?

[Laura Creighton]

In a message of Sat, 24 Sep 2016 11:33:58 -0400, David Levine writes:
>Resurrecting an old topic, Email Address Internationalization (EAI).
>The original message is at
>http://lists.nongnu.org/archive/html/nmh-workers/2015-08/msg0.html
>
>It doesn't mention RFC 6531, SMTP Extension for Internationalized
>Email, which is what this message is mostly about.
>
>Ken wrote:
>
>> - SMTPUTF8 looks relatively straightforward to implement, at least.
>
>I've done that on a branch, smtputf8.  I'd like to include it in 1.7.
>
>One design issue is how should the user enable sending of 8-bit
>(UTF-8 encoded) addresses.  My first attempt was two explicit steps,
>one to disable RFC 2047 encoding of addresses in the draft message
>and the other to instruct post, via send, to use SMTPUTF8, if
>supported by the SMTP server.  In terms of What now? responses:
>
>What now? mime -headerencoding utf-8
>What now? send -eai
>
>But to make it more convenient and remove potential mismatches, that
>-eai switch in the second step could be removed, so it would just be
>send as usual.  post would look at the draft and automatically use
>SMTPUTF8 if it has any 8-bit header field bodies.

Whatever we come up with, I will need a setting for 'default utf'
to handle my little corner of the world.  I don't want to type send -eai
for practically every piece of mail I create or reply to. :)

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Starting the final call for features for 1.7

[Laura Creighton]

In a message of Sat, 24 Sep 2016 10:41:18 -0400, Ken Hornstein writes:
>>My nmh displays base-64 encoded mail just fine, but if you try to reply
>>or forward with the message quoted, it doesn't convert.  I get a base-64
>>encoded mail about once every 5 years, so it hasn't been worth complaining
>>about, and for all I know you have already fixed this.  But I thought it
>>was worth mentioning.
>
>Wow, ONLY once every 5 years??  I get those like a few times a day!  Well,
>that also includes email with quoted-printable and having a few weird
>characters.

I think this may be an advantage of living in a part of the world
where ASCII is too small.  Once I got unicode up and working as text,
that is pretty much all I have to worry about.  iso-8859 is finally
dying around here, though I still have this mouthful in my .mh_profile
to handle it.

mhshow-show-text/plain: \
iconv -f "$(charset=$(echo %a | sed -n -r 's/.*charset="
?([-a-zA-Z0-9_]*).*/\1/p');
if [ x$charset = xunicode-1-1-utf-7 ]; then echo utf-7;
else echo ${charset:-iso-8859-1}; fi)" | less

I forgot about quoted printable -- I do get those, but very, very, very 
rarely.  I never figured out what quoted printable is for.

>David already pointed you toward replfilter; that's been around for a
>while (since 1.5) and I thought it was well known, but still people
>don't know about it.  Like most of the MIME support in nmh, it's kind of
>bolted on, but it does make MIME replies reasonable.

The problem is that you typically get your new nmh one day when you, or
maybe the sysadmins at work, do a system-wide update.  Since you never
asked for it to get changed, you never noticed that you have a new
version (unless things stop working for some reason). I am not sure what 
the best way to handle this is, but these days I am very greatful
when programs come with a --help option, which refers you, amoung other
things, to where the documentation lives.

>You have two options: you can use dist(1), which some people find confusing
>when they receive a message used by it (the whole message ends up intact,
>and the sender appears in the "Resent-From" header), or forw -mime, which
>generates a mhbuild directive so you have to make sure you "mime" the
>message at the What now? prompt.  That makes the forwarded message into
>a message/rfc822 MIME part, and all of the MIME structure of the enclosed
>message is preserved.

But can I make interleaved comments just as I did on this piece of mail
in some mail that I am forwarding to others?

>In a future release I am hoping that by default repl(1) will be much smarter
>than it is now.  That's a much harder job that it appears.
>
>--Ken

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Starting the final call for features for 1.7

[Laura Creighton]

In a message of Sat, 24 Sep 2016 09:45:38 -0400, David Levine writes:
>Laura wrote:
>
>> My nmh displays base-64 encoded mail just fine, but if you try to reply
>> or forward with the message quoted, it doesn't convert.
>
>nmh 1.6 has docs/contrib/replyfilter, it contains usage instructions.
>
>nmh 1.7 will have (and current master has) docs/contrib/replaliases, it
>also contains usage instructions.
>
>David

Thank you.

Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Starting the final call for features for 1.7

[Laura Creighton]

In a message of Fri, 23 Sep 2016 22:16:36 -0400, Ken Hornstein writes:
>Greetings all,
>
>I think that we are starting to get close to being ready for a 1.7
>release.  I believe all of the features I wanted for 1.7 have been
>merged into master; there are one two other features I know that are
>being worked on, but I think that will be coming soon.
>
>At this point, I'd like to put out a call; if there are any features or
>bugs you'd like fixed in 1.7, now is the time to speak up.  Obviously
>priority will be given to feature requests that come with code :-)
>We can still implement bug fixes during a release cycle, but I'd like
>to get as many out of the way beforehand.
>
>So this is your chance; if there's something missing in nmh you'd like
>to see implemented in 1.7, please speak up now!
>
>--Ken

My nmh displays base-64 encoded mail just fine, but if you try to reply
or forward with the message quoted, it doesn't convert.  I get a base-64
encoded mail about once every 5 years, so it hasn't been worth complaining
about, and for all I know you have already fixed this.  But I thought it
was worth mentioning.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Mobile mail access (was: Re: Need some general advice)

[Laura Creighton]

If you can use an ubuntu phone/tablet
https://wiki.ubuntu.com/Touch

You can just download the debian mnh package (or I think these days
there is an ubuntu one as well, I did this a long time ago) and it just works.

Laura



___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Future directions for nmh

[Laura Creighton]

I'd just like to mention that I am still getting lots of use out of
the mh mail storage.  A lot of the mail that I receive is code checkins.
Perhaps when everybody on the planet has moved all of their code to
github (as seems to be happening whenever I turn around) I won't need
my tools to find out exactly who made the checkin that makes the tests
fail, but I would be seriously inconvenienced if mh directory mail store
went away.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] thread mangling python-list mailing list to comp.lang.python google group

[Laura Creighton]

I am using nmh 1.6.7

People are reporting problems with my mail.

I send mail as a reply to something I receive in the mailman
mailing list python-l...@python.org

People who are also on the mailing list seem to receive it fine.
It goes into the archives fine.


But then it goes into the python-list to comp.lang.python gateway
which people are reading as google groups.  So far only google groupers
are complaining, but the problem could be more widespread.

My mail shows up in the correct group (i.e. comp.lang.python) but in the
wrong thread.

So the gateway is mangling the threading somehow, at least as far as
I know.  Googling around found this bug discussion that possibly is relevant:
https://bugzilla.mozilla.org/show_bug.cgi?id=651527
though this is about Thunderbird, and a different mail-usenet gateway.

For example, if you look in
https://groups.google.com/forum/#!topicsearchin/comp.lang.python/\
python$20implementaiton$20of$20a$20new$20coding/comp.lang.python/6yaqHQVKTYM

(or search google groups for python implementation of a new integer
coding algorithm)

somewhere on page 8 you will find an article by me:

Laura Creighton
8:17 AM (5 hours ago)
Re: memory control in Python
Other recipients: ros...@gmail.com, pytho...@python.org, l...@openend.se

And this clearly belongs in the google group under the thread
'memory control in Python' -- which googlegroups has, but my reply isn't
in it.


If you look at the python-list archives:
https://mail.python.org/pipermail/python-list/2015-August/thread.html

Things seem to be threaded properly.

Has anybody seen this?  Better yet, knows how to fix it?

Laura Creighton




___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] thread mangling python-list mailing list to comp.lang.python google group

[Laura Creighton]

In a message of Tue, 18 Aug 2015 18:21:55 +0100, Ralph Corderoy writes:
Hi Ken,

 But nowadays things have been tightened up and from RFC 2822

2001-04.  ;-)

 is that it should only contain a Message-ID

It's allowed multiple.  It's my damn MUA that stands in the way!

$ repl last:42
repl: only one message at a time!

Cheers, Ralph.

The odd thing is that I remember changing this, sometime in the early
2000s.  But apparently somewhere between then and now I must have
restored files and overwritten my changes.  Given that 2005 (I think)
was the year of 4 laptops, I suppose that isn't too surprising.
(PyPy.  We can jit your python code.  If you do nothing but jit python
code all day long -- i.e. you are using PyPy to develop PyPy -- you
will find that cpus are not designed to work this hard, and will
fail.)  The surprising bit is that nobody has complained until last
week.

Thanks again,
Laura


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] thread mangling python-list mailing list to comp.lang.python google group

[Laura Creighton]

In a message of Tue, 18 Aug 2015 13:12:55 -0400, Ken Hornstein writes:
From a skim of the headers, you could try making your In-Reply-To comply
with RFC 2822.  IOW, have it contain just the message ID of the email
you are replying to and not the human-readable gunk around it.  (It can
actually have more than one message ID, but it's not References so you
probably just want the MID of the email given to repl(1).)  See RFC
2822, 3.6.4, `Identification fields'.

Ralph has given you the answer, but let me expand on it a bit.

Since in that message you refer to yourself as an 'old fart' and mention
programming in the 1970s, you've probably been using MH/nmh for approximately
forever.

Exactly.

Probably somewhere along the way you copied the MH-supplied
replcomps to your ~/Mail directory and modified it.  In doing that, you
copied the then-standard In-Reply-To format, which would generate things
like:

In-Reply-To: Message from Chris Angelico ros...@gmail.com of Wed,
 18 Feb 2015 20:36:10 +1100.

Way back in RFC 822, this format was fine.  But nowadays things have
been tightened up and from RFC 2822 the official format for In-Reply-To
is that it should only contain a Message-ID; a lot of mail software use
that for threading purposes (they also use References).  By default nmh
will generate that ... except that people that have old replcomps around
are still sending out the old format.

And that is me, too.

So, that was the long answer.  Short answer: Replace/append these lines
to your replcomps:

%{message-id}In-reply-to: %{message-id}\n%\
%{message-id}References: \
%{references}%(void{references})%(trim)%(putstr) %\
%(void{message-id})%(trim)%(putstr)\n%\

And if you really want a 'in-reply-to' like header, use this:

Comments: In-reply-to \
%{from}%(void{from})%?(void{apparently-from})%|%(void{sender})%\
%(trim)%(putstr)\n\
   message dated %(nodate{date})%{date}%|%(tws{date})%.

--Ken

And this worked perfectly.  Thank you very much, perceptive man. :)
You diagnosed the problem exactly.

Laura

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers