Re: Review code changes for handling huge lines?
Andy wrote:
> There was some interest but I believe it got lost in the nmh 1.7.1
> shuffle. After patching up my OS to the latest, I found that it was now
> running nmh 1.8, but was missing the code and so I tried applying that
> patch locally against my system and have been running it since then
> (January of this year 2024) without issues.
> Any interest in renewing a discussion about this?
I'd be interested in hearing from Ken and Ralph, at least, if they're
available.
Just to note that we would need a test suite addition that shows what the
change fixes. Also, there are these gcc warnings with these settings
(from build_nmh -d), based on what Fedora has used:
CFLAGS="-g -std=c99 -pedantic -Wformat -Werror=format-security
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -fasynchronous-unwind-tables -fno-omit-frame-pointer
-fstack-clash-protection -fcf-protection -O0"
../../uip/popsbr.c: In function ‘traverse’:
../../uip/popsbr.c:592:43: warning: pointer targets in passing argument 2 of
‘netsec_read’ differ in signedness [-Wpointer-sign]
592 | len = netsec_read(nsc, buffer + inoffset, unused, );
|~~~^~
| |
| char *
In file included from ../../uip/popsbr.c:14:
../../h/netsec.h:169:64: note: expected ‘unsigned char *’ but argument is of
type ‘char *’
169 | ssize_t netsec_read(netsec_context *ns_context, unsigned char *buffer,
| ~~~^~
../../uip/popsbr.c:593:21: warning: comparison of unsigned expression in ‘< 0’
is always false [-Wtype-limits]
593 | if (len < 0) {
| ^
David
Re: Symbolic link to mhmail
I wrote: > Thomas wrote: > > > For the reason given above I don't think this would solve it. I think > > these results might be even more explicit: > > > > $ echo $PATH > > /usr/bin/mh:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin > > $ cp /usr/bin/mh/mhmail ./test > > $ ./test > > ./test: 1: /home/thomas/mhparam: not found > > ./test: 95: exec: /home/thomas/inc: not found > > The root cause of the problem is that mhmail uses, in effect, `dirname $0` > to find the location of the nmh executables. > > Because /usr/bin/mh is on your PATH, it could instead use `mhparam bindir`. I just committed that fix to mhmail and sendfiles. Thank you, Thomas, for reporting this. Starting with the current HEAD, you can symlink mhmail. David
Re: Symbolic link to mhmail
Thomas wrote: > For the reason given above I don't think this would solve it. I think > these results might be even more explicit: > > $ echo $PATH > /usr/bin/mh:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin > $ cp /usr/bin/mh/mhmail ./test > $ ./test > ./test: 1: /home/thomas/mhparam: not found > ./test: 95: exec: /home/thomas/inc: not found The root cause of the problem is that mhmail uses, in effect, `dirname $0` to find the location of the nmh executables. Because /usr/bin/mh is on your PATH, it could instead use `mhparam bindir`. Or instead of trying to find the location at runtime, configure could be used to at build time to insert the path into the mhmail script. And the same could be done with etc/sendfiles. Thoughts? David
Re: Setting send(1)'s draftfolder breaks mhmail.
Ralph wrote: > Or perhaps use -nodraftfolder to cancel any profile setting when send is > being used and carry on as before. Though I don't know if > -nodraftfolder completely undoes a profile's -draftfolder. Good idea. And good call about not completely undoing -draftfolder. As explained in the commit message: commit 5718396d9c51c6e41d13c2548cd3ced591d3a028 Added -nodraftfolder to send(1) args when mhmail(1) is invoked with -profile. mhmail uses a tmp file. If the user has a -draftfolder switch in the send component of their profile, send interpreted the tmp filename as a message number. That caused send to fail. Fixed by squashing any send -draftfolder switches by appending the -nodraftfolder switch. The handling by send of "-draftfolder folder_name -nodraftfolder" is not the same as if that sequence of switches was not used. With it, the filename is processed by m_maildir(). Because mhmail provides an absolute path to send as the filename, m_maildir() returns the path unchanged. send therefore works properly with the absolute path argument from mhmail. Thanks to Ralph for reporting the bug and providing the fix. David
Re: Setting send(1)'s draftfolder breaks mhmail.
Andy wrote: > Thus said Ralph Corderoy on Thu, 18 Jan 2024 15:22:28 +: > > > The suggestion was to duplicate the setting by adding "send: > > -draftfolder drafts". I think this breaks mhmail(1). > > Except, according to the man page for mhmail: > > PROFILE COMPONENTS >mhmail does not consult the user's .mh_profile > > Perhaps it breaks send? The fault is with mhmail. When its -profile switch was added to use send instead of post, this interaction wasn't considered. mhmail currently uses a tmp file, always, for the draft. I think the fix should depend on if mhmail has been instructed to use send and send has a draftfolder switch in the profile. In that case it should create the draft as a new draft message in the draftfolder, instead of as a tmp file. David
Re: Strange problem replying to message
> Perhaps I am losing it but when I first looked at the header fields for the > message that > was giving me problems I could have sworn it said "Content-Transfer-Encoding: > Base64". > Now when I look at it instead of base64 it says 8bit. Am I confused or is > that what mhfixmsg did, > changed the message from base64 to 8bit? mhfixmsg changed the encoding of the message content. There are other ways to reply to base64-encoded messages. One is explained in the "Convert Interface" section of the mhbuild(1) man page. David
Re: Strange problem replying to message
Arthur wrote: > Yesterday everything worked. Today, trying to reply to a message I get: > > > In message > , > "B. William via Remind-fans" writes: > >SG1tbW0gdGhpcyBsaW5lIGRvZXMgVEhJUyBXRUVLLCArIDMgTU9SRSBXRUVLUyBhbmQgZ2l2ZXMg > >dGhlIGRhdGVzOgoKcmVtaW5kIC1zKzQgLXEgLXIgfi8ucmVtaW5kZXJzIHwgY3V0IC1jNi0xMCwx It looks like the text part of the message that you're replying to was not base64-decoded. You could verify that by viewing the message with "show -nocheckmime -showproc less". If the text part is still encoded, you could decode it in the message itself, or a copy, with mhfixmsg(1). I don't know why it would have worked yesterday but not today. David
Re: Macintosh for nmh?
George wrote: > Orbiting back, It looks to have only been deployed in anger with Google POP. > And, in NEWS and the code it's marked as deprecated/unsupported for various > reasons. But I would imagine it still works fine on the SMTP side. Nmh's XOAUTH2 support was implemented generically to support both SMTP and POP. It was instantiated for both to work with Google. However, Google changed things such that neither will work with it now. I expect that it wouldn't take much effort to get them to work with O365, but I haven't tried. David
Re: mysterious c0 80
Michael wrote: > David Levine wrote: > > > I'm thinking of removing the support in post(8) for sending > > NULs. Any disagreement? It's not a lot of code so could be > > easily restored in the future if conditions change. > > Does that mean an error, or does that mean just skipping it? The old code relied on fprintf(3) and fputs(3), so it truncated at the first NUL. > I'm fine with skipping the NUL, but I'll live with the error; I'll > just have to fix my end :-) As Ken noted, it would be nice to understand the root cause. Ken wrote: + It is not clear to me that any of the OTHER nmh programs could + actually even receive a message with NUL in it, and plenty of other + programs fail if a message contains a NUL. Here's some messages + when I brought this up last year: In one of those messages, I noted that m_getfld and the MIME parser do handle NULs. I haven't tried inc(1). Ralph wrote: # But doesn't dist → send → post so if you remove post's support for # sending NULs then dist won't be able to send the old email verbatim. Yes, but isn't that required by RFC 5322? I don't object to violating it in this case, so I'm fine with whatever we can agree on. David
Re: mysterious c0 80
Ralph wrote: > nmh shouldn't comp(1) a new email today with a NUL in the body, but it > should be able to read and show(1) one. I'm thinking of removing the support in post(8) for sending NULs. Any disagreement? It's not a lot of code so could be easily restored in the future if conditions change. > Now, how about dist(1) of that old email? I'd have thought it should > send the old email verbatim, NUL and all. If that causes a bounce > then the sender can MIME-forward instead with a single message/rfc822 > part. Agreed. David
Re: mysterious c0 80
Michael wrote: > === > All 101 tests passed > (19 tests were not run) > === That's good. Though I'm surprised that 19 tests weren't run. That happens when nmh isn't configured with some options. 19 seems high to me. > I tried running "test/post/test-post-basic" manually, and it seemed to just > install stuff to test/testdir/inst, but I couldn't tell if it actually ran a > test. Do I need some arguments to the test? No, the tests don't take arguments. Some require helper programs. To make sure those are built, it's best to run a single test this way: make check TESTS=test/post/test-post-basic If the test succeeds, it exits with 0 status. And that test shouldn't produce any output if it succeeds. David
Re: mysterious c0 80
Ken wrote: > >> What version of nmh are you using? There was a recent bug reported > >> by Cy Schubert that may be the cause of this: > >> > >>http://savannah.nongnu.org/bugs/?65002 > > > >Interesting. Can anyone replicate this bug? Michael, are you running > >on FreeBSD or something else? > > I haven't tried yet; it was on my list to look at. test/post/test-post-basic should catch it. David
Re: mysterious c0 80
Ken wrote: > What version of nmh are you using? There was a recent bug reported > by Cy Schubert that may be the cause of this: > > http://savannah.nongnu.org/bugs/?65002 Interesting. Can anyone replicate this bug? Michael, are you running on FreeBSD or something else? David
Re: message-Id has localhost
On Sat, Dec 30, 2023, 10:50 Michael Richardson wrote: Maybe strcmp(hostname,"localhost") should cause that value to be > ignored, and if necessary, resort to random messageid. Or maybe that > should > just be the default in some way. > I don't think that's a good idea. If the user always wants a random messageid, they can add the switch to their profile. David >
Re: Testing the welcome message (was: nmh is vital to me)
Ken wrote: > [Ibsen:] > >Indeed that is what is happening. It seems like you prefer it work > >this way rather than showing the welcome message just once; in that > >case, there is nothing to do on the situation I present. > > I think you misunderstand me; I'm not saying I PREFER it work that way, > I just am explaining why it DOES work that way. It probably should be > fixed to behave better, but since right now I lack the time to do it > myself I don't make a big deal over it. That was fixed post-1.8, in commit 82b04d3149. Also, I just added this to the welcome message: This message will not be repeated until nmh is next updated. To permanently suppress this message, add "Welcome: disable" to your profile (/home/levine/.mh_profile). The actual absolute value of the profile will be shown. David
Re: nmh is vital to me
Alexander wrote: > On Fri, 01 Dec 2023 06:39:48 +, Ralph Corderoy writes: > >Though something must be going wrong for it to be shown more than once. > > the current debian 'stable' release that dan is using did end up with > nmh version 1.8-RC2, what with the various code freeze periods etc. > > with that version the welcome does indeed not go away and and becomes > quite unwelcome...and i didn't catch that before uploading the debian > version (because i'm mostly using exmh in front of nmh). I think that there are two possiblities here. First is that the command fails so the context doesn't get updated. That was fixed post-1.8, in commit 82b04d3149. The other possibility is the context file is not being saved. I tried replicating it on HEAD and could not. David
Re: mhbuild and long header fields
Andy wrote: > Minor correction; replace "then" with "than". > > Also, RFC 5322 2.1.1 does not "require" that the lines be no more than > 78 bytes, only that it's highly recommended that they not exceed that. > The actual line limit is 998 bytes. Good catches, thank you! And thank you, Phillipp. This bug fix/enhancement is well worth your efforts. commit 542cb12b6d0646b711772ee97c1e2aacf2bada86 Author: Philipp Date: Mon Sep 18 12:50:22 2023 +0200 mhbuild now folds header field bodies to avoid lines with more than 78 bytes. This is recommended by RFC 5322 2.1.1. Line Length Limits. Signed-off-by: David Levine David
Re: mhbuild and long header fields
Philipp wrote: > A format-patch is attached. Thanks. I think that the commit message should note that only header field bodies are folded. And because folding can only occur at whitespace, it is possible to end up with more than 78 bytes in a line. How about this? mhbuild now folds header field bodies to avoid lines with more then 78 bytes. This is required by RFC 5322 2.1.1. Line Length Limits. I'll add the first line of the commit message to docs/pending-release-notes. And add the year to the copyright notice in fold.[hc]. David
Re: mhbuild and long header fields
Philipp wrote: > Good to hear. Do you want a format-patch of the final version? Sure, that would be great. Or, all I need is the commit message. I just verified that I'm using your last code submission with no changes. > > One issue to resolve first: the References header field at the end of this > > message ends with: > > <16f13de3df80f62de768420a3cc3a2fe.phil...@bureaucracy.de> > > <14298-1693614066.188834@mIBq.BRD6.6M0V> > > > > There's always an extra space in front of the Message-ID that was appended > > last. Is that a relic of repl? > > That's strange and I can't reproduce this. Also I can't find code which > would explain this in repl and the default configuration. It took me a while to find it: References is updated by replcomps. For unknown reasons, mine had an extra space. I fixed it so all is good now. > No, fold() should not change the body of the field. Depending on the > context multible white space characters might have a meaning or are used > to increase readability without a MUA. Agreed. Thanks! David
Re: mhbuild and long header fields
Phillipp, I've been using your header field folding for a few weeks and I really like it. I think that it should be committed, it's big step forward. One issue to resolve first: the References header field at the end of this message ends with: <16f13de3df80f62de768420a3cc3a2fe.phil...@bureaucracy.de> <14298-1693614066.188834@mIBq.BRD6.6M0V> There's always an extra space in front of the Message-ID that was appended last. Is that a relic of repl? Or, should the folding code collapse multiple white space characters at the beginning of a line? David
Re: some thought on m_getfld
Philipp wrote: > [2023-09-02 14:41] Ken Hornstein > > > > I think you are thinking at the wrong scale. The problem with m_getfld() > > is not the interface, it is that it should not exist at all. > > Actually not quite, I think step by step. First get a good function > parsing the fields. Then look how this function can be used to parse the > complete header. With a scanner/parser approach, I don't think it's necessary to consider those separately. I agree with Ken: > > So this suggests to me that really in most cases the whole header should > > just be read and then you get some accessor functions to get out the > > headers you care about. The nmh code for interfacing with GMail APIs (on the gmailapis branch) does that. It's in Python and needs some optimizing, but at least it's brief and corresponds to the RFCs. David
Re: mhbuild and long header fields
Philipp wrote: > This was to vague asked by me. I was woundering about the API. Should > fold construct a string of the complete field or only the body. I think the wwy you have it currently implemented is fine: only the body but it accounts for the length of the name. David
Re: mhbuild and long header fields
Philipp wrote: > I have a version with charstring_t attached. I'm unsure if it's better > to only fold the body or include the field name. The version attached > only fold the body. RFC 5322 §2.2.3 only mentions folding the body. And field names can't have whitespace. So I think that only a body can be folded. I'll exercise your patch for the next week or so. Unfortunately, I'll be off line during much of that time so might not respond quickly. Thank you for doing this. As the References field in this message shows, it's badly needed. David
Re: mhbuild and long header fields
Philipp wrote: > One question about charstring_t: Why does charstring_push_back_chars() > not use memcpy? It has the side effect of advancing cur: s->cur++. David
Re: mhbuild and long header fields
Philipp wrote: > Ah, I forgott the early continue. The attached version sould work. It does. I'm sending this message using it. David
Re: mhbuild and long header fields
Philipp wrote: > [2023-08-27 09:29] David Levine > > > > My only comment on the code itself is that I prefer functions that > > just do one thing. So I would implement a fold function that just > > modifies a string, and leave the fprintf/fwrite to output_headers(). > > I have thought about this, but this would require fold() to allocate memory. > Because the plan was to use fold() in output_headers() I though this could > be avoided. I don't think that allocating memory is a drawback. > As far as I see output_message_fp() is currently only used by mhfixmsg > and mhbuild. For mhfixmsg I though it would be ok to also fold the field. Good point. Yes, mhfixmsg should fold also. > For the blank lines you mentioned: Can you test the attached version of > my patch. If this don't fix your problem, can you provide a sample mail? The patch didn't fix it. The attached sample shows the added line when run through mhfixmsg: $ uip/mhfixmsg -file fold_adds_blank_line.txt -out - From: sen...@example.com DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=example.com; b=0123456789012345678901234567890123456789012345678901234567890123456789012345 To: recipi...@example.com Date: Sun, 27 Aug 2023 23:00:00 + test If the length of that long line is reduced by 1, the blank line is not created. David --- Begin Message --- test --- End Message ---
Re: mhbuild and long header fields
I wrote: > There is a bigger issue, however. output_headers() gets called by > other code, such as mhfixmsg via output_message_fp(). So the change > as-is interferes badly with it. I haven't looked for a better place > to fold the header fiels, but we'll have to find one. Alternatively, maybe the behavior of fold() could be changed. The bad behavior is caused by occasional insertion of a blank line. David
Re: test-mhfixmsg and test-binary fails on debian stable
Philipp wrote: > [2023-08-26 17:39] David Levine > > Philipp wrote: > > > > > [2023-08-26 15:28] David Levine > > > > > > > > The NUL byte is output as \x00: > > > > > > I found the problem: The build in printf of dash don't write a NUL. > > > Using printf from path to generate the test and expected file works as > > > expected. > > > > Thank you! I'll update the test. > > An other hint for this test. Posix printf specifies an octal escape > sequences[0]. Replacing the '\x00' with '\000' fixes the test. Yes, much better. I'll fix that test and test/post/test-post-basic. Thank you! David > [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
Re: mhbuild and long header fields
Philipp wrote: > Do you only test the patch or have you looked at the code? It would > be nice to get some feedback on the implementation. My only comment on the code itself is that I prefer functions that just do one thing. So I would implement a fold function that just modifies a string, and leave the fprintf/fwrite to output_headers(). And a very minor change would be to add the year to the copyright notice. There is a bigger issue, however. output_headers() gets called by other code, such as mhfixmsg via output_message_fp(). So the change as-is interferes badly with it. I haven't looked for a better place to fold the header fiels, but we'll have to find one. David
Re: mhbuild and long header fields
Philipp wrote: > That said, my code detects lines without WSP (and are longer then 78 > bytes). Some rfc 2047 encoding could be added there. But first the > folding should be implemented. I agree. I'm sending this message using your patch. I'd like to exercise it for a few days before committing. Thank you for your patch! David
Re: test-mhfixmsg and test-binary fails on debian stable
Philipp wrote: > [2023-08-26 15:28] David Levine > > > > The NUL byte is output as \x00: > > I found the problem: The build in printf of dash don't write a NUL. > Using printf from path to generate the test and expected file works as > expected. Thank you! I'll update the test. David
Re: test-mhfixmsg and test-binary fails on debian stable
Philipp wrote: > This test now passes. Thank you for reporting the test failure and for confirming the fix. > Here you go: > $ od -ax /tmp/nmh/test/testdir/test-binary302898.actua Thanks. The NUL byte is output as \x00: > 260 y t e : sp \ x 0 0 . nl >74793a655c2030782e30000a The content in the message is identified as binary so I'm not sure why. For me, it is output as NUL: 260 y t e : sp nul . nl 74793a6500200a2e David
Re: test-mhfixmsg and test-binary fails on debian stable
Philipp wrote: > LANG=en_US.UTF-8 > LC_ALL= > I have "#define HAVE_ICONV 1" in config.h. I just run autogen.sh and > configure without any arguments. Thanks, those match what I use. I just committed a fix to test-mhfixmsg. Different html renderers produced different output. I replace a non-breakable space with a space so the output is now the same from w3m, lynx, and elinks. I don't know why your test_binary would count 26 bytes instead of 23. Can you post or send me your /tmp/nmh/test/testdir/test-binary.actual file? Or better, run od -ax on it and post that? David
Re: test-mhfixmsg and test-binary fails on debian stable
Philipp wrote: > I have noticed that two tests (test-mhfixmsg and test-binary) fail > on my computer. I use debian stable and configure outputs folloing: What is your locale? Do your nmh build use iconv? David
Re: mhbuild and long header fields
Philipp wrote: > I have had a quick look at fold() and just calling fold() would produce > incorrect results. fold() just insert '\n ' after 76 characters[0]. But > to correct fold a field you must insert a '\n' befor a whitespace. > > I'll try to implement a corrent fold funktion on the weekend. > > Philipp > > [0] I don't know if this is an issue in the context of ical Good catch! Yes, RFC 5322 folding for messages and RFC 5545 folding for ical are different. Thank you. This has bothered me for a long time. David
Re: mhbuild and long header fields
Ken Hornstein wrote: > [Phillip wrote:] > >Or in output_headers(). I'm not sure if there an extra options would be > >required. > > That is one option. Another is that repl(1) could do a better job; I > suppose that is the fault of mhl. mhl is used for display. And a user can substitute their own filter for it. We need to fold header fields when producing a message. I think that output_headers() is the right place. It's the only place where header fields are output. There is a fold() function in sbr/mhical.c, maybe it could be moved to sbr and called from output_headers() for message and content part headers. Those shouldn't need multibyte character support, though that wouldn't hurt. David
Re: mhbuild and long header fields
Philipp wrote: > Thanks for pointing this out, but now I'm more confused. Whats the point > of LENERR (in contrast to FMTERR)? But this is a diffrent discussion. There isn't much point to differentiaing LENERR from FMTERR. The error messages are different when they're set, which might help the user identify the problem. After that, they are handled identically. David
Re: mhbuild and long header fields
Philipp wrote:
> I have noticed that mhbuild don't implement header field folding.
> Specialy for the References field this might cause problems, when you
> use it to feed a mail build by mhbuild to a tool which checks the
> line length.
Thank you for pointing that out. Header field folding does need to
be properly implemented. It would be a great contribution if someone
has the bandwidth.
> Also I don't get the code. In uip/mhbuildsbr.c:359 a LENERR is handled
> with die(), but I can't create a testcase for this.
A draft with a header field name exceeding 997 bytes in length should
trigger LENERR. The only code that sets a LENERR is in m_getfld().
So the draft would trigger is in any nmh command that reads a message
header, such as scan(1):
$ (printf '%.sX' {1..997}; printf ': too-long\n') | scan -file -
scan: field name
"X:"
exceeds 997 bytes
??Format error (message -1) in component 1
1 08/18/23*
David
Re: graphical mail reader for one-off use
Ken wrote: > I think a BIG problem with this is that doesn't get you the "complete" > message. The main issue here is embedded images with Content-ID URLs; Yeah. I view showing them separately as a feature but maybe I shouldn't. David
Re: graphical mail reader for one-off use
Paul wrote: > david wrote: > > Paul wrote: > > > > > My working bash snippet (trimmed to remove some extraneous local > oddities). > > > > Just curious: does mhshow(1) do want you want, assuming you don't > > use it to read all of your messages? > > I'm not sure of the context of your question. I apologize, I should have provided that. When I read your original message, my first thought was "what's missing from nmh so Paul can view a message with a modern graphical reader?" To answer my own question, mhshow can be customized to use the user's preferred mail reader. Ken mentioned w3m with display_link_number. I use firefox, I find that its performance on a modern machine with an SSD drive is adequate. mhshow can be coaxed to use some of your thunderbird wrapper script with a profile entry such as: mhshow-show-text/html: cp $(mhpath cur) /tmp/$(whoami)-message.eml && thunderbird -file /tmp/$(whoami)-message.eml Of course, all user preference. David
Re: graphical mail reader for one-off use
Paul wrote: > My working bash snippet (trimmed to remove some extraneous local oddities). Just curious: does mhshow(1) do want you want, assuming you don't use it to read all of your messages? David
Re: mhl nocomponent
Ken wrote: > I am thinking maybe we should change the nmh default mhl files as well > to recognize current reality +1 to removing "extras:nocomponent". David
Re: mhl nocomponent
Jon wrote: > Things are way more verbose in the current release in that all sorts > of headers clog up my display. There's this, but that should just add a few headers: commit 5579e0dd84f9dcb67c989a191538346ee7ab63e2 Author: David Levine Date: Sun Jul 14 09:29:21 2019 -0400 show and mhl now decode more addresses in header fields. Added decoding of To:, Cc:, Resent-To:, Resent-Cc:, and Resent-From: addresses to mhl.format and mhl.headers. Thanks to Conrad Hughes for suggesting it for the first two components and to Ralph for suggesting it for the Resent- components. > The extras:nocomponent only seems to cut down on a few components. extras adds components, it doesn't cut them now. Try removing it? Or, I wonder if you're now using the default mhl.headers, which has had extras:nocomponent for decades. David
Re: (Not-so) hypothetical question: What to do about NULs?
I wrote: > Ken wrote: > > In terms of the networking code, > > it looks like the right thing will happen when sending a NUL via > > SMTP, > > Almost, but not quite. I posted a possible fix but I'm still refining > it. Fix to post(8) committed: commit 8f897f65fecbc668db777e2f4fabb23a08edf11b Author: David Levine Date: Sun Mar 12 10:28:39 2023 -0400 Enhanced post(8) to handle NULs in message body. :100644 100644 6436734c 30b887af M test/fakesmtp.c :100755 100755 39915e71 fb2b167b M test/post/test-post-basic :100644 100644 820ed05b bf35b8a4 M uip/post.c David
Re: nmh 1.8 -- repeated Welcome message unless there is a context change
Ken wrote: > unfortunately (we probably should do better at making sure the context > is updated when we display the welcome message). Done, added context_save() immediately after each context_replace() that updates the Version identifier. context_save() can safely be called multiple times, and it only rewrites the disk file if needed. commit 82b04d3149939661608b1ea8764d873c005f9956 Author: David Levine Date: Sat Mar 11 10:03:02 2023 -0500 Save context immediately after adding or updating its nmh Version. To prevent repeating the nmh welcome message if a command fails. Thanks to Mark Bergman for reporting that with inc(1). :100644 100644 d6319939 91e582f4 M docs/pending-release-notes :100644 100644 6b400f2f 69eb879b M sbr/utils.c :100755 100755 07188e9e aca8890c M test/install-mh/test-version-check David
Re: flist -- "Killed" -- oom (*not* 1.8 related)
Ken wrote: > This does suggest to me we should probably change the internal API > so sparse message ranges are handled better; Yes, that would be a nice enhancement. In the meantime, an occasional folder(1) -pack might solve the problem manually. David
Re: (Not-so) hypothetical question: What to do about NULs?
Ken wrote:
> [David:]
> >I have received email with C-T-E set to binary. While I don't think it
> >was needed, I haven't checked closely.
>
> Facinating! I am curious: who/what sent this to you! Do you remember
> the MIME type?
The C-T-E: binary is in the message header. The are two alternative
content parts, text/html and text/plain. Both are encoded Q-P. So
the C-T-E: binary is gratuitous. (And mhfixmsg converts it to 8-bit.)
msg part type/subtype size description
0 multipart/alternative 26K
boundary="--=_1648114734-702538-12126"
charset="UTF-8"
1 text/html 16K
disposition "inline"
2 text/plain9823
disposition "inline"
The sender, freecycle.org, uses that C-T-E: binary often. Maybe every
time.
> Well, I'm not SURE that's necessarily true. As you point out, that's
> only true for the bodies of message fields. And I see a lot of things
> in the code that assume the body of a message field is a valid C string,
> e.g (mhparse.c):
>
> /* if necessary, get rest of field */
> while (state == FLDPLUS) {
> bufsz = sizeof buf;
> state = m_getfld2(, name, buf, );
> vp = add (buf, vp); /* add to previous value */
> }
That's in FLDPLUS, still in the header.
> In terms of the networking code,
> it looks like the right thing will happen when sending a NUL via
> SMTP,
Almost, but not quite. I posted a possible fix but I'm still refining
it.
> It seems for message bodies we're
> in reasonable shape (unless you are RETRIEVING a message via POP), but
> if a NUL appears in the header somewhere all bets are off.
Yeah. I'd be OK with replacing NULs with some legal
character(s). I'm not sure that just squashing them is a good
idea. I don't have a concrete example, but wonder if it could be
abused, say in a really messy URL.
David
Re: (Not-so) hypothetical question: What to do about NULs?
David Malone wrote:
> I wonder if it would be better to use fwrite instead of write, to
> avoid mixing stdio and Posix-style output? (It would also avoid an
> unbuffered write of 1 byte.)
Good point. How about the attached?
David
diff --git a/uip/post.c b/uip/post.c
index 820ed05b..a58e19a1 100644
--- a/uip/post.c
+++ b/uip/post.c
@@ -660 +660,3 @@ main (int argc, char **argv)
- case BODY:
+ case BODY: {
+ size_t n;
+
@@ -664 +666,9 @@ main (int argc, char **argv)
- fprintf (out, "\n%s", buf);
+ if (fwrite ("\n", 1, 1, out) != 1) {
+ adios ("write of newline between header and body", "failed");
+ }
+ /* Don't emit trailing NUL to avoid interfering with SMTP
+ conversation. */
+ n = bufsz >= 1 && buf[bufsz-1] == '\0' ? bufsz - 1 : bufsz;
+ if (fwrite (buf, 1, n, out) != n) {
+ adios ("write of body", "failed");
+ }
@@ -668 +678,3 @@ main (int argc, char **argv)
- fputs (buf, out);
+ if (fwrite (buf, 1, bufsz, out) != (size_t) bufsz) {
+ adios ("continued write of body", "failed");
+ }
@@ -670,0 +683 @@ main (int argc, char **argv)
+ }
Re: (Not-so) hypothetical question: What to do about NULs?
I wrote: > This might not be much of a lift. m_getfld might handle NULs in bodies, > and the MIME parser comes close to handling them as well. m_getfld and the MIME parser do handle NULs. post(8) doesn't. I'd like to commit the attached patch. It uses write(2) instead of fprintf(3) and fputs(3). All tests pass with it. Any objection? While SMTP servers still might not be able to handle NULs, I don't think that nmh should block them. > mhshow has a test-binary that says that it reads a null byte, but it's > just a space. That was incorrect. printf(1) wrote out the NUL. I'll add a comment to the test to make that clearer. David diff --git a/uip/post.c b/uip/post.c index 820ed05b..010bcf1e 100644 --- a/uip/post.c +++ b/uip/post.c @@ -340 +340 @@ main (int argc, char **argv) -int state, compnum, dashstuff = 0, swnum; +int state, compnum, dashstuff = 0, swnum, out_fd; @@ -632 +632 @@ main (int argc, char **argv) - char *cp = m_mktemp2(NULL, invo_name, NULL, ); + char *cp = m_mktemp2(NULL, invo_name, _fd, ); @@ -664 +664,5 @@ main (int argc, char **argv) - fprintf (out, "\n%s", buf); + write (out_fd, "\n", 1); + /* Don't emit trailing NUL to avoid interfering with SMTP + conversation. */ + write (out_fd, buf, + bufsz >= 1 && buf[bufsz-1] == '\0' ? bufsz-1 : bufsz); @@ -668 +672 @@ main (int argc, char **argv) - fputs (buf, out); + write (out_fd, buf, bufsz); @@ -1240,0 +1245 @@ finish_headers (FILE *out) +fflush (out);
Re: (Not-so) hypothetical question: What to do about NULs?
Ken wrote: > But RFC 2045 says in §6.2: > >Thus there are no >circumstances in which the "binary" Content-Transfer-Encoding is >actually valid in Internet mail. > Also, I am not aware of "binary" being used as a C-T-E at all. I have received email with C-T-E set to binary. While I don't think it was needed, I haven't checked closely. > - Completely handle embedded NULs properly. This is arguably the most > correct option but would involve a lot of code changes. This might not be much of a lift. m_getfld might handle NULs in bodies, and the MIME parser comes close to handling them as well. mhshow has a test-binary that says that it reads a null byte, but it's just a space. That should be fixed, but I think that might reveal (minor?) deficiencies elsewhere. David
nmh 1.8 is now available!
Greetings all, I am pleased to announce that after nearly five years we are finally releasing nmh 1.8. The source code release is now available and can be downloaded from: http://download-mirror.savannah.gnu.org/releases/nmh/nmh-1.8.tar.gz There is an accompanying .sig file for GPG verification. MIME external-body pointers to the above files are included in this message. This release includes a large number of enhancements and bug fixes. The NEWS file included in the distribution contains greater details, but the highlights are: - Support for Content-MD5 header fields, MIME content cache functionality, and the message/partial MIME type have been removed. - Gmail OAuth2/XOAUTH support for desktop applications has been effectively dropped, so nmh no longer supports it. nmh support for Gmail API access is experimental, please post to nmh-workers@nongnu.org if you'd like to help with test and development. - repl(1) -convertargs now allows editing of the composition draft between translation and any encoding of text content. Because encoding can wrap long lines, the use of a paragraph formatter has been removed from mhn.defaults. This release is dedicated to Norman Z. Shapiro, co-designer of the MH Message Handling System. MH is the predecessor of nmh. Norm was an active supporter of nmh development until he passed away in October of 2021. We are most grateful to Norm for his stewardship of MH and nmh. https://en.wikipedia.org/wiki/Norman_Shapiro Thanks to all of the contributors for their hard work and to everyone who tried out the release candidates and gave feedback; it is very much appreciated. As always, please report feedback to nmh-workers@nongnu.org David Levine on behalf of the nmh development team Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: nmh 1.8-RC3?
Simon wrote: > I did some really basic testing (scan, show, repl) on NetBSD x86 > as well as a "make check" and got: > > == > All 112 tests passed > (7 tests were not run) > == Thank you! It really helps to have the NetBSD coverage. David
Re: nmh 1.8-RC3?
I wrote: > Has anyone tried 1.8-RC3 on a BSD platform? If good, any objection to > releasing 1.8 soon? Unless there's an objection or discovery of a problem, I'd like to release 1.8 this weekend. David > https://download.savannah.nongnu.org/releases/nmh/nmh-1.8-RC3.tar.gz
Re: Multiple IMAP accounts with nmh and getmail?
hariskar wrote: > I am a new (non developer) nmh user. Welcome to nmh! > I have configured nmh with getmail for one IMAP account, but can I configure > it for more accounts? > Getmail supports multiple accounts. Yes, you can put settings for different accounts in separate getmail rc files. Then use the getmail -r option to select the rc file(s) that you want to use. You can invoke getmail with multiple -r options. When I used getmail, I used to use it with procmail(1). The nmh mhfixmsg(1) man page has a section, Integration with procmail, with an example of how to filter messages through mhfixmsg before storing them in an nmh folder. David
nmh 1.8-RC3?
Has anyone tried 1.8-RC3 on a BSD platform? If good, any objection to releasing 1.8 soon? It looks good on Red Hat and Debian Linux, MacOS, Solaris 11, and Cygwin. https://download.savannah.nongnu.org/releases/nmh/nmh-1.8-RC3.tar.gz Thanks! David
Re: nmh-1.8-RC2 issues
I wrote: > DaveF wrote: > > > Is this a deliberate decision or a regression? If it is a deliberate > > decision > > it should probably be documented in the NEWS and/or Changelog. I added am explanation for the removal of the par/fmt from mhn.defaults to NEWS. Thank you for pointing this out! David
Re: nmh-1.8-RC2 issues
DaveF wrote: > I have built RC2 on my Gentoo Linux system. It mostly works. The tests all > pass. Thanks! > However. I have noticed that in 1.7.1 etc/mhn.defaults.sh searches for > external programs par and fmt and iconv. If it finds them it outputs > entries for, eg. mhbuild-convert-text: > which use said programs in the pipeline. > > In 1.8-RC2 the programs are searched for and shell variables textfmt and > charsetconv are assigned assigned accordingly, but the shell variables are > not used so the programs are not used in the processing pipelines. There is some unused code in there. (I don't think charsetconv has ever been used.) The helper applications have evolved over time. The use of par/fmt in the mhbuild-convert-text directives turned out to not be necessary. The resulting mhn.defaults from 1.7.1 and 1.8 RC2 should be similar otherwise. > Is this a deliberate decision or a regression? If it is a deliberate decision > it should probably be documented in the NEWS and/or Changelog. The ChangeLog does capture these changes, though maybe not explicitly. I don't think the raw changes are significant enough to be called out in NEWS. > Also, while rummaging about I noted that nmh-1.8-RC2/SPECS/nmh.cygport > contains > VERSION=1.7 > RELEASE=2 > > Don't know if it is relevant, but it seems anomalous. Yeah, that's an example. I don't know if cygport supports shell expansion, if it does it could be changed to resemble nmh.spec. I'll try to look at some point. David
The third release candidate of nmh 1.8 is now available!
The third nmh 1.8 release candidate is now available. It treats a set but empty (null) HOME variable the same way as if it was unset. You can download it here: http://download-mirror.savannah.gnu.org/releases/nmh/nmh-1.8-RC3.tar.gz There is an accompanying .sig file for GPG verification. To simply download, build, and test: wget http://download-mirror.savannah.gnu.org/releases/nmh/nmh-1.8-RC2.tar.gz && tar xzf nmh-1.8-RC2.tar.gz && cd nmh-1.8-RC2 && ./configure && make check If you encounter any problems or issues with this release candidate, please don't hesitate to contact us at nmh-workers@nongnu.org. David Levine on behalf of the nmh development team Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: nmh 1.8RC2, xlbiff, and $HOME
Ralph wrote: > Your principles soon went out the window. Oh no, they're all still there. One of them just got moved to the front. David
Re: nmh 1.8RC2, xlbiff, and $HOME
az wrote: > minor data point: after following the discussion here, i've decided > that for now _the debian packages_ of nmh should not distinguish > between unset $HOME and set-but-empty $HOME, and that either should cause a > fallback to getpw*. Then I think that we should do the same in 1.8 for all platforms. Thoughts on applying that patch (plus a test and documentation update) to create a 1.8RC3 this weekend? David
Re: nmh 1.8RC2, xlbiff, and $HOME
I wrote: > What case am I missing? I get it: the non-null, empty HOME. Anyways, I'd like to keep the 1.7 behavior for 1.8 and change it after. Can we agree to that? David
Re: nmh 1.8RC2, xlbiff, and $HOME
Ralph wrote:
> Hi David,
>
> > And my feeling at this point is to put out an RC3 with the 1.7
> > behavior for $HOME.
>
> Which, to be clear, is not the behaviour Ken and kre want. :-)
I was thinking that just removing the if (!*var) statement from your
code, leaving:
char *var = getenv("HOME");
if (var) {
mypath = mh_xstrdup(var);
return;
}
errno = 0;
struct passwd *pw = getpwuid(getuid());
if (!pw) {
if (errno)
adios("", "getpwuid() failed"); /* "" prints errno! */
die("password entry not found");
}
if (!*pw->pw_dir)
die("password entry has empty home directory");
mypath = mh_xstrdup(pw->pw_dir);
is the same as the 1.7 code (ignoring the string copies):
if ((mypath = getenv("HOME")) == NULL) {
if ((pw = getpwuid(getuid())) == NULL || *pw->pw_dir == '\0')
adios(NULL, "cannot determine your home directory");
else
mypath = pw->pw_dir;
}
What case am I missing?
David
Re: nmh 1.8RC2, xlbiff, and $HOME
Ralph wrote: > The behaviour cannot solidify further. :-) It's clear, determinate, > predictable, and simple to document. Those qualities can be true for the 1.7 behaviour. > I thought RCn+1 was meant to be minimal differences from RCn? If there's an RC3, the only code difference would be for this issue. > That's why Andy Bradford's POP3 patch is post 1.8. There's a key difference between the $HOME change and Andy's POP3 patch: the behaviour has already, prior to 1.8 final release, changed from 1.7 for the former but not the latter. > Switching the behaviour of > a set-but-empty HOME now seems significant given some value for HOME > must be chosen. 1.8 hasn't been released yet. I think that we owe users consistent behaviour from 1.7 to 1.8 unless clearly documented. > And will mean another round of testing by others on top of your time. I appreciate your consideration of that but I think that we need to resolve the consistency issue. In any case, a new test and man page update are called for. And my feeling at this point is to put out an RC3 with the 1.7 behavior for $HOME. David
Re: nmh 1.8RC2, xlbiff, and $HOME
Ralph wrote: > This close to a release, I think we should stick with requiring HOME to > be non-empty if it's set as otherwise there's too many paths to consider > which the test harness probably doesn't exercise. I'd rather crank out an RC3 than pass up the opportunity to solidify the behaviour here. Ken's point that different treatmet of unset vs empty HOME is a mistake is fairly compelling for me. David
Re: nmh 1.8RC2, xlbiff, and $HOME
Stephen wrote: > My analysis: > > This is a regression. HOME is used only to set the default profile > file to "$HOME/.mh_profile". But nmh doesn't need HOME if MH is set. Thanks for your analysis. I'd like to get Ralph's take on what we should do. > A further documentation issue: mh-profile(5) does not specify the > treatment of a relative Path. I expected it to be relative to the > directory of the profile file, but it seems to actually be relative to > HOME. Right, it's relative to HOME. I'll add this clarification to the man page: A relative Path is relative to the user's $HOME directory. unless there's another suggestion. David
Re: 1.8RC2?
Jerry wrote: > Success on Mageia Linux 8. Working as promised, using live for email > as I type. Thanks, Jerry. David
Re: 1.8RC2?
Ken wrote: > >> But ... did we ever get a resolution on the long lines POP patch? > > > >No. How about we defer to post-1.8? > > Can we tenatively say that it's targeted for 1.8.1? Sure, that sounds great. And it would be great to have shorter release cycles for 1.8.1 (and beyond), but I know that life gets in the way. David
Re: 1.8RC2?
Bakul wrote: > On Jan 28, 2023, at 6:17 AM, David Levine wrote: > > > > How does 1.8RC2 look? BSD users, have any of you tried it? > > Works on FreeBSD 13. make check succeeds + random commands > I tried worked fine. Thank you, Bakul. David
Re: 1.8RC2?
Ken wrote: > I wanted to test it on MacOS X. I did. Success both with debug and non-debug builds. > But ... did we ever get a resolution on the long lines POP patch? No. How about we defer to post-1.8? David
Re: 1.8RC2?
Including Stephen Gildea, the Debian maintainer of xlbiff. Ralph wrote: > Finding a Debian system, I think it's more that package xlbiff depends > on nmh. So it does, thanks. I hope the issue can be resolved. David
Re: 1.8RC2?
Alexander wrote: > debian: works well. however, 1.8 might not make it into the upcoming > release (upload freeze is just weeks away and one nmh-dependent package > has a test suite bug that blocks nmh from going in... > https://qa.debian.org/excuses.php?package=nmh) It looks like that dependent package is xbiff. Do you know how that is identified as a dependecy? I don't see it as an explicit dependency in nmh itself. David
Re: 1.8RC2?
Pascal wrote: > I have been using it (and previously rc1) on OpenBSD since it came out. > No issues so far. Thank you, Pascal. If all goes well, I hope to release 1.8 within a week. David
1.8RC2?
How does 1.8RC2 look? BSD users, have any of you tried it? For RedHat and Fedora users, you can install or upgrade using one of: sudo dnf install nmh --enablerepo=3Dupdates-testing sudo dnf upgrade nmh --enablerepo=3Dupdates-testing David
The second release candidate of nmh 1.8 is now available!
The second nmh 1.8 release candidate is now available. It contains several minor fixes relative to nmh-RC1, mostly to ancillary files. You can download it here: http://download-mirror.savannah.gnu.org/releases/nmh/nmh-1.8-RC2.tar.gz There is an accompanying .sig file for GPG verification. To simply download, build, and test: wget http://download-mirror.savannah.gnu.org/releases/nmh/nmh-1.8-RC2.tar.gz && tar xzf nmh-1.8-RC2.tar.gz && cd nmh-1.8-RC2 && ./configure && make check If you encounter any problems or issues with this release candidate, please don't hesitate to contact us at nmh-workers@nongnu.org. David Levine on behalf of the nmh development team Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: nmh 1.8?
az wrote: > debian: 1.8RC1 builds fine, and all tests pass. (there are, as always, > a small number of debian-specific deltas/patches but nothing of note.) Thanks! > i'll upload that version to debian unstable later today. If you haven't done that yet, I'll be pushing out 1.8RC2 shortly. David
Re: Fedora Rawhide just dropped a prerelease of gcc-13
Valdis wrote: > The good news is that I did a 'git pull' of nmh, 'make clean', './configure', > 'make'. > Zero gcc warnings even with -Wall -Wetra, 'make check' reported all 118 > tests passed, and nothing broken that I have noticed... Glad to hear it, thanks! David
Re: minor issues with 1.8-RC1 NEWS
Mike wrote: > Hi, I'm starting to look at 1.8-RC1, and I noticed a typo and an > omission in the NEWS file. > > Typo: In the first paragraph, "Long-time MH and nmh uses": > s/uses/users/. Fixed. That crept into the nmh 1.6 NEWS file. > Omission: It looks like mhparam no longer supports "libdir". I don't > object to the change, since the NEWS for nmh 1.7 noted that it would go > away at some point. But it does seem worth noting in the NEWS file for > 1.8. Fixed, and added the removal of MHPDEBUG for pick(1) as well. Thank you for pointing these out, Mike. David
Re: nmh 1.8?
Has everyone had a chance to try out nmh 1.8RC1? I'd like to hear of results from the BSDs, especially. For RedHat and Fedora users, you can install it using: sudo dnf install nmh --enablerepo=updates-testing I know that we want to try to get in Andy Bradford's patch for inc with POP and long lines. In any case, I'd like to push out an RC2 given that there have been a few (very minor) code updates. David
Re: [SCM] The nmh Mail Handling System branch, master, updated. 1.7-branchpoint-887-g54434563
Ralph wrote: > I've pushed a few more trivial documentation things to master, which > don't have to make 1.8. Those will be in 1.8. > I can see tag 1.8-branchpoint is the branch point for the 1.8-release > branch, but why are 69027ab9, 760a6ba9, 5608cda8, which alter VERSION > and DATE, on master rather than 1.8-release? Good question. When I did that I was thinking of where master is at that point in time. Maybe it should just be 1.8+dev? David
Re: Plans for distribution updates
Ken wrote: > - Various RPM-based distributions (Fedora, RedHat, CentOS, Rocky, > and I am sure others) I'll do Fedora and RedHat, which might include CentOS. And Cygwin, though just for the final 1.8 release. David
Re: [SCM] The nmh Mail Handling System branch, master, updated. 1.7-branchpoint-887-g54434563
Ralph wrote: > I've pushed a little update to that to master which falls after the 1.8 > tags. > > a3a23a66 (origin/master, origin/HEAD) > man/*.man: fix options which didn't escape their hyphen. > → 277347a4 NEWS: fix spelling of ‘MIME’. > f8fb242b NEWS: add a link to Norm's Wikipedia page. > 19d63f85 .gitignore: move ‘/configure~’ entry to correct section. Thanks for catching those. I cherry picked them to the branch. > Should I stop pushing commits now so as to not get in your way, or keep > pottering them in as they may make it if there's an 1.8-RC2? I'd rather avoid code changes because, in theory, they'd require complete re-testing. If you find a code change that really should go in, how about posting it here for concurrence? Everything else should be easy to cherry pick. David
The first release candidate of nmh 1.8 is now available!
Greetings all, I am pleased to announce that after four years we are finally starting the release cycle for nmh 1.8. The first release candidate is now available! You can download it here: http://download-mirror.savannah.gnu.org/releases/nmh/nmh-1.8-RC1.tar.gz There is an accompanying .sig file for GPG verification. (I've also included a MIME external-body pointer to it below, which nmh should be able to use with a suitable nmh-access-url profile entry.) The release has a large number of bug fixes and new features. The NEWS file included in the distribution has a reasonably complete list of the significant changes. If you encounter any problems or issues with this release candidate, please don't hesitate to contact us at nmh-workers@nongnu.org. David Levine on behalf of the nmh development team Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: nmh 1.8?
Ralph, your last round of changes look good to me. HEAD builds and tests cleanly for me on Fedora, Solaris 11, and Cygwin. Do you or anyone else have anything else you'd like to put in before starting the 1.8 release cycle? David
Re: send(1) and Draft-Folder.
I wrote: > Ralph wrote: > > Is this equivalent? > > > > Draft-Folder: -draftfolder's default > > I don't like that, because then I have to figure out how -draftfolder > fits in. I might have come across as harsh on that. In reality, I don't have a preference. David
Re: send(1) and Draft-Folder.
Ralph wrote: > Hi David, > > > How about changing all of these man page descriptions: > > > > Draft-Folder: To find the default draft-folder > > > > to: > > > > Draft-Folder: To specify the default draftfolder > > > > Removing the hyphen from the second draft-folder helps associate it > > with the -draftfolder switch, I think. > > Is this equivalent? > > Draft-Folder: -draftfolder's default I don't like that, because then I have to figure out how -draftfolder fits in. David
Re: valgrind Complaint for test/mhshow/test-charset.
Ralph wrote:
> I'm getting a repeatable valgrind(1) complaint with
>
> NMH_VALGRIND=1 make TESTS=test/mhshow/test-charset check
>
> on one machine but not the other. Both are x86_64 but with different
> C libraries, etc.
I don't get that complaint here, Fedora 37 with glibc 2.36.
> I think it's
>
> start_test 'Encoded parameter value'
>
> with the interesting, repetitive, bit of valgrind:
>
> ==19813551992192== Invalid read of size 8
> ==19813551992192==at 0x4024AC0: strncmp (strcmp-sse2.S:160)
> ==19813551992192==by 0x4004EBF: is_dst (dl-load.c:216)
> ...
> ==19813551992192==by 0x4923707: iconv_open (iconv_open.c:39)
I would think that would be suppressed by this in test/valgrind.supp:
{
iconv_open on Fedora 33
Memcheck:Addr16
fun:strncmp
...
fun:iconv_open
}
Even with that suppression removed, I don't see the complaint.
And it's clean for me on a non-debug build with all of the compiler
checks that build_nmh enables.
David
nmh 1.8?
Greetings as we approach the new year. It's been a long time since nmh 1.7.1 was released, March 2018 to be specific. What does everyone think of pushing out a 1.8 soon? Here are changes since 1.7.1: https://git.savannah.nongnu.org/cgit/nmh.git/plain/docs/pending-release-notes While Ken has a worthy wish list at https://lists.gnu.org/archive/html/nmh-workers/2019-05/msg0.html and maybe more, I've reached the point where I don't think that we should hold up a release any longer. What triggered this? I finally figured out how to package for Red Hat EPEL 8 and 9. I don't think that should be done with 1.7.1. And, the current HEAD has been stable for a while. As always, new features and improvements can be added as they're ready. Question: is anyone besides me using the Gmail integration on the gmailapis branch? It needs a fix, but if no one else is using it, that can wait. David
Re: send(1) and Draft-Folder.
I wrote: > How about changing all of these man page descriptions: > > Draft-Folder: To find the default draft-folder > > to: > > Draft-Folder: To specify the default draftfolder I committed that. And the additions to the profile created by install-mh(1) to enable the draft folder facility. David
Re: send(1) and Draft-Folder.
I wrote: > Ralph wrote: > > > So as it stands, the bug is with the man page and Draft-Folder should be > > removed. > > I'm not so sure. I see use cases for Draft-Folder with comp and whom. > I don't with dist, forw, repl, and whatnow. Now I see. dist, forw, repl, and whatnow need to know where to put or find drafts. How about changing all of these man page descriptions: Draft-Folder: To find the default draft-folder to: Draft-Folder: To specify the default draftfolder Removing the hyphen from the second draft-folder helps associate it with the -draftfolder switch, I think. David
Re: send(1) and Draft-Folder.
Ralph wrote: > So as it stands, the bug is with the man page and Draft-Folder should be > removed. I'm not so sure. I see use cases for Draft-Folder with comp and whom. I don't with dist, forw, repl, and whatnow. And I'm not sure about send given this: send with no file argument will query whether the draft is the intended file, whereas -draft will suppress this question. So to send a draft from a draftfolder non-interactively, the user would have to use "send -draft -draftfolder drafts". That seems too cumbersome to me. There is a typo in the mh-draft man page: will construct the message draft in the ‘draft’ folder using the ‘new’ message number. should say 'drafts' folder given these example profile entries: Draft−Folder: drafts sendf: −draftfolder +drafts > This is a perennial problem. I normally bring up Python's ‘from future > import ...’ method of requesting new behaviour. I don't think the benefits are worth the trouble we'd face when diagnosing user problems. We'd have to figure out what behavior the asked for vs what they think they asked for. David
Re: send(1) and Draft-Folder.
Ralph wrote: > I've Draft-Folder set to drafts in .mh_profile. Using at(1) to ‘send > 42’ fails because `mhpath +`/42 doesn't exist. Would it succeed with 'send -draftfolder drafts 42'? Or if your profile included '-draftfolder drafts' for a 'send' component? > The man page seems inconsistent. The default is -nodraftfolder so why > is Draft-Folder listed under Profile Components as it isn't used? Yeah, this looks like an unfortuate result of tacking on the draft folder facility, It would have been easier to have had that from the beginning. And only used that, because the old-style simple draft file isn't very useful with it. > I'd expect a .mh_profile Draft-Folder to be used by default. I agree. But I'm not sure if we want to change it at this point, to not break existing users' workflows. For new users, install-mh could add a "Draft-Folder" component and add a corresponding -draftfolder to a "send" component. David
Re: Question as I haven't been paying attention
Bakul wrote:
> Looking through git log, the following may have be interest:
>
> commit 54c9b8ee126b284c25b8ae3c7e600638fda2cb06
> Author: David Levine
> Date: Sun Jan 30 09:26:44 2022 -0500
That commit cleaned up the helper applications, some of which were
very out of date. I doubt it would be helpful to look at it.
Ken mentioned the man pages. The mhshow(1) man page should be helpful.
I have these in my profile:
showproc: less
mhshow: -noconcat -notextonly -noinlineonly
mhshow-show-text/html: firefox --new-window %F 2>/dev/null; sleep 0.2
show: -noconcat
David
> On Dec 7, 2022, at 3:50 PM, Jon Steinhart wrote:
> >
> > Bakul Shah writes:
> >> On Dec 7, 2022, at 2:32 PM, Jon Steinhart wrote:
> >>>
> >>> Just upgraded my system to FC37 which incldes nmh 1.7.1.
> >>> show now runs everything through more which I hate.
> >>> Can't seem to disable it, even with --showproc cat.
> >>> Can someone save the trouble of having to figure this
> >>> out from the source code?
> >>
> >> I have
> >>
> >> showproc:/usr/bin/less
> >>
> >> in my ~/.mh_profile. Shouldn't matter but this is on FreeBSD.
> >
> > Huh. OK, adding showproc: /bin/cat seemed to do it. Thanks.
> >
> > Oops, no it didn't. It works for your messages but that's
> > because it's text/plain, doesn't work on anything else such
> > as an html doc that I run through w3m to show as ascii.
> >
> > Can whoever made this change explain how to turn it off?
>
> I built a fresh version (commithash 0e68a78e44d03c) and ran it
> through ktrace to see what gets called. I have
>
> mhshow-show-text/html: charset=%{charset};
> w3m ${charset:+-I $charset} -T text/html %F
>
> in ~/.mh_profile. mhshow calls w3m to format the text
> and then calls less to display the formatted text. It
> also calls mhl. Setting -showproc has no impact, it still
> goes through less.
>
> You can try setting -showmimeproc to /bin/cat but that
> is probably not what you want for html!
>
> Looking through git log, the following may have be interest:
>
> commit 54c9b8ee126b284c25b8ae3c7e600638fda2cb06
> Author: David Levine
> Date: Sun Jan 30 09:26:44 2022 -0500
>
>
> [app1, app2, ... appN] shows the order that mhn.defaults.sh uses
> when looking for the helper for the specified content type and
> optional subtype.
>
> Support for audio content is only added if /dev/audioIU or /dev/audio
> exists.
>
> Old helper appplications
>
> [acroread, okular, evince, xpdf, gv]: application/pdf
> [okular, evince, gv]: application/postscript
> [ivs_replay]: application/x-ivs
> [soffice]: application/msword
> [splayer, raw2audio, cat >/dev/audio]: audio/basic
> [adpcm_dec, play]: audio/x-next
> [xv, netpbm + djpeg + xwud]: image
> [w3m, lynx, elinks]: text/html
> [richtext, rt2raw]: text/richtext
> [mpeg_play]: video/mpeg
>
> Changes:
> 1. replaced use of netpbm with mpv --keep-open, preferring mpv over xv
> 2. replaced mpeg_play with [mpv, mplayer] for video (not just video/mpeg)
> 3. moved acroread to end of application/pdf list
> 4. removed application/x-ivs support
> 5. removed text/richtext support
> 6. added mhshow-suffix-video.mp4 to mhn.defaults
>
> New helper appplications
>
> [okular, evince, xpdf, gv, acroread]: application/pdf
> [okular, evince, gv]: application/postscript
> [soffice]: application/msword
> [splayer, raw2audio, cat >/dev/audio]: audio/basic
> [adpcm_dec, play]: audio/x-next
> [mpv --keep-open, xv]: image
> [w3m, lynx, elinks]: text/html
> [mpv, mplayer]: video
Re: inc and non-compliant long lines redux
Andy wrote: > I'm running a similar patch on my nmh 1.7.1 installation and will report > any problems that I find in "production". > > Suggestions? Would it be much trouble for you to add tests for the test suite? David
Re: inc and non-compliant long lines redux
Michael wrote: > It did not apply cleanly on master: Same problems for me. Andy, are you able to create patches against HEAD? David
Re: does anyone use nmh's Google OAuth mechanism?
Ken wrote: > First off ... my apologies to everyone for being silent the past few > months. Things have been rather ... challenging in my personal and > professional life I hope that any difficult challenges resolve as best they can. > >Alternatives include updating nmh per the Google recommendations, or > >(I think) using Google APIs. If you use nmh's glogin.py, you're using > >Google APIs. > > > >Details from Google are available here: > >https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html > > > >The "might" and "I think" are due to me not understanding some of > >Google's announcement. For example, I expected to see a "user-facing > >warning message" starting September 5, but I don't see any such > >message. I'm also not sure if glogin.py is affected. It doesn't > >display any warning message, either. Google has not notified me about > >it; they did notify me about the older nmh Google OAuth mechanism. > > The thing that worries me is that as far as I can tell, we do use the > "oob" scope, at least as I understand it, and that's what specifically > they are shutting down. That's right. They have shut it down for what's in nmh 1.7.1. I need to go in and remove the Gmail-specific pieces. > So, are things going to continue to work? I guess > that's what I am really wondering. The Python code on the gmailapis branch continues to work. No warnings. I need to merge it to the main branch. David
Re: Packages for EL8 distros?
Tom wrote: > I'm in the process of standing up a new Alma Linux 8.6 server for the > company's forseeable future, and I was wondering if you had plans to > distribute a new nmh package into EPEL for RHEL 8-based distros, or if I > need to compile it myself for this particular build? Hoping for the > former, obviously, but - the boss sure lves his MH email, and > uses nmh to navigate it. I package nmh for Fedora. It won't build for EPEL 7 and I haven't figured out how to get it into EPEL 8 and 9 to try. I might not have time for a while. If you want to take a look, that would be very helpful. If you want to build an rpm yourself, this should work: wget http://git.savannah.gnu.org/cgit/nmh.git/plain/build_nmh sh build_nmh -drv -b 1.7-release and respond to the prompts. The RPM will be put in the RPM/RPMS/ directory below the installation. David
Re: does anyone use nmh's Google OAuth mechanism?
Bob wrote: > On Thu, 08 Sep 2022 06:29:32 -0700 David Levine sez: > > > > OAuth can also be used to send. It would be enabled using these nmh > > send(1)/post(8) switches: > > -saslmech xoauth2 -authservice gmail > > > > after logging in with mhlogin(1). > > > > David > > I too use fetchmail(1). (Too lazy to change. B-) But I use it > _just_ to fetch email from Gmail to my laptop, not to send. I > never knew it had that capability Whoops, I should have said that OAuth can be used to authenticate when sending. fetchmail can't send. David
Re: does anyone use nmh's Google OAuth mechanism?
Michael wrote: > David Levine wrote: > > If you use nmh's mhlogin(1) to login to Gmail, then you use nmh's > > Google OAuth mechanism. Please let me know if you use it. > > I try do, but I think that I fell back to fetchmail on my laptop. Glad to hear that. OAuth can also be used to send. It would be enabled using these nmh send(1)/post(8) switches: -saslmech xoauth2 -authservice gmail after logging in with mhlogin(1). David
does anyone use nmh's Google OAuth mechanism?
Effective October 3, 2022, use of nmh's Google OAuth mechanism will (or might) be blocked by Google. This feature was introduced in nmh 1.7 to allow receiving and sending through a user's Gmail account. If you use nmh's mhlogin(1) to login to Gmail, then you use nmh's Google OAuth mechanism. Please let me know if you use it. Alternatives include updating nmh per the Google recommendations, or (I think) using Google APIs. If you use nmh's glogin.py, you're using Google APIs. Details from Google are available here: https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html The "might" and "I think" are due to me not understanding some of Google's announcement. For example, I expected to see a "user-facing warning message" starting September 5, but I don't see any such message. I'm also not sure if glogin.py is affected. It doesn't display any warning message, either. Google has not notified me about it; they did notify me about the older nmh Google OAuth mechanism. Thanks, David
Re: Surprising MIME Type from Android.
Ralph wrote: > Fair enough. Either way, I think nmh should baulk at invalid characters > in the MIME type so to avoid creating ‘42.2.*’ as it contains shell > globbing characters. Agreed. If you don't have time in the near future, this would be a great task to introduce someone new to nmh work. It's "balk" in baseball rulebooks. I never knew it's spelled differently on your side of the pond. David
