Ken wrote:
> Oh, hm, what a great question. I hope the creator of this bug is on
> nmh-workers and can chime in. However ... I'm not sure there's a
> wonderful answer, although maybe it's possible with some (possibly
> a lot of) work.
Thanks, Ralph and Ken.
I added a link to this email thread
The recent bug report, Bug #65934: rcvdist runs afoul of gmail DMARC/DKIM/ARC
policies, could use some discussion here, I believe.
Here are the contents of the bug (https://savannah.nongnu.org/bugs/?65934):
I have been using slocal and rcvdist for many years to forward filtered
mail to a pr
Arthur wrote:
> Using OpenBSD -current and emacs-29.4 I am trying to get
> diary-mail-entries to work. What I get is:
>
> post: no mailbox in address, only a phrase (July 21,) July 21, continuing...
> Sunday: loses; [USER] 550 Invalid recipient:
> 2024: loses; [USER] 550 Invalid recipient: <2
George wrote:
> That would be great.
commit da1e630f2c0d6196d949b99b35f5a0771e9cdb3b
Author: David Levine
Date: Sat Jul 6 07:56:33 2024 -0400
Added message number to scan "botch" error message.
Formatted it as "scan() botch (%d) attempting to read `%d'" to be
Ralph wrote:
> We report the problem better in other cases.
Agreed.
How about this simple addition to identify the offending directory:
diff --git a/uip/scan.c b/uip/scan.c
index 00992b3d..80846630 100644
--- a/uip/scan.c
+++ b/uip/scan.c
@@ -224 +224 @@ main (int argc, char **argv)
-
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 i
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
> > $ ./te
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/thoma
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
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
> 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
Arthur wrote:
> Yesterday everything worked. Today, trying to reply to a message I get:
>
>
> In message
> ,
> "B. William via Remind-fans" writes:
> >SG1tbW0gdGhpcyBsaW5lIGRvZXMgVEhJUyBXRUVLLCArIDMgTU9SRSBXRUVLUyBhbmQgZ2l2ZXMg
> >dGhlIGRhdGVzOgoKcmVtaW5kIC1zKzQgLXEgLXIgfi8ucmVtaW5kZXJzI
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 s
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 a
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 chan
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-pos
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?
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
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
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,
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.
>
This is recommended by RFC 5322 2.1.1. Line Length Limits.
Signed-off-by: David Levine
David
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 head
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
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...@bureaucr
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 l
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
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 bod
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
Philipp wrote:
> Ah, I forgott the early continue. The attached version sould work.
It does. I'm sending this message using it.
David
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 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
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&#x
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 l
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 committin
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
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
>7479
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-br
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
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.
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 o
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 u
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
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
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 ques
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
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
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
s
f65fecbc668db777e2f4fabb23a08edf11b
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
s, 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
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
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 alternati
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 100
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(
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 d
/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
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
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
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. Th
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
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!
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:
> whi
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
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
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
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
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("HO
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
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
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(
Jerry wrote:
> Success on Mageia Linux 8. Working as promised, using live for email
> as I type.
Thanks, Jerry.
David
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 t
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
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
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
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 p
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
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
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
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
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
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"
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 lon
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 maste
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
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'
nably 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.
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
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
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
> >
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
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
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 facilit
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
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
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.
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
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
Michael wrote:
> It did not apply cleanly on master:
Same problems for me.
Andy, are you able to create patches against HEAD?
David
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 recommend
1 - 100 of 1608 matches
Mail list logo
