Re: [Nmh-workers] Announcing the second release candidate of nmh 1.7.1

Hi Andy, > first named test failure: replacement character in parameter value > FAIL: test/mhshow/test-charset Interesting. > Maybe the environment variable to not clean up corrupted the test > environment and I need some way to clean it up? I can rerun ``make > check'' multiple times

Re: [Nmh-workers] Announcing the second release candidate of nmh 1.7.1

Thus said Ken Hornstein on Mon, 22 Jan 2018 14:20:32 -0500: > This is a patch release for 1.7, and fixes some output problems with > the format engine, issues with rcvdist(1) passing switches to post(8), > and a number of problems discovered with the test suite. Speaking of the test suite, I

Re: [Nmh-workers] Announcing the second release candidate of nmh 1.7.1

Thus said Ken Hornstein on Mon, 22 Jan 2018 14:20:32 -0500: > If you encounter any problems or issues with this release candidate, > please don't hesitate to contact nmh-workers@nongnu.org. This may be a known issue (or not an issue at all): uip/post.c: In function 'putadr': uip/post.c:1239:

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

Thus said David Levine on Mon, 22 Jan 2018 20:43:50 -0500: > > The comment in mhfixmsg which I quoted at the beginning of > > this thread seems to be saying that sometimes message components > > described as text/* are really binary files, and that the > > 998-character

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

>Well, "binary" has a specific meaning in the MIME world. Specifically, >it refers to a MIME Content Transfer Encoding of binary, which has no >restrictions in terms of line length. So when that message says that >it can't decode it because the part would have to be binary, THAT is what >it is

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

Ken wrote: > >> That's a question for David, since mhfixmsg is his baby. I would suggest > >> that was probably an oversight and he might fix it at some point (and > >> by "fix it" I mean, "refuse to decode it", but that's up to him). > > > >I thought that mhfixmsg DID refuse to decode it: > > >

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

Steven wrote: > This suggests to me that removing the 998-character limit in mhfixmsg > (only, and nowhere else) is a reasonable thing to do. I think that -decodetext binary would be a better approach, but note that warning about producing non-compliant messages. But maybe none of this is

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

>The comment in mhfixmsg which I quoted at the beginning of this thread >seems to be saying that sometimes message components described as text/* >are really binary files, and that the 998-character limit is used in >mhfixmsg (only) as a heuristic to identify this situation. Well, "binary" has a

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

>> That's a question for David, since mhfixmsg is his baby. I would suggest >> that was probably an oversight and he might fix it at some point (and >> by "fix it" I mean, "refuse to decode it", but that's up to him). > >I thought that mhfixmsg DID refuse to decode it: > > mhfixmsg: /tmp/msg,

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

Ken wrote: > [Steven wrote:] > >This part is 670 lines before decoding, and exactly one line afterward. > >This arrived before I started using mhfixmsg, but given what I've just > >learned I'd certainly expect mhfixmsg to refuse to decode it. > > That's a question for David, since mhfixmsg is his

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

>Are you saying you received via SMTP a RFC5322 message where there >was 42027 characters between CR-LF pairs? I think I might have said that :-/, but whether I did or not you're right that it isn't what I meant. >That suggests to me that you in fact received a message that had lines no

Re: [Nmh-workers] Nmh-commits Digest, Vol 108, Issue 11

>As for C99, POSIX mandates it these days so it's time to upgrade from >pcc(1)! I don't think it was discussed publicly, but The Nmh Cabal(*) decided not too long ago to make C99 our baseline target in terms of language. Since that ratified 19 years ago, seems like it's about time. --Ken * -

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

>And I won't presume to suggest what nmh should do, but I will point out >that I recently received a message with a text/html part which was one >single line of 42027 characters. Let me ask you a more precise question. Are you saying you received via SMTP a RFC5322 message where there was 42027

Re: [Nmh-workers] Nmh-commits Digest, Vol 108, Issue 11

Hi Paul and Bakul, > > Paul wrote: > > > Ralph Corderoy (7): > > > fmttest.c: Avoid `++' with bools, silencing compiler warnings. > > > > i hate that perfectly reasonable, traditional idioms have to be > > avoided for this reason. > > No strong reason to use type bool in the first place. It

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

>To answer your larger question (on the subject line): > >- MH/nmh doesn't handle lines greater than 998 characters because such > messages are not valid according to RFC 5322, and mhfixmsg isn't going > to generate a message that nmh cannot handle. Whether or not nmh SHOULD > handle such

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

>So I guess what I'm asking is: I can easily modify my copy of nmh to raise >the 998-character limit, but it's not clear to me what I might break by >doing so. Would someone please explain what I'm missing here? To answer your larger question (on the subject line): - MH/nmh doesn't handle

[Nmh-workers] why does mhfixmsg dislike long text lines?

I'm in the middle of integrating mhfixmsg (1.7) into my proxmail setup, and just discovered this behaviour: # mhfixmsg -verbose -textcharset utf8 -fixcte -noreformat -fixboundary -file /tmp/msg -outfile /tmp/501.fm mhfixmsg: /tmp/msg, will not decode text/html; charset="UTF-8" because it

[Nmh-workers] Announcing the second release candidate of nmh 1.7.1

Greetings all, I am pleased to announce the availability of the second release candidate for nmh 1.7.1. You can download it here: https://download.savannah.nongnu.org/releases/nmh/nmh-1.7.1-RC2.tar.gz A GPG signature of this release is available here:

Re: [Nmh-workers] Nmh-commits Digest, Vol 108, Issue 11

Bakul Shah wrote: fmttest.c: Avoid `++' with bools, silencing compiler warnings. i hate that perfectly reasonable, traditional idioms have to be avoided for this reason. No strong reason to use type bool in the first place. It didn’t show up till c99. pointers aren't booleans.

Re: [Nmh-workers] Nmh-commits Digest, Vol 108, Issue 11

> On Jan 22, 2018, at 9:47 AM, Paul Fox wrote: > > nmh-commits-requ...@nongnu.org wrote: >> Ralph Corderoy (7): >> fmttest.c: Avoid `++' with bools, silencing compiler warnings. > > i hate that perfectly reasonable, traditional idioms have to be avoided > for

Re: [Nmh-workers] Nmh-commits Digest, Vol 108, Issue 11

nmh-commits-requ...@nongnu.org wrote: > Ralph Corderoy (7): > fmttest.c: Avoid `++' with bools, silencing compiler warnings. i hate that perfectly reasonable, traditional idioms have to be avoided for this reason. paul =-- paul fox, p...@foxharp.boston.ma.us