Re: [Nmh-workers] nmh in near, medium, and far-term
On Tue, 06 Dec 2011 17:45:43 EST, valdis.kletni...@vt.edu writes: >>And if you figured out how to get exmh to use the "fixed" font >> with the most recent version of Tk, that would be super-awesome :-) (As >> an aside ... from my brief investigation, it seems that with the changes >> to the font handling in Tk you can no longer use any X font that is >> semicondensed, and fixing it required looking at the whole Tk font mess). > >I'll take a look at that, I suspect that exmh's use of fonts needs to be cleane >d >up since the rest of the world moved to fontconfig/cairo. i committed a band-aid fix for this to cvs, back in april - see http://article.gmane.org/gmane.mail.exmh.devel/977>. the debian versions since 2.7.2-22 (ie. testing and unstable) include that fix. regards az -- + Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ A)bort, R)etry, P)ee in drive door signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Debian
On Sat, 07 Jan 2012 12:00:12 PST, Bill Wohler writes: >Jeffrey Honig writes: > >> I'm thinking we should look into providing a repo with our own debs >> that will run on both Debian and derivatives to increase the >> availability of the latest code. please don't. dealing with custom/halfbaked packages makes a packager's work a lot harder and annoying: as upstream you're supposed to be the expert on how to make the software work well. leaving the (occasionally messy) integration work to the integration expert minimizes the duplication of effort. >As long as Debian maintainers update their packages in a timely manner, >and by and large, they do, I think that's more work than it's worth. i've just created a wishlist bug (http://bugs.debian.org/655047) asking for the new version to be packaged. >And if we configure our nmh .deb differently from the way Nick does it, >we'd be doing our users a disservice. indeed - and if nick can't find the time to update nmh, then there's surely other debian developers who can step in. regards az -- + Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Debian
On Sat, 07 Jan 2012 12:00:12 PST, Bill Wohler writes: >Jeffrey Honig writes: > >> I'm thinking we should look into providing a repo with our own debs >> that will run on both Debian and derivatives to increase the >> availability of the latest code. please don't. dealing with custom/halfbaked packages makes a packager's work a lot harder and annoying: as upstream you're supposed to be the expert on how to make the software work well. leaving the (occasionally messy) integration work to the integration expert minimizes the duplication of effort. >As long as Debian maintainers update their packages in a timely manner, >and by and large, they do, I think that's more work than it's worth. i've just created a wishlist bug (http://bugs.debian.org/655047) asking for the new version to be packaged. >And if we configure our nmh .deb differently from the way Nick does it, >we'd be doing our users a disservice. indeed - and if nick can't find the time to update nmh, then there's surely other debian developers who can step in. regards az -- + Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On Mon, 06 Feb 2012 18:59:17 EST, Ken Hornstein writes: >And while we're talking about post I always forget about it, but there's >also spost. It opens a pipe to sendmail -t and uses that to submit email. >It's not documented and there's a lot of duplicated code there. I propose >to just get rid of it (because, frankly, I don't want to have to hack on that >code twice). Objections? yes! please either keep it, or improve post by giving it a switch that allows it to submit mail to an mta/msp program directly. submitting mail via smtp is not an option (or not an ideal one) for some of us. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Things should be as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On Mon, 06 Feb 2012 21:17:42 EST, Ken Hornstein writes: >>yes! please either keep it, or improve post by giving it a switch that >>allows it to submit mail to an mta/msp program directly. > >E ... you know about the sendmail mts, right? i do indeed - but post always talks smtp, even with mts: sendmail. i need something that submits to a program on stdin without any to-and-fro interaction - which is precisely what spost does. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Starting your usenet experience with this group is like starting your drug experiences with 500 mikes of acid with an amphetamine chaser. -- Rebecca Ore about the monastery signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings & spost
On Mon, 06 Feb 2012 22:02:15 EST, Ken Hornstein writes: >>>>yes! please either keep it, or improve post by giving it a switch that >>>>allows it to submit mail to an mta/msp program directly. >>> >>>E ... you know about the sendmail mts, right? >> >>i do indeed - but post always talks smtp, even with mts: sendmail. >> >>i need something that submits to a program on stdin without any >>to-and-fro interaction - which is precisely what spost does. > >Really? I'm curious ... why? sorry for the late response, but here it is: i'm using kuvert, a wrapper for outbound mail that gpg-signs/encrypts it automatically based on where the mail is going. (see http://snafu.priv.at/mystuff/kuvert/ if interested) that's my "sendmail:" entry in mts.conf, and the kuvert tool emulates/wraps sendmail in stdin mode (ie. sendmail or sendmail -t). i do this job at that particular point in the pipeline because i use all of exmh, mh-e (and occasionally raw nmh) in parallel and don't want to teach each of them independently what my crypto preferences are - and i *definitely* don't want two+ parties caching my key passphrases. as to living with post-doing-batched-smtp: of course i can hack up kuvert to support this, but i really really like the straightforward simplicity of non-interactive, one-shot submission of mails where smtp isn't involved (locally). >Enough people have said that they use it that it's not going >to get removed for 1.5; I'm just trying to understand what they need >from spost that post doesn't provide. that's fine, and in time i'm sure somebody will find the energy/time to contribute the code for an spost-like submission mode for post. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] NMH long lines
On Mon, 20 Feb 2012 12:02:51 GMT, mark.w...@hmrc.gsi.gov.uk writes: >I see this has been covered in some detail but I really need to know if >there's an override for the 998 character line limit when building a >message for sending? the 998 byte line length limitation is part of the smtp mail format, as per rfc822/2822/rfc5322, section 2.1.1, and thus pretty much set in concrete. https://tools.ietf.org/html/rfc5322#section-2.1.1 mime helps one to work around that with the q-p encoding and 'fake' line breaks. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Every bit is sacred, Every bit is right. If a bit is wasted, I can't sleep at night. Every bit is gorgeous, Every bit is free. Admire the shape it forges, In hex and BCD! signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem reported in comp.mail.mh
On Sun, 20 May 2012 11:45:45 -0400, Ken Hornstein writes: >I don't have access to any Debian systems ... *debian hat on* >and I don't know why getting a valid dbm library is so hard under Linux. it's not. the official (outdated) nmh package, for example, properly specifies that it build-depends on libdb-dev. jerry, you can't expect to be able to build nmh (any version) without having the prerequisite software present (whether in the form of prebuilt packages or not doesn't make any difference here). >Maybe there's another dbm package that would work? apt-get install libdb-dev and things work. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ "Quoted-Printable: a standard for mangling Internet messages Quoted-Unreadable: the result of applying said standard Unquoted-Unprintable: the comments from the recipients of the above" -- bf8 signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in debian
On Tue, 29 May 2012 01:37:44 +0200, Harald Geyer writes: >Is there any DD on this list, who could sponsor an upload of 1.4 or 1.5RCx? here. i'm the DD maintaining exmh, so nmh is close to the heart and i'd be happy to maintain it. i'll check with nick if he's ok with co-maintaining. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ "How degrading -- to actually have to use a _voice-quality_ line for _speech_." -- Mike Andrews, a.s.r signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] question about encoded recipient names
On Sat, 09 Jun 2012 23:40:03 -0400, Ken Hornstein writes: >another question. I don't actually use MM_CHARSET myself; if it's not >set then nmh simply falls back to using your locale setting (assuming >you have support for the nl_langinfo() function). Why do people use >MM_CHARSET instead of just their locale setting? maybe because the mh-profile and scan man pages say so? :-) regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ We're standing there pounding a dead parrot on the counter, and the mgt. response is to frantically swap in new counters to see if that fixes the problem. -- Peter Gutmann signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The third release candidate of nmh is now available
On Thu, 31 May 2012 13:24:38 -0400, Ken Hornstein writes:
>This release has a few minor bugfixes relating to the test suite,
>documentation, and non-ASCII charset handling in mh-format(5) routines.
>If there are no problems with this release I expect to release 1.5 final
>reasonably soon, so if you've been waiting to try it out now would be
>the time!
i've finished packaging nmh-1.5-rc3 for debian, and just uploaded it to
unstable; as the current maintainer is non-responsive to the extreme
i guess i'll take over.
anyway, i ran into a few minor issues, mostly related to the test suite:
* the test suite /really/ dislikes it if there's no /dev/tty or if stdin isn't
connected to a tty. this is unfortunately the case for the debian autobuilder
infrastructure (= fully automated, non-interactive chroots).
the mhshow/test-* and bad-input/test-header tests fail in an interesting
fashion: mhshow uses more and without stdin (at least the util-linux-)more
adds
"::
name of file
::"
to the output. this breaks the comparison of actual and expected value.
my fix was to check [ -t 0 ] || sed -e '/^:::*$/,+2{d}'
but on reflection a 'moreproc: cat' in the dummy .mh_profile for the tests
seems more appropriate.
* pick/test-pick doesn't survive an existing /dev/tty that is not backed
by kernel support (-w succeeds but writing fails, and
set -e makes this terminal...).
if test -w /dev/tty && echo > /dev/tty; then... fixed this issue for me.
* format/test-mymbox doesn't work when you build under sudo (or fakeroot),
because $LOGNAME is used but %mymbox{text} triggers on the effective
uid and the comparison fails. for the debian version i removed the $LOGNAME
default and go with id -unr.
apart from that there was just one tiny man glitch: install-mh claims to be
in section 8, but its file name (and makefile entry) place it in section 1.
(the debian version also moves nmh and mh-chart into section 7.)
regards
az
--
Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/
Do not meddle in the affairs of kitties, for they are subtle
and will piss in your keyboard. -- Peter H. Coffin
signature.asc
Description: Digital Signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.5 has been released!
'--exclude=_darcs' '--exclude=.bzr' nmh-1.5~/uip/whatnowsbr.c nmh-1.5/uip/whatnowsbr.c
--- nmh-1.5~/uip/whatnowsbr.c 2012-06-11 14:06:19.0 +1000
+++ nmh-1.5/uip/whatnowsbr.c 2012-06-12 20:03:54.316798423 +1000
@@ -141,9 +141,9 @@
char **argp, **arguments;
struct stat st;
char *attach = NMH_ATTACH_HEADER;/* attachment header field name */
-char cwd[MAXPATHLEN + 1]; /* current working directory */
-char file[MAXPATHLEN + 1]; /* file name buffer */
-char shell[MAXPATHLEN + 1]; /* shell response buffer */
+char cwd[PATH_MAX + 1]; /* current working directory */
+char file[PATH_MAX + 1]; /* file name buffer */
+char shell[PATH_MAX + 1]; /* shell response buffer */
FILE *f; /* read pointer for bgnd proc */
char *l; /* set on -l to alist command */
int n; /* set on -n to alist command */
#! /bin/sh /usr/share/dpatch/dpatch-run
## 03-smtptest.dpatch by
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: fakesmtp tool doesn't always start fast enough
@DPATCH@
diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' nmh-1.5-release~/test/post/test-post-common.sh nmh-1.5-release/test/post/test-post-common.sh
--- nmh-1.5-release~/test/post/test-post-common.sh 2012-06-04 05:37:10.0 +1000
+++ nmh-1.5-release/test/post/test-post-common.sh 2012-06-12 20:27:55.134596720 +1000
@@ -26,7 +26,8 @@
test_post ()
{ "${MH_OBJ_DIR}/test/fakesmtp" "$1" $localport &
pid="$!"
-
+# the server doesn't always come up fast enough...
+sleep 5
send -draft -server 127.0.0.1 -port $localport || exit 1
wait ${pid}
regards
az
--
Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/
Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and
weighs 30 tons, computers in the future may have only 1,000 vacuum tubes
and weigh only 1 1/2 tons. -- Popular Mechanics, March 1949
signature.asc
Description: Digital Signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] nmh 1.5 doesn't work on 64-bit big-endian archs (+patch)
i've run into another gotcha: the base64-decoder doesn't
work on 64-bit big-endian architectures: mhstore and co. write
files of the correct length but which consist only of \0s.
the culprit is uip/mhparse.c, which contains a pretty ugly base64
decoder (in two places). that thing allocates a "long int" as a container
for the 24 bits that you get from four base-64 chars. the container is then
accessed both as a single entity and as a byte array, which naturally
depends on how wide the long int is and in what order things end up in there.
the code distinguishes between big- and little-endian systems but wrongly
assumes that sizeof(long int) == 4, which isn't universally
true (quel surprise...).
the attached patch fixes the issue, but in the long run we should
insist on posix and use a64l().
regards
az
#! /bin/sh /usr/share/dpatch/dpatch-run
## 05-base64-64bit-bigendian.dpatch by
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: homegrown base64 decoder fails on all big-endian and 64-bit architectures (like s390x)
@DPATCH@
diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' nmh-1.5-release~/uip/mhparse.c nmh-1.5-release/uip/mhparse.c
--- nmh-1.5-release~/uip/mhparse.c 2012-06-14 16:35:36.0 +1000
+++ nmh-1.5-release/uip/mhparse.c 2012-06-14 16:36:02.322155163 +1000
@@ -1737,10 +1737,15 @@
CE ce;
MD5_CTX mdContext;
+/* the decoder works on the least-significant three bytes of the bits integer,
+ but their position in memory depend on both endian-ness and size of
+ long int... for little-endian architectures the size is irrelevant, for
+ big-endian archs it's crucial... ideally we'd adopt posix and use a64l instead
+ of this mess. */
b = (unsigned char *) &bits;
-b1 = &b[endian > 0 ? 1 : 2];
-b2 = &b[endian > 0 ? 2 : 1];
-b3 = &b[endian > 0 ? 3 : 0];
+b1 = &b[endian > 0 ? sizeof(bits)==8?5:1 : 2];
+b2 = &b[endian > 0 ? sizeof(bits)==8?6:2 : 1];
+b3 = &b[endian > 0 ? sizeof(bits)==8?7:3 : 0];
ce = ct->c_cefile;
if (ce->ce_fp) {
@@ -2825,10 +2830,16 @@
unsigned char *dp, value, *ep;
unsigned char *b, *b1, *b2, *b3;
-b = (unsigned char *) &bits,
-b1 = &b[endian > 0 ? 1 : 2],
-b2 = &b[endian > 0 ? 2 : 1],
-b3 = &b[endian > 0 ? 3 : 0];
+/* the decoder works on the least-significant three bytes of the bits integer,
+ but their position in memory depend on both endian-ness and size of
+ long int... for little-endian architectures the size is irrelevant, for
+ big-endian archs it's crucial... ideally we'd adopt posix and use a64l instead
+ of this mess. */
+b = (unsigned char *) &bits;
+b1 = &b[endian > 0 ? sizeof(bits)==8?5:1 : 2];
+b2 = &b[endian > 0 ? sizeof(bits)==8?6:2 : 1];
+b3 = &b[endian > 0 ? sizeof(bits)==8?7:3 : 0];
+
bitno = 18;
bits = 0L;
skip = 0;
--
Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/
Perl is like vise grips. You can do anything with it but it is
the wrong tool for every job. -- Bruce Eckel
signature.asc
Description: Digital Signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.5 has been released!
On Tue, 12 Jun 2012 12:23:36 -0500, David Levine writes: >How about this instead: > ># The server doesn't always come up fast enough, so sleep and ># retry a few times if it fails... >status=1 >for i in 0 1 2 3 4 5 6 7 8 9; do >if send -draft -server 127.0.0.1 -port $localport >/dev/null 2>&1; then >status=0 >break >fi >sleep 1 >done >[ $status -eq 0 ] || exit 1 yes, that's perfect. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Perl is like vise grips. You can do anything with it but it is the wrong tool for every job. -- Bruce Eckel signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.5 doesn't work on 64-bit big-endian archs (+patch)
On Thu, 14 Jun 2012 08:15:29 -0400, Ken Hornstein writes: >>i've run into another gotcha: the base64-decoder doesn't >>work on 64-bit big-endian architectures: mhstore and co. write >>files of the correct length but which consist only of \0s. > >Just curious ... did the test suite catch this? Because if it didn't, then >we should DEFINITELY have a test for it. it did, but the info that it provided was not overly helpful - just some mhlists and mhstore 'contents of expected and actual differ' and indications of faulty content-md5 hashes. it took me most of a day with printf and the source to figure out what was *really* going on... regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ "Alas I've yet to find a gig which offers "control of Orbital Anvil Delivery System at weekends" as a fringe-benefit." -- Tanuki signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] merge spost into post
On Sat, 07 Jul 2012 18:12:20 -0500, David Levine writes: >I'm thinking about merging the spost sendmail interaction >method into post. oh, yes please! >We'd need a new mts value, in addition to the current "smtp" >and "sendmail", in mts.conf to select it. why not reuse "sendmail" with a profile/cmdline option for post to select the pipe mode instead of batched smtp? after all both scenarios do involve sendmail (or whatever mts.conf says is sendmail:) regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ > hence the AIX boxen of increasing power [...] That phrasing reminded me of "Rodents of Unusual Size". -- Mike and Greg Andrews signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] merge spost into post
On Sun, 08 Jul 2012 08:52:09 -0500, David Levine writes: >Well, post doesn't read the profile. ah, good point. i was misled by an ancient "post: -msgid" in my .mh_profile. on further reflection your setup makes much more sense indeed: only one file to configure all the relevant bits in. maybe call the mts values: smtp, bsmtp (alias sendmail, for backwards compat), pipe? regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ You can believe anything you want. The universe is not obliged to keep a straight face. signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] whatnow brittle wrt. $SHELL
whatnow cooks up strings for executing external commands, and then feeds these
strings to popen or system.
these command strings rely on $SHELL being present - and if that is
not the case, then we get weird error messages
("sh: -c not found" or similar).
(because both system() and popen() start up fine with the std shell, but
their arg string to parse doesn't include a cmdname/path before the -c)
as far as i understand the POSIX standard, SHELL is recommended
but not actually mandatory, so i think it would be good to
handle this a bit more robustly: by setting SHELL to /bin/sh if not present.
the attached trivial patch uses setenv() with overwrite=0 to achieve that.
regards
az
#! /bin/sh /usr/share/dpatch/dpatch-run
## 07-shell.dpatch by
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: workaround for #682362 (debuild nukes $SHELL)
@DPATCH@
diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' nmh-1.5-release~/uip/whatnowsbr.c nmh-1.5-release/uip/whatnowsbr.c
--- nmh-1.5-release~/uip/whatnowsbr.c 2012-07-22 12:19:48.742288837 +1000
+++ nmh-1.5-release/uip/whatnowsbr.c 2012-07-22 12:22:00.145064615 +1000
@@ -605,6 +605,11 @@
{
char olddir[BUFSIZ];
int r;
+
+/* ensure that $SHELL exists, as the cmd was written relying on
+ a non-blank $SHELL... */
+setenv("SHELL","/bin/sh",0); /* don't overwrite */
+
if (getcwd(olddir, sizeof(olddir)) == 0)
adios("getcwd", "could not get working directory");
if (chdir(dir) != 0)
@@ -621,6 +626,11 @@
{
char olddir[BUFSIZ];
FILE *f;
+
+/* ensure that $SHELL exists, as the cmd was written relying on
+ a non-blank $SHELL... */
+setenv("SHELL","/bin/sh",0); /* don't overwrite */
+
if (getcwd(olddir, sizeof(olddir)) == 0)
adios("getcwd", "could not get working directory");
if (chdir(dir) != 0)
--
Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/
The idea is that RAID stands for Redundant Array of Inexpensive Dreck.
-- Anthony de Boer
signature.asc
Description: Digital Signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] whatnow brittle wrt. $SHELL
On Sun, 22 Jul 2012 12:41:41 -0500, David Levine writes: >I added a test of that (unset SHELL) to whatnow/test-ls. >But it doesn't seem to catch the problem on Linux. It looks >like its system() always sets SHELL to /bin/bash if it was not quite so in my experience on linux systems: system() and popen() *always use* /bin/sh -c, and totally ignore SHELL. but: /bin/bash itself does set SHELL, so if it's involved you'll have next to no chance of seeing this scenario. the environment where i encountered the problem involves /bin/dash, the posix-only shell that debian defaults to for /bin/sh (and a build tool that's a tad overzealous in cleaning the environment). the nmh code tries to be "nice and helpful" and work with the user's preferred shell, so we certainly waste some cycles with /bin/sh -c whatevershell -c ...actual stuff... personally i don't think that aiming for the users' preferred shell is necessary for the not-very-interactive situation with whatnow, so the $SHELL -c code should indeed be dumped in the long run. regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ #define sizeof(x) rand() -- Dark_Brood signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] bcc components
On Thu, 16 Aug 2012 22:31:21 -0500, David Levine writes: >Michael wrote: >> I'm running: >> ii nmh 1.5-release-0.2 >> >> from debian wheezy. (testing) > >I don't do debian so I can't readily look at it. But >how could the send(1) man page be from 1.4? most likely an outdated man cache, because i know for sure that i put the correct man pages into 1.5-release-0.2. michael, is your /usr/share/man/man1/send.1.gz newer than /var/cache/man/cat1/send.1.gz? if that's the case your man install has a problem... regards az -- Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ The Microsoft Torque Wrench: what do you want to shear today? -- Malcolm Ray signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Ditch autoconf selection of pager?
On Mon, 14 Jan 2013 16:38:42 -0800, Paul Vixie writes: >i beg to differ. the best damn keyboard on the planet is: [ibm model-m] maybe, but you need hearing protection to work on it. i much prefer sun type 4 or 5 (which can be made ps2-compatible without too much hassle, <http://snafu.priv.at/mystuff/sunkbd.html>) regards az -- Alexander Zangerl + GPG Key 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would fully suffice. -- Einstein signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh dependence on metamail
On Sat, 18 May 2013 11:20:00 -0500, Dale Alspach writes: >Are there any replacements for metamail or an updated source? >exmh seems to work fine. in 2008 i modified exmh to try mimencode first (that's from metamail if you still have it), then fall back to recode and if that's unavailable use the slow internal encoder. recode is present in debian and ubuntu, and is not hard to use: $ recode data..quoted-printable < whatever > otherthing $ recode base64..data < encoded > raw regards az -- Alexander Zangerl + GPG Key 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ superglue works better on cats than paste. it sets much faster which is important when you are gluing a cat. -- John W. Krahn about 'cat-and-paste' signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] show in Debian Linux is slightly Different than in FreeBSD.
On Mon, 16 Sep 2013 06:25:22 -0500, Martin McCormick writes: >When nmh is installed on a FreeBSD-based system, the >show command works as one would expect. You get whatever headers >you have selected to see plus the first screen of the message. >On two Linux systems, I get the selected headers as shown >below: ...headers pager'd independent of the body this is precisely working as per manual for show when you are showing a message that's not just text/plain (see showmimeproc in show(1)): first headers, then all the body parts separately. a quick fix would be to use show -nocheckmime or show -showmimeproc mhl (or showmimeproc in .mh_profile); that way you lose the mime part separation but gain uninterrupted display. > This is really not a new issue but I thought it was >peculiar to one system and then I discovered that it is >apparently common to at least Debian Linux systems, one of which >is Squeeze and the other is Wheezy. i don't think that this is debian-specific, but i rather suspect it's an artefact of the common-ish mailcap stuff in linux, which might be handled differently on *bsd? (or might it have been that you tested with a plain message on the bsd and a mime-encrusted one on the linuxes?) regards az -- Alexander Zangerl + GPG Key 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Q. why do you get when you cross an elephant and a grape? A. sin(theta) Note: assumes |elephant|==|grape|==1 signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 and text parts
On Sat, 19 Oct 2013 23:33:31 -0400, valdis.kletni...@vt.edu writes: >I admit being insufficently caffienated at the moment to know whether >this would break S/MIME or PGP, but ISTR that the signatures are done >over a canonical CR/LF. that's correct; see rfc3156, section 5. https://www.rfc-editor.org/rfc/rfc3156.txt >So we probably need to treat decoding and >converting to local line-end conventions as two separate steps. indeed - and i'd go a bit further: if nmh encounters a mail that's multipart/signed or multipart/encrypted, then it has to leave the whole thing untouched. (see also section 3 or the above rfc) regards az -- Alexander Zangerl + GPG Key 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Fachbegriffe der Informatik, Admin: Die wo machen, daß das Internet geht, aber die man nicht fragen darf, wenn es um ein klemmendes Word geht, da sonst das Internet an meinem Rechner wieder nicht geht, weil die dann stinkewütend werden. -- Bernd Jürgens signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] IMAP, again
On Mon, 28 Oct 2013 14:32:17 -0700, Lyndon Nerenberg writes: > >On Oct 28, 2013, at 8:35 AM, valdis.kletni...@vt.edu wrote: > >> Hmm.. so 'anno' is a complete loss then? I'd be screwed if I didn't have >> a way to add 'Replied:' headers > >With a basic 3501 server, yes. > >However, if the IMAP server supports the ANNOTATE extension (RFC5257), >it should be possible to support almost all of anno(1). and there's always the possibility of using APPEND to upload modified mails back to the server, which is less than lovely as you have to upload the complete mail. regards az -- Alexander Zangerl + GPG Key 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ Surely the 4 sysadmins of the apocalypse should be: edquota, rm -rf, kill -9, and shutdown. -- Rob Blake signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Building nmh 1.6 for Ubuntu 12.04
On Tue, 15 Apr 2014 23:40:27 +0100, Ralph Corderoy writes: >> So, what's the process for getting that updated? I see Nick Rustov is >> the maintainer for it, but I don't know if he's still around. 1.3 was >> released in 2008. > >Nick is Debian's maintainer AIUI and Ubuntu just pick up Debian's >version. Debian 7, "wheezy", the current stable release, has >1.5-release-0.2; https://packages.debian.org/wheezy/nmh > >http://packages.qa.debian.org/n/nmh.html suggests Alexander Zangerl is >an "uploader". call it co-maintainer for max politeness, but basically i've been doing all debian nmh (and exmh) work for quite a while. the most recent debian release ships with 1.5 (and a few patches from git). i plan to build and upload 1.6 soonish, but it'll have to wait until after easter. regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ REAL*8 RESPONSE(8) DATA /RESPONSE/ 8HYOU EVER,8H DONE IT,8H IN FORT,8HRAN IV?$ -- Peter da Silva about the joys of string handling signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Second release candidate for nmh 1.6 now available
On Sat, 19 Apr 2014 23:49:15 -0400, Ken Hornstein writes:
>This release include a few bug fixes to RC1, including fixes for SASL
>support and scan line corruption when using inc(1) with POP or Maildir.
>Please see the NEWS file for the list of changes since the 1.5 release.
i've just finished the packaging of nmh 1.6 rc2 for debian, and found
two bugs:
. with locale iso-8859-1 mhshow fails to display an
utf-8 encoded mail and test/mhshow/test-subpart fails.
mhshow reports
mhshow: Can't convert utf-8 to ISO-8859-
mhshow: unable to convert character set of part 1.1
to utf-8, continuing...
yes, the error message *really* shows the charset incorrectly,
without the trailing 1.
i've traced this back to norm_charmap(). most of the time it returns
just static strings (or the original input), but for charsets
containing "8859-" or "CP12" it uses, returns and reuses the same
static string buffer.
because the calling code does not copy norm_charmap's output away
safely ( but instead does fun things like
strcmp(norm_charmap(source),norm_charmap(dest)) ) subsequent calls to
norm_charmap then destroy the result of the previous one
if charsets win-1252 or iso-8859-x are involved.
the dud "ISO-8859-" is the buffer initializer which i
believe is caused by norm_charmap being asked to work on its own output.
i've fixed this by malloc()ing that buffer; see attached patch.
. the lzma in debian (9.22-2) refuses to uncompress a file named '11.tar'
even with -cdf based on the file's extension;
this breaks test/post/test-sendfiles. for now i've disabled
lzma compression as a test option for this test.
regards
az
Description: repair problematic static buffer returned by norm_charmap()
Author: Alexander Zangerl
--- a/sbr/norm_charmap.c
+++ b/sbr/norm_charmap.c
@@ -28,12 +28,10 @@
#define digit(x) ((x) >= '0' && (x) <= '9')
-static char buf[16];
-
char *
norm_charmap(char *name)
{
- char *p;
+ char *p, *buf;
if (!name)
return name;
@@ -73,6 +71,9 @@ norm_charmap(char *name)
/* ISO 8859 will be converted to "ISO-8859-x" */
if ((p = strstr(name, "8859-"))) {
+/* mustn't overwrite previous norm_charmap results, so dynamic buffer */
+if (!(buf=malloc(16)))
+ return buf;
memcpy(buf, "ISO-8859-\0\0", 12);
p += 5;
if (digit(*p)) {
@@ -80,10 +81,14 @@ norm_charmap(char *name)
if (digit(*p)) buf[10] = *p++;
return buf;
}
+free(buf); /* free mem if dud input */
}
/* Windows code pages will be converted to "WINDOWS-12xx" */
if ((p = strstr(name, "CP12"))) {
+/* mustn't overwrite previous norm_charmap results, so dynamic buffer */
+if (!(buf=malloc(16)))
+ return buf;
memcpy(buf, "WINDOWS-12\0\0", 13);
p += 4;
if (digit(*p)) {
@@ -91,6 +96,7 @@ norm_charmap(char *name)
if (digit(*p)) buf[11] = *p++;
return buf;
}
+free(buf); /* free mem if dud input */
}
/* TIS-620 comes in at least the following two forms */
--
Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/
I halve a spelling chequer - It came with my pea sea -
It plane lee marques four my revue - Miss steaks aye ken knot sea
-- J.S. Tenn, Owed to a Spell Chequer
signature.asc
Description: Digital Signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Second release candidate for nmh 1.6 now available
On Sun, 04 May 2014 09:35:08 -0400, Ken Hornstein writes: >> the dud "ISO-8859-" is the buffer initializer which i >> believe is caused by norm_charmap being asked to work on its own output. >> >> i've fixed this by malloc()ing that buffer; see attached patch. > >Thanks! However ... that will result in a memory leak, yes? Okay, yes, and i'm certainly not claiming this to be a perfect fix. >you'll point out that nmh is terrible on memory management and I won't >disagree, but I don't think that's an excuse for making it worse. >Fixing this properly either means we need to be much more clever in >norm_charmap(), or always allocate a buffer and fix every caller of >norm_charmap(). Sigh. that's pretty much my thoughts as of yesterday evening, so i opted for "second best tomorrow". however, with nmh not (yet) having any long-running daemons i think leaving the memory freeing (of 16 bytes) to the OS is more a minor blemish than a big leak issue. regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ RedHat Adventure: "You're in a maze of twisted little packages, all dependent. There's a threatening little Gnome in the room with you." -- Peter Dalgaard signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Third release candidate for nmh 1.6 now available
On Sun, 08 Jun 2014 10:08:12 -0400, Ken Hornstein writes:
>I am hoping that this release will be good enough to be the basis of
>the 1.6 final release, so I would encourage everyone to download it
>and try it out.
i've just packaged and uploaded the debian build of this version, and
things look pretty good.
as expected there are a few small debian differences (e.g. all manpages to
go in as whatever.1mh instead of whatever.1); besides that
there are two patches that i think might be interesting for upstream:
1. the automatic debian build daemons and build environments are very
stripped down, without guarantees wrt. particular locales being configured.
it makes no sense to attempt the tests that only work if en_US.UTF-8 is
available, so i've made the affected tests check that and skip if
necessary.
2. in my experience the fake smtpd doesn't always start up fast enough for
the subsequent send invocation, so i've adjusted that test to
wait and retry a few times if required.
regards
az
Author: Alexander Zangerl
Subject: fakesmtp test tool doesn't always start fast enough
--- a/test/post/test-post-common.sh
+++ b/test/post/test-post-common.sh
@@ -29,7 +29,17 @@ echo "clientname: nosuchhost.example.com
test_post ()
{ pid=`"${MH_OBJ_DIR}/test/fakesmtp" "$1" $localport`
-run_prog send -draft -server 127.0.0.1 -port $localport $3 || exit 1
+# The server doesn't always come up fast enough, so sleep and
+# retry a few times if it fails...
+status=1
+for i in 0 1 2 3 4 5 6 7 8 9; do
+if run_prog send -draft -server 127.0.0.1 -port $localport $3 ; then
+status=0
+ break
+fi
+ sleep 1
+done
+[ $status -eq 0 ] || exit 1
#
# It's hard to calculate the exact Date: header post is going to
Description: skip locale-dependent tests if no suitable locale present
Author: Alexander Zangerl
--- a/test/dist/test-dist
+++ b/test/dist/test-dist
@@ -16,6 +16,10 @@ fi
setup_test
+if ! locale -a | grep -iq en_us.utf; then
+test_skip "no suitable locale available"
+fi
+
expected=$MH_TEST_DIR/$$.expected
expected_err=$MH_TEST_DIR/$$.expected_err
actual=$MH_TEST_DIR/$$.actual
--- a/test/mhbuild/test-attach
+++ b/test/mhbuild/test-attach
@@ -14,6 +14,9 @@ fi
setup_test
+if ! locale -a | grep -iq en_us.utf; then
+test_skip "no suitable locale available"
+fi
LC_ALL=en_US.UTF-8; export LC_ALL
draft="$MH_TEST_DIR/$$.draft"
--- a/test/mhbuild/test-cte
+++ b/test/mhbuild/test-cte
@@ -16,6 +16,9 @@ setup_test
set -e
+if ! locale -a | grep -iq en_us.utf; then
+test_skip "no suitable locale available"
+fi
LC_ALL=en_US.UTF-8; export LC_ALL
draft="$MH_TEST_DIR/$$.draft"
--- a/test/mhbuild/test-ext-params
+++ b/test/mhbuild/test-ext-params
@@ -14,6 +14,9 @@ fi
setup_test
+if ! locale -a | grep -iq en_us.utf; then
+test_skip "no suitable locale available"
+fi
LC_ALL=en_US.UTF-8; export LC_ALL
draft="$MH_TEST_DIR/$$.draft"
--- a/test/mhbuild/test-header-encode
+++ b/test/mhbuild/test-header-encode
@@ -22,6 +22,9 @@ backupname="${MH_TEST_DIR}/`mhparam sbac
# We're going to hardcode UTF-8 for this test.
#
+if ! locale -a | grep -iq en_us.utf; then
+test_skip "no suitable locale available"
+fi
LC_ALL=en_US.UTF-8; export LC_ALL
#
--- a/test/mhfixmsg/test-mhfixmsg
+++ b/test/mhfixmsg/test-mhfixmsg
@@ -20,6 +20,9 @@ actual="$MH_TEST_DIR/test-mhfixmsg$$.act
actual_err="$MH_TEST_DIR/test-mhfixmsg$$.actual_err"
Make sure that html-to-text conversion is what we expect.
+if ! locale -a | grep -iq en_us.utf; then
+test_skip "no suitable locale available"
+fi
LC_ALL=en_US.UTF-8; export LC_ALL
if grep mhfixmsg-format-text/html "${MH_TEST_DIR}/Mail/mhn.defaults" \
--- a/test/mhlist/test-ext-params
+++ b/test/mhlist/test-ext-params
@@ -18,6 +18,10 @@ setup_test
expected=$MH_TEST_DIR/$$.expected
actual=$MH_TEST_DIR/$$.actual
+
+if ! locale -a | grep -iq en_us.utf; then
+test_skip "no suitable locale available"
+fi
LC_ALL=en_US.UTF-8; export LC_ALL
#
--- a/test/mhshow/test-textcharset
+++ b/test/mhshow/test-textcharset
@@ -20,6 +20,9 @@ if test "$ICONV_ENABLED" -eq 0; then
test_skip 'test-textcharset requires that nmh have been built with iconv'
fi
+if ! locale -a | grep -iq en_us.utf; then
+test_skip "no suitable locale available"
+fi
LC_ALL=en_US.UTF-8; export LC_ALL
expected="$MH_TEST_DIR"/$$.expected
--- a/test/pick/test-pick
+++ b/test/pick/test-pick
@@ -16,6 +16,10 @@ fi
setup_test
+if ! locale -a | grep -iq en_us.utf; then
+test_skip "no suitable locale available"
+fi
+
expected=$MH_TEST_DIR/$$.expected
actual=$MH_TEST_DIR/$$.actual
--- a/test/scan/test-scan-multibyte
+++ b/test/scan/test-scan-multibyt
Re: [Nmh-workers] Third release candidate for nmh 1.6 now available
On Wed, 11 Jun 2014 14:12:26 +0100, Ralph Corderoy writes: >Hi Alexander, > >> e.g. all manpages to go in as whatever.1mh instead of whatever.1 > >OOI, why's that? And is that a recentish change on Debian as this old >Ubuntu doesn't do that. Does that mean co(1) is co.1rcs, etc. too? it's required as per the filesystem hierarchy standard (<https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html>, just look for the string mh) and necessary because there is an unrelated program /usr/bin/scan whose manpage clearly clashes with the nmh one. <http://bugs.debian.org/694814> regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ "I am truly free only when all human beings, men and women, are equally free." -- Mikhail Bakunin signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] wishlist item for 1.7: better configurability for smtp port
mts.conf lets one select which smtp server(s) to use for mail submission, but there's no convenient way of selecting port 587 instead of 25. it would be great if one could set the port with the server entry, e.g. servers: this.one:587 regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ I am Dyslexia of Borg. Prepare to have your arse laminated. signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] modernizing smtp message submission
On Thu, 03 Jul 2014 21:44:38 -0700, Lyndon Nerenberg writes: >> I didn't think that 587 requires AUTH; > >It does. That's its entire point. (Read the RFC.) that's not quite correct. https://tools.ietf.org/html/rfc6409 4.3. Require Authentication The MSA MUST, by default, issue an error response to the MAIL command if the session has not been authenticated using [SMTP-AUTH], unless it has already independently established authentication or authorization (such as being within a protected subnetwork). so, accepting mail on 587 from localhost without smtp auth is fine, localhost being classifiable as 'protected subnetwork'. sendmail allows that automatically, for example. regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ I keep six honest serving-men - (They taught me all I knew); Their names are What and Why and When - And How and Where and Who -- Kipling signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] big-endian build slaves
On Mon, 28 Jul 2014 18:11:59 -0700, Lyndon Nerenberg writes: >Do any of you have gear with the one true (:-)) byte order we could add to the >build cluster? E.g. a pair of 32/64-bit Sparc boxes would be great. Or PPC. >Or even MIPS-BE if anyone keeps that sort of thing running these days. i can't quite offer a build slave at the moment, only some related info: the debian build daemon network includes a bunch of big-endian archs: powerpc, sparc, s390x and mips. every nmh build for debian (that i prep & upload) must first auto-build on all of those & survive the testsuite before it can enter debian. status and logs are here: https://buildd.debian.org/status/package.php?p=nmh regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ "Any sufficiently advanced political correctness is indistinguishable from irony." -- Erik Naggum signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] PGP support
On Sun, 09 Nov 2014 12:43:40 -0500, Ken Hornstein writes: >It would be helpful if regular users of PGP could let us know what >kind of messages they get, and they want to send. A single text/plain >with just ASCII-armoured PGP data? The old application/pgp MIME >type? Or the more standards-based multipart/encrypted with the >application/pgp-encrypted type? only multipart/signed or /encrypted are of real relevance today. both application/pgp and embedded signatures are dead and long buried, and enigmail is the only major perpetrator of borkenness in that area. regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ A successful sysadmin must accept no limits on his laziness. -- Peter da Silva signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Default setup broken on Debian?
On Mon, 02 Mar 2015 17:51:22 +, Conrad Hughes writes: >Debian's version sends >everything (although sometimes there's no-such-file, causing >failures) to GUI helper applications, which feels like something of >a regression vs 1.5 behaviour. debian's exmh uses run-mailcap, which is the only thing we can depend on to be available. after all not everybody has (or wants) lynx installed, or libreoffice or . i'd say the clean debianish solution for delegating mime types to specific apps would be to configure /etc/mailcap and/or /etc/mailcap.order, so that the run-mailcap mime handler learns of your preferences. the nmh way would be to prime your mh_profile with your personal mhshow-mimetype/subtype entries for mhshow, and/or massaging /etc/mhn.defaults. the only difference between upstream's mhn.defaults and the one shipped with debian's nmh are the 4+6 lines for mime types application/postscript, /msword, /pdf, image/* (upstream and too specific) vs the generic application/*, audio/*, image/*, video/*, message/* and text/* (debian). i guess i might add a specific entry for text/plain to make show "fall back" to the default %l+moreproc, to divert/refine the generic text/* entry (which we need for text/richtext). regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ Buchen sollst du suchen, Bei den Eiben kannst du speiben. -- Gunkl signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Default setup broken on Debian?
On Wed, 04 Mar 2015 00:42:44 -0500, Ken Hornstein writes: > >I can understand that, but from what we've seen it looks like >run-mailcap simply is non-functional with base nmh (Conrad said it >didn't work; a lot of cases of "file not found"). hmm, as far as i'm aware debian's mime-support (and its run-mailcap component) is very well primed from the get-go, but that's between conrad, me and the other debian maintainers. >>debian's exmh uses run-mailcap, which is the only thing we can depend on ... > And I was actually >under the impression that exmh used mailcap directly, yes, sorry, that was a typo - i meant nmh. (i'm maintaining both nmh and exmh and the brain must have suffered a small jolt...) anyway, i think this is resolved; i've briefly discussed this with conrad off-list and amended the mhn.defaults that debian's nmh ships (plus more visible documentation of what the differences between upstream and debian are). i've also asked conrad to prod me (well, whoever is the debian maintainer of something) a bit earlier in the future: it's a pity that he misliked the defaults for so long without a peep, and this could have been resolved much sooner. you guys naturally aren't in any way responsible for the (relatively small) mods that were needed to make nmh fit in with debian, and it's an integral part of being a debian maintainer to be the first point of contact when users experience problems with your packages. so here's my thanks to everybody on the list for not being offended when being bothered with debian-specific issues :-) regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ Competely pointless fact of the day: One of my rats is called Solaris, due to the fact it's fat and bloated. The other is called Perl. It's a nervous insane little animal. -- Ashley Penney signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] small patch for test/inc/test-deb359167
a debian user reported that valgrind errors out on this particular test
(<http://bugs.debian.org/779947>); the root cause is not anything in nmh
but rather fakeroot, which is the standard build and
test environment for debian packages.
however, that particular test totally ignores the shipped test/valgrind.supp.
i'd appreciate it if somebody with git commit rights would add the following
one-liner to make the test honor valgrind.supp:
---patch---
--- a/test/inc/test-deb359167
+++ b/test/inc/test-deb359167
@@ -36,4 +36,4 @@ fi
chmod 755 ${MH_INST_DIR}${bindir}/inc
-valgrind --error-exitcode=1 --quiet inc -silent -file "$TESTMBOX"
+valgrind --error-exitcode=1 --quiet
--suppressions="$MH_OBJ_DIR/test/valgrind.supp" inc -silent -file "$TESTMBOX"
---patch---
for completeness' sake here is the debian/fakeroot-specific addition to
test/valgrind.supp:
---patch---
--- a/test/valgrind.supp
+++ b/test/valgrind.supp
@@ -15,3 +15,20 @@
fun:*sendmsg*
fun:readline
}
+
+{
+ Syscall param msgsnd(msgp->mtext) points to uninitialised byte(s) [under
fakeroot]
+ Memcheck:Param
+ msgsnd(msgp->mtext)
+ ...
+ obj:*libfakeroot*.so
+}
+
+{
+ Syscall param stat(file_name) points to uninitialised byte(s) [under fakeroot]
+ Memcheck:Param
+ stat(file_name)
+ ...
+ obj:*libfakeroot*.so
+}
+
---patch---
regards,
az
--
Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/
[Unix] is not necessarily evil, like OS/2. - Peter Norton
signature.asc
Description: Digital Signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Sharing MH files across computers
On Thu, 01 Sep 2016 19:49:41 +, Thomas Levine writes: >Are there any very good ways of using mail between two computers? maybe not 'very good' but 'works for me': a few years ago i programmed a more or less mh-specific bidirectional sync tool (in perl, uses ssh and sshfs, gpl). my primary use case is having both lapdog and main desktop get inbound email, and me sending from either device. every few days mhsync brings them back into sync. it hasn't eaten or lost any emails in 5+ years of use, but certainly could be improved on (e.g. it's not very smart about sequences). it's available here: http://snafu.priv.at/mystuff/mhsync.html regards az -- Alexander Zangerl + GPG Key 0xB963BD5F + http://snafu.priv.at/ Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
On Fri, 23 Sep 2016 22:16:36 -0400, Ken Hornstein writes: >At this point, I'd like to put out a call; if there are any features or >bugs you'd like fixed in 1.7, now is the time to speak up. i've got one outstanding item: the debian ssl people have reported that nmh doesn't build with the newest openssl 1.1.0; apparently the api has changed a bit. further info here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828455 regards az -- Alexander Zangerl + GPG Key 0xB963BD5F + http://snafu.priv.at/ "Bush, Ashcroft, Rumsfeld: The Axis of Idiocy". (somewhere on IRC) signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Cutting a new exmh release...
On Fri, 21 Apr 2017 11:26:51 -0400, valdis.kletni...@vt.edu writes: >1) Would anybody complain if a new Exmh release >said "You must have nmh 1.7"? i don't think this will cause any issues, make it so. >2) Is anybody sitting on patches and/or important wish list items >that aren't in the Sourceforge CVS tree? not me, i pushed some gpg-related stuff a few weeks ago. (btw, does sf do git? cvs is getting a bit painful.) >3) Does anybody remember how to do a release? to me it looks like adjust makefile, adjust version.sed, make version, make srctar. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ if God really existed, it would be necessary to abolish him. -- Mikhail Bakunin signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Call for testing of nmh 1.7 release candidate 3
On Fri, 25 Aug 2017 19:35:38 -0400, Ken Hornstein writes: >>tar -zxvf nmh-1.7-RC3.tar.gz >>cd nmh-1.7-RC3 >>./configure >>make i'm trying to test a build from git, but all branches that i looked at seem to be missing sbr/sigmsg.awk, without which sbr/sigmsg.h cannot be built. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ How do I set my LaserPrinter to "Stun"?! signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Call for testing of nmh 1.7 release candidate 3
On Fri, 25 Aug 2017 21:26:55 -0400, Ken Hornstein writes: >We got rid of sbr/sigmsg.awk when we got rid of the code that used >sbr/sigmsg.h; I think you're getting bitten by stale dependencies. Try *lightbulb*. i had forgotten to autoreconf, so makefile.in had the stale stuff in it... sorry for the noise. one autoreconf later and now branch master builds fine on debian 8, and the testsuite runs through fine. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "Wenn ein Bürger glaubt, dass ein Terrorist ihm gefährlicher wird als ein autoritärer Staat, dann war die ganze politische Bildung für die Katz." -- Ilija Trojanow signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] The State of exmh.
On Tue, 06 Nov 2018 14:02:48 +, Ralph Corderoy writes: >Where does one go for exmh these days? Google's top hit is >http://exmh.sourceforge.net/ and that's the right place for uptodate sources. >and that says the current web site is >http://www.beedub.com/exmh/. i'll get in touch with brent welch about updating that version and link on his site. >I considered poking around >https://www.redhat.com/mailman/listinfo/exmh-users for signs of life, >but those archives are subscriber only. exmh-workers and exmh-users are very low volume lists, but worth subscribing to. >I found a probable public copy >at https://marc.info/?l=exmh-users&r=1&w=2 and see valdis is active. and so am i (the debian maintainer of both exmh and nmh). >The 2.7.2 I found suggests running a wish script to install. >That doesn't appeal without reading through and understanding it first. :-) that's been the way exmh tunes and adjusts things before installation for decades. it's not awesome. >Debian has a dozen patches to apply, and a semi-hand-crafted >/etc/exmh.conf to avoid running the install program. I'm thinking of >following its >https://sources.debian.org/src/exmh/1:2.8.0-7/debian/rules/ to manually >install here on Arch Linux. the main reason why debian has debian-specific patches is that the debian policy requires particular behaviours wrt. where files may go and so on. some are just patches for things that have been fixed in cvs/git since 2.8.0 went out. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Happiness is the maximum agreement between reality and desire. -- Joseph Stalin signature.asc Description: Digital Signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] The State of exmh.
On Thu, 08 Nov 2018 17:53:28 +, Ralph Corderoy writes: >Reading through the notes, it appears metamail is pretty vital for >display of MIME messages. it's not required anymore; i added support for recode instead of metamail in commit 2bf11b0704 in 2008. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Duct tape is like the force. It has a light side, and a dark side, and it holds the universe together... -- Carl Zwanzig signature.asc Description: Digital Signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
[nmh-workers] nmh 1.7.1: both bcc and dcc broken for mts sendmail/pipe
i've just raised bug https://savannah.nongnu.org/bugs/?55700 and i'm working on a fix for this for debian. however, the best way forward isn't totally clear to me, hence this email. the issues that i'm trying to find good solutions for: 1. with sendmail/pipe the headers of what we pass to the mta must make sense for message routing, but the warning-encrusted modified draft baked for bccfil doesn't work because it has no to: and no bcc: headers, so the mta rejects that as unroutable. the original message that post also submits to the mta is left with bcc intact (and thus the mta does deliver it to the blind recipients), which duplicates the (currently nonfunctional) warning-encrusted message. so, in order to make bcc: be both blind and warning-encrusted as per the documentation we'd have to modify the original draft and nuke its bcc: header, and add a bcc: header to the bccfil draft. the patch that i've already attached to the bug report doesn't go that far, it makes bcc with sendmail/pipe work like dcc elsewhere. (it also doesn't contain any documentation updates.) my question: is that good enough? or should we aim for bcc working exactly the same regardless of mts? 2. the docs say dcc isn't supported for sendmail/pipe, which is ok. however, that fact is not overly visibly documented, which is slightly bad. what's quite bad in my opinion is that post with sendmail/pipe leaves the dcc: header in place and so that leaks to the actual recipients (and doesn't cause any message to be sent to the dcc: recipients). my question: wouldn't it be best if dcc in the sendmail/pipe case was handled by simply replacing the header with bcc: and letting the mta do its job? or should post with sendmail/pipe reject messages with dcc? regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ bash: syntax error near unexpected token `=:)' signature.asc Description: Digital Signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh 1.7.1: both bcc and dcc broken for mts sendmail/pipe
On Tue, 12 Feb 2019 09:57:49 -0500, Ken Hornstein writes: >And it strikes me as a bad idea to have Bcc behave >differently depending on the MTS you are using. So I think when >stripping Bcc out of the original draft and putting it IN the Bcc draft >makes the most sense. very good, we're thinking along the same lines here. >Well ... where should this be documented better? what i meant was that the send manpage for example just says 'if you have dcc and anything but sendmail/pipe then...' but doesn't say what happens when you're on pipe. it's similar regarding that bcc is meant to produce those warning encrustations; not having used non-silent bcc in decades i couldn't figure that out fully from the manpages, but had to look at the source. >Really, if you have some suggestions I would >be glad to make them; I don't want to shove this on you, especially if >you are contributing a bug fix. no problem, i'll try to update the send and post manpages where applicable. >I firmly believe that post should reject the message immediately and nothing >should be sent. thanks for your advice; i'll work towards these in the next few days and will let you know when i have something workable. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Windows95 is a 32-bit extension to a 16-bit shell of an 8-bit OS originally written for a 4-bit microprocessor by a 2-bit company that can't stand 1-bit of competition. signature.asc Description: Digital Signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh 1.7.1: both bcc and dcc broken for mts sendmail/pipe
On Tue, 12 Feb 2019 09:57:49 -0500, Ken Hornstein writes:
>So I think when
>stripping Bcc out of the original draft and putting it IN the Bcc draft
>makes the most sense.
done. patch is attached.
>>or should post with sendmail/pipe reject messages with dcc?
>I firmly believe that post should reject the message immediately and nothing
>should be sent.
also done.
i've updated the post and send manpages a little; they now both
spell out the bcc/dcc situation more or less the same way and do mention
the dcc rejection aspect.
regards
az
Description: fix bcc/dcc handling for mts sendmail/pipe
patch makes bcc behave the same regardless of mts config,
and messages with dcc are now rejected with mts sendmail/pipe.
manpages for send and post slightly updated and clarified.
Author: Alexander Zangerl
Bug: https://bugs.debian.org/921244
Bug: https://savannah.nongnu.org/bugs/?55700
--- a/uip/post.c
+++ b/uip/post.c
@@ -848,6 +848,12 @@ putfmt (char *name, char *str, int *eai,
badmsg++;
return;
}
+if (hdr->flags & HDCC && sm_mts == MTS_SENDMAIL_PIPE)
+{
+ inform("Dcc header is not supported with sendmail/pipe");
+ badmsg++;
+ return;
+}
msgflags |= (hdr->set & ~(MVIS | MINV));
if (hdr->flags & HSUB)
@@ -1242,8 +1248,7 @@ putadr (char *name, char *aka, struct ma
if (mp->m_mbox == NULL || ((flags & HTRY) && !insert (mp)))
return 0;
-if (sm_mts != MTS_SENDMAIL_PIPE &&
-((flags & (HBCC | HDCC | HEFM)) || mp->m_ingrp))
+if ((flags & (HBCC | HDCC | HEFM)) || mp->m_ingrp)
return 1;
if (!nameoutput) {
@@ -1475,7 +1480,33 @@ make_bcc_file (int dashstuff)
fprintf (out, "Message-ID: %s\n", message_id (tclock, 0));
if (subject)
fprintf (out, "Subject: %s", subject);
-fprintf (out, "BCC:\n");
+
+/* for sendmail/pipe, insert all bcc recipients here so that the email can be routed based on the bcc: header */
+if (sm_mts == MTS_SENDMAIL_PIPE)
+{
+ char *allbcc = NULL;
+ struct mailname *lp;
+
+ for (lp = localaddrs.m_next; lp; lp = lp->m_next)
+ if (lp->m_bcc)
+ allbcc = allbcc? add(concat(", ", lp->m_mbox, NULL), allbcc)
+ : mh_xstrdup(lp->m_mbox);
+ for (lp = netaddrs.m_next; lp; lp = lp->m_next)
+ if (lp->m_bcc)
+ allbcc = allbcc? add(
+ concat(", ", lp->m_mbox, "@", lp->m_host, NULL),
+ allbcc)
+ : concat(lp->m_mbox, "@", lp->m_host, NULL);
+ if (allbcc)
+ {
+ fprintf (out, "BCC: %s\n",allbcc);
+ free(allbcc);
+ }
+}
+else
+{
+ fprintf (out, "BCC:\n");
+}
/*
* Use MIME encapsulation for Bcc messages
--- a/man/post.man
+++ b/man/post.man
@@ -89,9 +89,12 @@ components that contain addresses.
.PP
If a \*(lqBcc:\*(rq field is encountered, its addresses will be used for
delivery, and the \*(lqBcc:\*(rq field will be removed from the message
-sent to sighted recipients. The blind recipients will receive an entirely
-new message with a minimal set of headers. Included in the body of the
-message will be a copy of the message sent to the sighted recipients.
+sent to sighted recipients. The blind recipients will receive an entirely
+new message with a minimal set of headers. The body of this new message
+will contain a copy of the message sent to the sighted recipients, either
+marked up with the indicator text "Blind-Carbon-Copy" or encapsulated
+as a MIME digest.
+.PP
If
.B \-filter
.I filterfile
@@ -104,6 +107,28 @@ switch is given, then
.B post
will use the MIME rules for encapsulation.
.PP
+If a \*(lqDcc:\*(rq field is encountered and the
+.B sendmail/pipe
+mail transport method is not in use, its addresses will be used for
+delivery, and the \*(lqDcc:\*(rq field will be removed from the message. The
+blind recipients will receive exactly the same message as the sighted
+recipients. *WARNING* Recipients listed in the \*(lqDcc:\*(rq field receive no
+explicit indication that they have received a \*(lqblind copy\*(rq.
+This can cause blind recipients to
+inadvertently reply to all of the sighted recipients of the
+original message, revealing that they received a blind copy.
+On the other hand, since a normal reply to a message sent
+via a \*(lqBcc:\*(rq field
+will generate a reply only to the sender of the original message,
+it takes extra effort in most mailers to reply to the included
+message, and so would usually only be done deliberately, rather
+than by accident.
+.PP
+.B post
+rejects all messages that contain a \*(lqDcc:\*(rq field if the
+.B sendmail/pipe
+mail transport method is used.
+.PP
The
.B \-alias
.I aliasfile
--- a/man/send.man
+++ b/man/send.man
@@ -257,14 +257,16 @@ will abort with a
If a \*(lqBcc:\*(rq field is encountered, its addresses will be used fo
Re: [nmh-workers] nmh 1.7.1: both bcc and dcc broken for mts sendmail/pipe
On Thu, 14 Feb 2019 17:30:28 +, Ralph Corderoy writes: >In particular, the end of a >sentence must be followed by two spaces to indicate to the formatter >that it is indeed the end of a sentence and not a word following an >abbreviation or something else that happens to end in a full stop. thanks, i wasn't aware of that particular *roff quirk. sorry about missing the doublequotes. >Though, reading on, I realise that you copied how it was already done >elsewhere. yes, i aimed for a minimum delta. >I'd be tempted to make it an if-then with no else clause by hoisting the >"BCC:" prefix and "\n" suffix outside of the if-then. hmm. i see your point, but don't entirely agree. my aim here was to contain all the related logic within the smallest possible/sensible horizon. apart from the small ugliness of having the string "bcc:" hardcoded twice i prefer that 'if' block doing its thing (and all of its thing!) over strings conditionally accumulating across a pageful of code or more. >(It canbe "foo, bar, " instead but then the end of the string needs finding to >shorten it by two.) ... >I think this would remove the ternary operators and >duplicated terms like `lp->m_mbox, "@", lp->m_host, NULL' so the reader >has less to parse and check they're the same. true, but again i beg to differ; i find parsing string retrofiddlery like that shortening after lazily accumulating them earlier quite a bit less clean than one ternary. anyway, these are my personal preferences; i hope we can agree to disagree and that somebody with commit rights will apply the patch or equivalent to the code. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ >We're talking about a bleeding mainframe, mate. It's got hemoglobin in its fluorinert? -- Peter da Silva and AdB signature.asc Description: Digital Signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Additional features for S/MIME support
On Sat, 28 Sep 2019 19:52:58 -0400, Ken Hornstein writes: >I was looking at what kind of things we need to generate S/MIME >messages, and ... well, we're like 60% of the way there (by that I mean >60% of the TOOLS you need are there; if possible please keep that part generic enough to also work for pgp/mime (https://tools.ietf.org/html/rfc3156). i strongly suspect that there's fewer hoops to jump through for pgp/mime than for s/mime, so supporting both shouldn't be onerous. >other tools would generate the CMS data). ... >All of these seem like they are extra stuff that should be added to mhstore. i'm not entirely sure how you envision that split between nmh and 'other tools' to work, because you mention both generating s/mime messages and mhstore at the same time. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ If you can't build it with 2N3055's, it's not worth building. -- Peter Gutmann signature.asc Description: Digital Signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Additional features for S/MIME support
On Sat, 28 Sep 2019 21:24:00 -0400, Ken Hornstein writes:
>Oh, there is one additional
>bit of tooling I think is necessary: being able to specify the "raw" contents
>of a multipart part when CREATING a message.
yes.
># This is a hypothetical syntax for including "pre-formed" multipart content
>echo '#!<' >> /tmp/newdraft.$$
>cat /tmp/body.$$ >> /tmp/newdraft.$$
>echo "#application/pkcs7-signature; name=smime.p7s {attachment;
>filename=smime.p7s} /tmp/signdata.$$" >> /tmp/newdraft.$$
>echo "#end" >> /tmp/newdraft.$$
i think telling mhbuild to ignore directives for pre-formed stuff will need
need both 'start verbatim here'
and 'stop verbatim here' markers, or you won't be able to attach the crypto
signature or end the outermost
multipart... maybe something like shell here document delimiters?
>Does that make sense?
thanks, yes, that clarifies things.
>What you would do with PGP/GPG is pretty close to that, I think.
the mime types are different but that's pretty much it. (i feel confident
claiming that because
i wrote an outgoing automatic signer-or-encrypter for pgp/mime a while ago; see
http://snafu.priv.at/mystuff/kuvert/ for details)
regards
az
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Commercial televsion is like deliberately sticking hat pins through your
frontal lobes most of the time. -- Rebecca Ore
signature.asc
Description: Digital Signature
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh sourcesfile:///home/norm/Desktop/repl.desktop
On Fri, 18 Oct 2019 13:01:10 -0700, n...@dad.org writes:
>But I don't know with what value for --prefix it was configured. Does
>anybody know?
looks like ubuntu is reusing debian packages of nmh, and i'm the maintainer
of that. nmh in debian (and thus ubuntu) is configured to meat the debian
policy wrt. file locations, ie. with a configure invocation of
--prefix= \
--bindir='$${prefix}/usr/bin/mh' \
---sysconfdir='$${prefix}/etc' \
--libdir='$${prefix}/usr/lib' \
--mandir='$${prefix}/usr/share/man' \
--docdir='$${prefix}/usr/share/doc/nmh' \
--libexecdir='$${prefix}/usr/lib/mh' \
--with-tls \
--with-mts=sendmail/pipe \
--with-cyrus-sasl \
--with-oauth
regards
az
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, Debian Hardening:
Rigor Mortis. -- Felix von Leitner
signature.asc
Description: Digital Signature
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] sendmail/pipe default config?
On Sat, 19 Oct 2019 12:20:11 -0400, David Levine writes:
>> ---sysconfdir='$${prefix}/etc' \
>I assume that 3 dashes there is a typo.
indeed, cut and paste issue.
>> --with-mts=sendmail/pipe \
>
>Is that the best choice for a default configuration?
it's been that way since 2003 when somebody complained about
smtp as default (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152729);
personally i prefer pipe for submission and nobody asked for a different
default yet, hence...
>Re. sendmail/pipe, are these comments in post.c still valid?
>
>/* This won't work with MTS_SENDMAIL_PIPE. */
>verify_all_addresses (1, eai, envelope, oauth_flag, auth_svc);
as far as i can tell yes, because verify_all_addresses uses do_an_address which
uses sm_wadr which talks smtp.
>/* It would be nice to have support to call
> verify_all_addresses with MTS_SENDMAIL_PIPE, but
> that might require running sendmail as root. Note
> that spost didn't verify addresses. */
this idea would also not work for postfix: its sendmail
emulation wrapper does have a '-bv' option, but one which never responds
to the invoking process (like real sendmail does); instead postfix
sends an email report back after verifying each recipient address.
personally i think spending any further effort on verifying addresses for
deliverability on the sending side is wasted because of how little
verification/guarantee it provides (see bugs section in man whom).
regards
az
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
And God spoke: There shall be packets.
And there were packets, and these packets were good, mostly. -- G.S. Granados
signature.asc
Description: Digital Signature
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh sourcesfile:///home/norm/Desktop/repl.desktop
On Wed, 23 Oct 2019 14:44:14 -0700, n...@dad.org writes: >comp: error while loading shared libraries: libreadline.so.6: cannot open >shared object file: No such file or directory > >What I am doing wrong? it looks as if you're not doing anything wrong, at least not at this particular point in time. quick workaround: sudo apt install libreadline6 what's going on? i'm not entirely certain. first hunch: you have ended up with an nmh package which was built by some piece of kit that linked the packages against libreadline but omitted to specify that nmh depends on the libreadline package. this should be near impossible (as the package build automation looks at all the binaries and their shared lib dependencies). the ubuntu packages that i checked (for ubuntu releases 16.x, 18.x, 19.x) were all correct(but see below) in that they didn't link libreadline and didn't depend on that package either. second hunch: your system has a mix of locally built nmh binaries and some stuff from ubuntu. your locally built stuff was built against libreadline, but ubuntu's packages didn't depend on it so its presence is not enforced. if you then cleanup 'unnecessary' packages then libreadline may very well vanish. find /usr -name comp |xargs -n1 dpkg -S should tell you where your comp file(s) came from (well, at least originally; there's no safeguards against scribbling into /usr/bin/mh/ by the root user. regading 'correctly' not including libreadline: that's my oversight, and it will be fixed in the next nmh version. i haven't specified that nmh should build-depend on libreadline, so the default configure flag 'use readline: maybe' won't lead to it being used. this is because the debian autobuilders always create packages from a fresh utterly minimal set of packages. only stuff that a package marks as being required for building (aka build-depend) is installed, then the package is built after which things are cleaned up. (this slightly imperfect package configuration does not, however, explain binaries linked against libreadline included in a package that doesn't depend on libreadline.) regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Chastity: The most unnatural of the sexual perversions. -- Aldous Huxley signature.asc Description: Digital Signature
Re: smtp authentication problem
On Mon, 07 Feb 2022 17:31:16 +, Ralph Corderoy writes: [about install-recommends: false] >I use that option too on APT systems, I expect that's quite common. so do i, liking my systems to be minimally encrusted with 'helpful' extras. >The nmh package in Debian's Testing depends on 'libsasl2-2 >= >2.1.27+dfsg2'. https://packages.debian.org/bookworm/nmh yes, because without that dependency as a minimum none of the sasl-ish access bits will be built in. >Ken, Can nmh make any use of libsasl2-2 without libsasl2-modules also >being installed? i'll look at that a bit later as well, but ken seems to have hit the nail on the head with his 'no'...(the rationale for the actual split into libsasl and the modules package is, well, a bit beyond me.) >If not, then I wonder if nmh should depend on >libsasl2-modules instead of, or as well as, libsasl2-2 as otherwise it's >too easy for Debian users to have a needless installation of libsasl2-2 >which also lures them into thinking all's well.. you've got a good point there; i'll think about it a bit but will likely make that change. >If libsasl2-2 is useful to nmh without libsasl2-modules then perhaps >nmh's package description should mention the extra package which is >required for authentication in this way. if the recommends doesn't get raised to depends, then i'll definitely add that to the next nmh upload. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, HTTP: Hot Tits Transport Pr0nocol. -- Ulrich Schwarz signature.asc Description: Digital Signature
Re: smtp authentication problem
On Mon, 07 Feb 2022 14:27:49 -0500, Ken Hornstein writes: >I suspect the thinking is that since many packages link against cyrus-sasl >but users might not necessarily USE cyrus-sasl (and certainly nmh >falls into that category) you shouldn't install those mechanisms >unless you specifically want to. But then you get into this situation. >I'm not sure what the right answer is. the libsasl2-modules package costs only 260kb on disk (and just one possible extra dependency: libssl). i decided that on a system with email client duties having the modules installed is preferrable to weird, wonderful and hard to diagnose auth failures; the freshly uploaded vesion nmh version 1.7.1-11 therefore depends on libsasl2-modules (and has got the auth= patch). regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ > What should I do ..the machine can't find the program iexplorer.exe... Breathe a sigh of relief. -- Arthur Hagen in no.www signature.asc Description: Digital Signature
Re: new release?
On Tue, 19 Apr 2022 19:18:49 -0700, David Levine writes: >In the meantime, if those who build from the repo could pull and >report the results of "make check", that will help reveal areas >that we need to address. Platforms such as the BSDs and Debian >are blind spots for me. i've pulled master, massaged it a bit with the (few remaining) debian-specific patches, and built it. one test fails: mhical apparently has timezone issues? not sure, no icalendar user, but i'm in gmt +1000. *** /home/az/src/debian/nmh/nmh-1.7.2/test/testdir/test-mhical20684.expected 2022-04-20 17:55:16.187725294 +1000 --- /home/az/src/debian/nmh/nmh-1.7.2/test/testdir/test1.txt2022-04-20 17:55:16.188725276 +1000 *** *** 1,12 Method: REQUEST Organizer: Requester Summary: test request ! At: Mon, 05 Jan 2015 09:00 -0500 ! To: Mon, 05 Jan 2015 09:30 Attendees: Requestee1, Requestee2, Requestee3 Organizer: Requester Summary: test request ! At: Mon, 05 Jan 2015 13:00 -0500 ! To: Mon, 05 Jan 2015 13:45 Attendees: Requestee2, Requestee3 --- 1,12 Method: REQUEST Organizer: Requester Summary: test request ! At: Tue, 06 Jan 2015 00:00 +1000 ! To: Tue, 06 Jan 2015 00:30 Attendees: Requestee1, Requestee2, Requestee3 Organizer: Requester Summary: test request ! At: Tue, 06 Jan 2015 04:00 +1000 ! To: Tue, 06 Jan 2015 04:45 Attendees: Requestee2, Requestee3 ... first named test failure: display of multiple vevent requests in single vcalendar FAIL: test/mhical/test-mhical -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ PHB: "According to M$ Project, your utilization level is 1850%." CS: "You mean I have a load average of 18.5?" -- Charlie Stross signature.asc Description: Digital Signature
Re: new release?
On Wed, 20 Apr 2022 17:29:39 -0700, David Levine writes: >Should any of those debian-specific patches be considered for >upstream? i don't think so; by now the delta is really minimal (i tend to report functional issues upstream anyway, and the most recent difference was the bcc handling which is all in line now). what's left is a few historic compatibility bits (e.g. man pages to go into the mh section) and some minor adjustments to make the debian autobuilders happier (e.g. reproducible build bits). -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Erst wenn der letzte Programmierer eingesperrt und die letzte Idee patentiert ist, werdet ihr merken, dass Anwälte nicht programmieren können. -- Hopi mod Kulf signature.asc Description: Digital Signature
Re: Plans for distribution updates
On Sun, 01 Jan 2023 12:05:58 -0500, Ken Hornstein writes: >- Debian (and anything else that uses .deb files) i'll take care of debian in the next few days. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Fachbegriffe der Informatik, Debian Hardening: Rigor Mortis. -- Felix von Leitner signature.asc Description: Digital Signature
Re: nmh 1.8?
On Mon, 02 Jan 2023 12:23:54 +, Ralph Corderoy writes: >> Is anyone here packaging nmh as part of a .deb file in the process of >> testing? > >Alexander Zangerl is Debian's packager in the past; I'm CC-ing him. ...and i still am, but i was out of town w/o net access over the holidays. i'll package 1.8 within a week or so. >I assume if we grabbed the debian directory, e.g. >https://sources.debian.org/src/nmh/1.7.1-12/debian/, then we could have >a stab at building the .deb on a Debian machine; I have one to hand. generall you would have to grab the *.dsc and the *.debian.tar.xz, besides the actual upstream (= your) tarball. the combo of the above is guaranteed (by debian policy) to create pretty much exactly the deb in the debian distro (except for file signatures). >I've had a look at the Lintian output and fixed a spelling mistake. >It also says debian/control could do with a Homepage definition: >Alexander, it's https://www.nongnu.org/nmh/ > >That README also mentions a quick overview of what's shipping what >version: > >A useful overview of what third parties are shipping which release >is available at https://repology.org/project/nmh/versions with a >quick overview on the Badges tab which shows >https://repology.org/badge/vertical-allrepos/nmh.svg. > sure can do; i'll have a look at those as part of packaging 1.8. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Programming is like sex: One mistake and you're providing support for a lifetime. -- ? signature.asc Description: Digital Signature
Re: nmh 1.8?
On Sun, 15 Jan 2023 13:47:16 -0500, David Levine writes: >Has everyone had a chance to try out nmh 1.8RC1? I'd like to hear of >results from the BSDs, especially. 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.) i'll upload that version to debian unstable later today. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Politicians are like diapers. They should be changed often, and for the same reason. signature.asc Description: Digital Signature
Re: 1.8RC2?
On Sat, 28 Jan 2023 06:17:09 -0800, David Levine writes: >How does 1.8RC2 look? 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) regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ LISP: To call a spade a thpade. signature.asc Description: Digital Signature
Re: 1.8RC2?
On Sun, 29 Jan 2023 11:54:06 -0800, David Levine writes: >Including Stephen Gildea, the Debian maintainer of xlbiff. stephen's already indicated that he'll look into it. https://bugs.debian.org/#1029752 >I hope the issue can be resolved. same here. originally i slightly suspected the 'welcome to nmh' stuff, but that seems well enough guarded against non-interactive use to be the trigger of xlbiff's autopkgtest gotcha. (the welcomes certainly never interfere with my use of exmh or mh-e, but typically surprise me some days later when i happen to run a direct nmh command for the first time since an upgrade...) -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ The problem with the gene pool is that there is no lifeguard. -- BSD fortune Nah, the problem is that it doesn't have enough chlorine. -- Lionel in ASR It also lacks an undertow for the weak ones. -- Joe Creighton in ASR signature.asc Description: Digital Signature
Re: nmh 1.8RC2, xlbiff, and $HOME
On Mon, 30 Jan 2023 10:47:05 -0800, Stephen Gildea writes: >I have investigated the failure of the xlbiff tests with nmh 1.8RC2. >(This is https://bugs.debian.org/1029752) stephen, thanks for that. >In one of the tests, xlbiff sets environment variable HOME to an empty >string and MH to a file containing a custom profile with an absolute Path. >With nmh 1.7.1, this environment works. > >With nmh 1.8RC2, this environment fails with the error message >"environment variable HOME is empty". *lightbulb* that error message comes from set_mypath in sbr/path.c, and the changelog tells me that "Author: Ralph Corderoy Date: Thu May 13 13:46:20 2021 +0100 sbr/path.c: add set_mypath() to factor out repeated code." started to consolidate the various places that figure out a home for mh. however, set_mypath spot doesn't bother with $MH. a quick glance seems to indicate that only context_read in sbr/context_read.c looks at $MH for finding a home, but it does (well attempts) that just a few lines AFTER set_mypath has bailed out on it... i think we need to fix that sequence up a little :-) [handling of relative paths in the profile] >Whatever your decision, the choice should be documented. If you decide >to keep Path relative to HOME, then HOME should be required to be >non-empty if (and only if!) Path is relative. (nmh 1.7.1 used "/", >which seems wrong.) with my nitpicker's hat on: POSIX/SUS says HOME can be depended on. "HOME The system shall initialize this variable at the time of login to be a pathname of the user's home directory. See ." personally i'd say we should rely on posix and insist on not being $HOMEless. for me that would imply relatives should be relative to that, not the profile location. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ `bastard operators from hell' anagrams to `shatterproof armored balls'. -- Cliff Miller signature.asc Description: Digital Signature
Re: nmh 1.8RC2, xlbiff, and $HOME
On Thu, 02 Feb 2023 16:44:05 -0800, David Levine writes:
>Anyways, I'd like to keep the 1.7
>behavior for 1.8 and change it after. Can we agree to that?
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*.
(1.8RC2 will hopefully/likely be part of the upcoming debian
release; the previous release shipped with 1.7.1.)
regards
az
Description: treat set-but-empty $HOME same as unset
upstream code aborts on empty $HOME and falls back to getpw* only on unset $HOME,
which is undesirable (affects xlbiff's testsuite and generally surprises end users).
this patch makes it fall back for both empty and unset $HOME.
Author: Alexander Zangerl
Bug: https://bugs.debian.org/1029752
Last-Update: 2023-02-02
--- a/sbr/path.c
+++ b/sbr/path.c
@@ -38,10 +38,7 @@ void
set_mypath(void)
{
char *var = getenv("HOME");
-if (var) {
-if (!*var)
-die("environment variable HOME is empty");
-
+if (var && *var) {
mypath = mh_xstrdup(var);
return;
}
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
He who joyfully marches to music in rank and file has already earned my
contempt. He has been given a large brain by mistake, since for him the
spinal cord would fully suffice. -- Einstein
signature.asc
Description: Digital Signature
Re: nmh 1.8-1 Ubuntu package for Jammy Jellyfish
On Sun, 01 Oct 2023 00:32:46 +0900, Christophe Prévotaux writes: >Would it be possible to get a package for Ubuntu Jammy Jellyfish which is an >LTS ? not unless ubuntu provides backports, which it doesn't seem to. >I saw there is support for the very latest Ubuntu release ( Mantic >Minotaure) but I wonder why no backport is available for Jammy. i'm the person packaging nmh for debian, from where ubuntu just copies the packages for direct inclusion and use. apparently that process is totally robotic, and there doesn't seem to be any human involvement in curating/managing nmh in ubuntu - i'm certainly not involved, even though the package page lists me as maintainer. you'll have to get in touch with whoever in ubuntu does backports. besides that there's always the option of rebuilding the package yourself; nmh's build-dependencies are easy to satisfiy in just about any linux distro released in the last 10 years. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ In German "invent-a-new-word-where-a-perfectly-good-one-already-exists" is probably a word. -- Peter da Silva signature.asc Description: Digital Signature
Re: nmh is vital to me
On Thu, 30 Nov 2023 11:05:29 -0800, Dan Relles writes: >but inc produces this infernal message. >how to i shut it off? ... >Welcome to nmh version 1.8-RC2 the fastest way to disable this forever is to add Welcome: disable to your .mh_profile. see man mh_profile. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ "The Computer made me do it." -- BSD fortune file signature.asc Description: Digital Signature
Re: nmh is vital to me
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). as to cause, i suspect the version comparison logic has a hiccup parsing the '-RC2' bit. -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ E Pluribus UNIX signature.asc Description: Digital Signature
