Fedora Rawhide just dropped a prerelease of gcc-13
The good news is that I did a 'git pull' of nmh, 'make clean', './configure', 'make'. Zero gcc warnings even with -Wall -Wetra, 'make check' reported all 118 tests passed, and nothing broken that I have noticed... pgpeqmXn58Tso.pgp Description: PGP signature
Re: slocal and relation with rcvstore
On Sun, 13 Mar 2022 21:37:12 +0100, "Thomas Dupond" said:
> If so, what should I use to have all the goodness of filtering and 'unseen'
> behaviour from nmh?
Procmail also knows how to deal with mh-style folders. You can either have it
deliver it directly (which doesn't update sequences), or invoke rcvstore. The
nice thing is that procmail has much more fine-grained matching, searching,
and processing.
So the mail I'm replying to got filtered into the folder by this:
:0 Ew:nmh/$LOCKEXT
*^(To:|cc:).*nmh-workers@nongnu.org
|rcvstore +nmh
While Greg Kroah-Hartman's weekly patch review posts for the various
linux-stable kernel trees get auto-ignored thusly:
:0 E
*^(To:|cc:|X-mailing-list:).*linux-ker...@vger.kernel.org
*^From: Greg Kroah-Hartman
*^Subject: \[PATCH [45].[0-9]
trash/.
(Yes, all 3 regexp have to match. I used 'trash/.' rather than '/dev/null' so
that if it ever false-positived, I'd still be able to fish it out of the trash
folder)
Or even how I invoke 'mhfixmsg' as a filter (at the time, I wasn't sure what
mhfixmsg's interaction with converting parts of a multipart/signed and
potentially breaking a signature, so I didn't invoke it for signed mail)
# Canonify to 8-bit UTF-8
:0
*!^Content-type:.*multipart/signed
{
# Set here rather than earlier so we don't splat out zero-length files for
stuff
# we filed before this, so we didn't fixmsg...
TMPFILE=`mktemp -p /home/valdis/tmp fixmsg.XX`
:0 wf
| tee $TMPFILE | mhfixmsg -noverbose -file - -outfile -
}
And I won't share some of the more bletcherous things I did with procmail to
produce actionable data from Listserv/Sendmail bounce reports (hint - since
every single time that Listserv hands Sendmail a mail and bounces, the
boilerplate in the resulting bounce message is identical so you want to extract
the copy of the bounced mail from inside the multipart/report. Let's see you do
*that* with slocal :)
Re: mhfixmsg character set conversion
On Sun, 06 Feb 2022 09:26:14 -0800, David Levine said: > Ok, commit 41ce4490ac5d might fix the problem for you. The cause > was mismatch between the character set of content generated by the > external program (lynx, in this case) and mhfixmsg -textcharset > UTF-8. mhfixmsg wasn't capturing the charset of the generated > output, assuming it was unchanged. It then converted it again. So I did a 'git pull', and 'git show HEAD' reports: commit 51f9b175b18f4f37ebc7a5135346c7f3433cf100 (HEAD -> master, origin/master, origin/HEAD) Author: David Levine Date: Sun Feb 6 11:37:22 2022 -0500 Fixed charset determination code. Fix to commit 41ce4490ac5d5c6a25240c4101cacefa16d885eb. And I'm seeing 2 failures in 'make check', am attaching the output from 'make check |& tee check.output' as a gzip to avoid any possible charset wonkiness... I also hit a third error, but I *think* it's just 'par' not being installed. I wonder where it went, I'm pretty sure I installed it somewhere along the line. In any case, test-convert's message isn't correct, as the directory /home/valdis/src/nmh/test/testdir/Mail/ doesn't exist, and the file 'draft' is obviously not in the non-existent directory. check.output.gz Description: check.output.gz
Re: Problem sending jar file to Windows user
On Mon, 05 Jul 2021 12:22:55 -0700, n...@dad.org said: > Second: I copied /home/norm/lib/Jar/chart.jar to /tmp/,chart.zip and attached > > This time whatNow accepted an 's'. But then I got the an error Email, which > I am attaching to this message. > Final-Recipient: rfc822; csfuh...@verizon.net > Action: failed > Status: 5.0.0 > Remote-MTA: dns; mx-aol.mail.gm0.yahoodns.net. (67.195.204.75, the server for > the domain verizon.net.) > Diagnostic-Code: smtp; 554 Message not allowed - [299] My first guess is that Verizon doesn't allow sending .zip files to its customers because miscreants send victims stuff that looks like a zip file, but actually contains malware of various flavors If Verizon is lax, renaming the file to ',chart.not-a-zip-at-all' may work. If they actually introspect the contents you'll have to find a way to obfuscate it. Using S/MIME or PGP encryption would probably do the trick, but can be a royal pain to set up if you're not already doing crypto pgplKu8f30SuI.pgp Description: PGP signature
Re: Bug reported regarding Unicode handling in email address
On Sat, 12 Jun 2021 10:04:36 +0100, Ralph Corderoy said: > What sorry excuse for an MUA are you using over there? :-) That would be exmh. > And why doesn't it complain at you when it spots the attempt to send > these transgressions onto the wire? That's a very good question - I *thought* I fixed that, but obviously there's still some unicode/utf-8 confusion. It displayed correctly in Ken's mail, while composing the reply, and in your mail, which is why I didn't notice it was still broken. But wait.. there's more.. The =AF=5C screw-up is in the outbound file. 17:38:01 0 [~] grep "can only say" Mail/outbox/41541 | hx 3E206361 6E206F6E 6C792073 6179203D 41463D35 435F28E3 8384295F 2F3D4146 *> can only say =AF=5C_(...)_/=AF* 0020 2E0A But linemode 'show' displays it correctly as well. Why did *that* work here but you report > it doesn't display correctly here when decoded, e.g. the un-QP'd =AF > isn't valid UTF=8.
Re: Bug reported regarding Unicode handling in email address
On Fri, 11 Jun 2021 14:04:36 -0400, Ken Hornstein said: > character. This obviously works best if your local character set is > UTF-8. I am aware that some people, for reasons I cannot comprehend, > want to run in the "C" locale but PRETEND that their character set > is UTF-8 and this approach does not work for them. To these people I > can only say �\_(ツ)_/�. I discovered that using LANG=en_US.utf8 but LC_COLLATE=C was the proper solution, as /bin/ls then outputs files in the order that God intended, not the creeping bletcherous horror that UTF-8 collation creates. :)
Re: Bug reported regarding Unicode handling in email address
On Wed, 02 Jun 2021 00:13:51 -0400, Ken Hornstein said: > So this bug was reported yesterday: > > https://savannah.nongnu.org/bugs/?60713 > I am wondering if the simplest solution is to put in isascii() in front > of those tests in that function. We only really care about those tests > returning "true" for ASCII characters. Thoughts? It's early morning for me, and I'm still at least a liter of Diet Mountain Dew away from being sufficiently caffeinated to be positive, but that looks like "not totally correct, but a lot closer than what we have now". In particular, that will accept overlong and illegal utf-8 codepoints, and probably misbehaves in strange and unusual non-ascii/non-utf-8 things like iso2022-jp. Personally, I'd just stick the isascii() in there and wait for a bug report regarding the previous paragraph. :) pgpylEu6aGNYk.pgp Description: PGP signature
Re: mhbuild: extraneous information in message
On Wed, 12 May 2021 12:58:23 -0400, Ken Hornstein said: > >> Oh goodness. I had no idea. And here I have been happily editing > >> /etc/mailcap > >> every time somebody sends me something I cannot read, adding a rule about > >> how to > >> read it, and smiling contentedly when nmh starts being able to read it > >> properly. > >> > >> Where should I have been adding such rules, if not there, then? > > > >$HOME/.mailcap > > There's no HARM in you putting entries there. But nmh doesn't read that > file either. Which raises the question - what is getting into the path so when Laura adds entries to /etc/mailcap, things start working for her? pgpVPNP_CepTG.pgp Description: PGP signature
Re: mhbuild: extraneous information in message
On Wed, 12 May 2021 18:16:28 +0200, Laura Creighton said: > Oh goodness. I had no idea. And here I have been happily editing > /etc/mailcap > every time somebody sends me something I cannot read, adding a rule about how > to > read it, and smiling contentedly when nmh starts being able to read it > properly. > > Where should I have been adding such rules, if not there, then? $HOME/.mailcap Among other things, that way your personal entries are safe from operating system upgrades. pgpG9f82fL5jJ.pgp Description: PGP signature
Re: Crash in 'post' after recent commit - patch in next mail...
On Tue, 11 May 2021 17:58:21 -0700, David Levine said: > Valdis wrote: > > > I originally put "patch in next mail" in the subject because the fix to not > > use > > a static char[] seemed obvious. > > I went the other way, so all the other callers of etcpath() wouldn't > have to change: That works too. Did a git pull, make check worked, and if you're seeing this, post isn't crashing. :)
Re: Crash in 'post' after recent commit - patch in next mail...
On Mon, 10 May 2021 04:17:44 -0700, David Levine said: > Valdis wrote: > > > which gives free() indigestion. I suspect Fedora is using a hardened > > malloc() > > that does more sanity checking and that's why it didn't get caught right > > away. > > Or the tests don't cover a path starting with '~'. > > > So obviously a more subtle solution is needed. > > Yeah, I'll work on that. I originally put "patch in next mail" in the subject because the fix to not use a static char[] seemed obvious. Then I actually ran 'make check' and that blew up in a way that was pretty obviously a case of somebody doing something subtly dodgy indeed Good luck. Hopefully chasing down why the "obvious" fix breaks isn't *too* bad.
Crash in 'post' after recent commit - patch in next mail...
Noticed I hadn't updated since Feb, did a git pull, things went poorly.
The gory details:
git bisect says:
[~/src/nmh] git bisect bad
c723593d2af190d9c86062d2a265fceec25fb777 is the first bad commit
commit c723593d2af190d9c86062d2a265fceec25fb777
Author: David Levine
Date: Sun Mar 21 09:31:21 2021 -0400
Added alias expansion to From: address for use by sendfrom.
but I think this is merely exposing a bug in this commit:
commit 85aebdf30129dc779d3164a3ba784215283dac26
Author: David Levine
Date: Sun Mar 21 09:25:34 2021 -0400
Plugged memory leak resulting from etcpath() call.
Trying to send mail says:
What now? send -snoop
free(): invalid pointer
send: message not delivered to anyone
What now?
And gdb says:
Core was generated by `post -library /home/valdis/Mail -nomime -msgid -server
smtp.gmail.com -port 587'.
Program terminated with signal SIGABRT, Aborted.
#0 0x7f023723f292 in raise () from /lib64/libc.so.6
(gdb) where
#0 0x7f023723f292 in raise () from /lib64/libc.so.6
#1 0x7f02372288a4 in abort () from /lib64/libc.so.6
#2 0x7f0237281cd7 in __libc_message () from /lib64/libc.so.6
#3 0x7f023728995c in malloc_printerr () from /lib64/libc.so.6
#4 0x7f023728ad2c in _int_free () from /lib64/libc.so.6
#5 0x7f023728ea58 in free () from /lib64/libc.so.6
#6 0x00408e8d in alias (file=0x439ca0
"/home/valdis/.mh_alias",
file@entry=0x7ffd2d74175c "~/.mh_alias") at uip/aliasbr.c:184
#7 0x0040571a in main (argc=, argv=) at
uip/post.c:388
(gdb) up
#6 0x00408e8d in alias (file=0x439ca0
"/home/valdis/.mh_alias",
file@entry=0x7ffd2d74175c "~/.mh_alias") at uip/aliasbr.c:184
184 if (allocated_file) free (file);
(gdb) info local
i =
bp =
cp =
pp =
lc =
ap = 0x7ffd2d7416ed "/home/valdis/Mail"
ak = 0x0
allocated_file = true
fp = 0x2419d60
The code:
165 alias (char *file)
166 {
167 int i;
168 char *bp, *cp, *pp;
169 char lc, *ap;
170 struct aka *ak = NULL;
171 bool allocated_file = false;
172 FILE *fp;
173
174 if (*file != '/'
175 && !has_prefix(file, "./") && !has_prefix(file, "../")) {
176 file = etcpath (file);
177 allocated_file = true;
178 }
179 if ((fp = fopen (file, "r")) == NULL) {
180 akerrst = file;
181 return AK_NOFILE;
182 }
183
184 if (allocated_file) free (file);
The problem is that if etcpath() is fed ~/some.path, what it returns is a
pointer to:
33 static char epath[PATH_MAX];
which gives free() indigestion. I suspect Fedora is using a hardened malloc()
that does more sanity checking and that's why it didn't get caught right away.
Just making epath an malloc'ed array produces interesting breakage:
PASS: test/whatnow/test-ls
./test/whom/test-whom: "whom -alias nonexistent" expected:
'whom: aliasing error in nonexistent - unable to read 'nonexistent''
but instead got:
'whom: aliasing error in /usr/lo - unable to read '/usr/lo''
first named test failure: -alias with nonexistent aliasfile
FAIL: test/whom/test-whom
So obviously a more subtle solution is needed.
Re: displaying Date using local timezone
On Mon, 03 May 2021 09:30:46 +0100, Ralph Corderoy said: > +0845 Australia/Eucla To quote Casey Schaufler: EGADS - Concept violates the principle of Least Astonishment. And here in North America, we tease Newfoundland for being on the half-hour. pgp55RpIHwHdW.pgp Description: PGP signature
Re: check if message is in a particular sequence?
On Sun, 02 May 2021 19:23:06 +0100, Ralph Corderoy said: > I went for -range because it's controlling the printing as âlo-hiâ and > mh-sequence(5) already says things like > > A message range is specified as âname1-name2â or âname:nâ, where > `name', `name1' and `name2' are message names, and `n' is an > integer. So -range means "make it into a range if possible" and -norange doesn't. I'm sold. :) And yes, being able to say -norange is handy if you're doing something where you're grabbing a range and then feeding it to a shell's "for i in $foo". (Over the decades that's annoyed me - a big reason I don't use mark more is because I'm usually using that to feed something else that doesn't grok "14-19" pgpry30ACwrrf.pgp Description: PGP signature
Re: improved mh-chart man page
On Tue, 23 Mar 2021 16:09:38 -0400, Ken Hornstein said: > We USED to use $(...) in the test suite. But that was dropped because > it turns out that /bin/sh on Solaris does not support that (at least, that > was my memory). I am neutral about whether or not we should continue > to support ancient shells. The question becomes: How many users are (a) on Solaris that old *and* (b) likely to update to nhm 1.7.1? And is there anything we can to do help them migrate off ancient Solaris to semi-this-century Solaris? pgprXews0qd9u.pgp Description: PGP signature
Re: Bogusly RFC2047'd "inline" for Content-Disposition
(Merging replies to two related items) On Sat, 26 Sep 2020 00:14:59 +0100, Conrad Hughes said: > Just saw this for the first time: > > Content-Disposition: =?utf-8?Q?inline?= I can do you one better.. In my folder of broken mail that gives exmh heartburn, I found this one back in 2016: X-Mailer: =?UTF-8?B?dGlwLWdpdC1sb2ctZGFlbW9u?= Robot-ID: =?UTF-8?B?PHRpcC1ib3QuZ2l0Lmtlcm5lbC5vcmc+?= Robot-Unsubscribe: =?UTF-8?B?Q29udGFjdCA8bWFpbHRvOmhwYUBrZXJuZWwub3JnPiB0byBnZXQgYmxhY2tsaXM=?= =?UTF-8?B?dGVkIGZyb20gd Ghlc2UgZW1haWxz?= MIME-Version: =?UTF-8?B?MS4w?= Content-Transfer-Encoding: =?UTF-8?B?OGJpdA==?= Content-Type: =?UTF-8?B?dGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOA==?= Content-Disposition: =?UTF-8?B?aW5saW5l?= Fortunately for all concerned, *that* bot was fixed within a few hours. Unfortunately, it looks like in *this* case, we may be waiting for a while for it to actually be fixed out in the wild - looks like the fix to force the Content-Disposition: tag was merged in Dec 2019, and we're just hearing about the problem now in almost-October 2020. On the other hand, that also tells me that Magento's market share must not be very large if nobody noticed. I've poked the relevant IETF lists about the details on this On Sat, 26 Sep 2020 09:45:20 -0400, David Levine said: > It looks like the problem has been fixed. We could teach mhfixmsg to > fix this, though I'm inclined not to do that unless this turns out to be > a more widespread problem. Given that I've only seen this sort of silliness twice this century, I'd say the risks of adding code to mhfixmsg probably outweigh the need to extend it. And although there's "Be liberal in what you accept", that's not really scalable with stuff that's flat-out broken - especially if it doesn't generate pushback to get the broken stuff fixed. pgp59Gsuf_ZZd.pgp Description: PGP signature
Re: Has anyone looked at JMAP?
On Mon, 31 Aug 2020 20:44:42 -0400, Ken Hornstein said: > >- Paragraph 4.b.1, which states that "You will keep your credentials > >> confidential and make reasonable efforts to prevent and discourage other > >> API Clients from using your credentials. Developer credentials may not be > >> embedded in open source projects." prohibits the use of OAuth credentials > >> in free software projects. As I wrote above (and earlier), Google > >> tolerates (at the moment) that this specific point of their TOS is > >> violated. But that doesn't mean that violating them is without legal > >> risk. > > Oof, fair enough. It does seem unfortunate that the official rules don't > permit OSS projects; I wish there was a way for a user to create their > own custom API key and they could just add that to their account. Honestly, > I am fine with doing what KMail did (since that's what we did before). Oh, it's fairly easy for a user to create their own custom API key for their own instance of fetchmail. What's *not* permitted is for a *project* to ship a tarball or whatever with a key usable by everybody who installs the package. Which of course is actually pretty reasonable - imagine the flamestorm if openssh shipped a public/private keypair that it installed on every machine. pgpEIP4Rkm01d.pgp Description: PGP signature
Re:
On Thu, 02 Jul 2020 21:58:04 +0100, Justice Jvsta said: > I don't know what next to do am stuck with the command Well... it says it can't change to the directory. Investigate why. /data/data/com.termux/files/home/Mail/inbox (Egads. :) Does it exist? Is it the directory you *expect* your inbox to be? (Mine has been located at /home/valdis/Mail/inbox for several decades now, even when /home/valdis was actually a symlink to something like /bigdisk/homedirs/valdis back when Fujitsu Super Eagles were what all the cool kids were using. ;) If it isn't where you expect it to be, what location *did* you expect? Is your home directory /data/data/com.termux/files/home/ ? (Seems odd, I'd expect to see home/jvista/ or similar with a username in there someplace). Do you have a .mh_profile in your home directory? If so, what does: grep Path: ~/.mh_profile return? (Usually, it contains "Path: Mail" so everything nmh lives under ~/Mail/) Is there some squirrelly permission problem? I've seen network file systems say "no such file" even though the *real* problem is a permissions issue several directories up the tree... (Suggestion - if you're using a smartphone for this, rotate it 90 degrees. nmh is not going to provide a very good experience with a 42 row 50 column display, it will do much better if you have 20-30 rows of 80 columns.) pgpYL6ndj2Zpb.pgp Description: PGP signature
Re: multiply linked emails
On Fri, 29 May 2020 14:41:05 -0400, Ken Hornstein said: > > 2) would it be reasonable to have a mh-format that returned the number of > > hard links so that I could see in my scan that it was also stored > > elsewhere? > > That should be relatively straightforward, although it sounds like a bunch > of layer violations to me (not that we really have many layers in nmh, > but we should!). Again, it has limited utility if the filesystem doesn't > support hard links. Well, if the system is Unixoid enough to *have* a stat() system call, and you stat() a file on a file system that doesn't support multiple hard links, it will just set the stat.st_nlink field to 1. And I'm going to make a guess that most nmh users are using a sane filesystem that does have multiple links. The bigger thing will be bulletproofing it for things like the purported file actually being a directory or a symlink or other non-file entity. pgpS7gsbEnZF4.pgp Description: PGP signature
Re: send bcc: wierdness?
On Sun, 12 Apr 2020 18:59:01 +0700, Robert Elz said: > Yes, so both were OK, which means it is OK to transmit the message. > > That needed to be done in two different SMTP transactions, to avoid > revealing the bcc user's address to the other user (nmkh doesn't > know they're both you). But if it already knew that it would need two transactions, why did it bother with the first transaction? Or is the problem that if the first transaction sends 1 bcc note and succeeds, and the second sends 3 successful and one failed, error recovery gets difficult? (Though even if you have no bcc's, and 2 recipients to 1 mx, and 2 recipients to a different mx, and one fails, you still have the same problem...) Or has it been doing a pre-test all along and I've just never caught it at it? :) pgpzvPkYqluRa.pgp Description: PGP signature
Re: send bcc: wierdness?
On Sun, 12 Apr 2020 14:54:31 +0700, Robert Elz said: > That will be do that is one of the addresses is bad (and the receiving > MTA can work that out - which it once would have often done, and sadly these > days, amost never) then the message gets delivered to no-one, rather than Well, the -snoop output was pretty clear that Google's inbound listener on port 587 gave back a 250 OK on both addresses: (tls-encrypted) => MAIL FROM: (tls-decrypted) <= 250 2.1.0 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RSET (tls-decrypted) <= 250 2.1.5 Flushed o16sm4571323qki.110 - gsmtp (tls-encrypted) => MAIL FROM: (It then goes on to correctly send one copy to each destination) So if it was supposed to retry if one address was bad, it's even more broken than we thought pgpb2UD3AalNg.pgp Description: PGP signature
send bcc: wierdness?
So I got a user report that exmh was doing something weird with bcc:. I looked at the exmh code, which doesn't do anything special with bcc:, it just assumes that the underlying nmh will DTRT. So.. I go to test nmh. As tested, it had: From: "Valdis =?utf-8?Q?Kl=c4=93tnieks?=" To: valdis.kletni...@gmail.com bcc: val...@vt.edu Fcc: +outbox Subject: Test of bcc: nmh adsfasdf And I do a 'send -watch -snoop', and the relevant part of the transcript says: (tls-encrypted) => MAIL FROM: (tls-decrypted) <= 250 2.1.0 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RSET (tls-decrypted) <= 250 2.1.5 Flushed o16sm4571323qki.110 - gsmtp (tls-encrypted) => MAIL FROM: (tls-decrypted) <= 250 2.1.0 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => DATA (tls-decrypted) <= 354 Go ahead o16sm4571323qki.110 - gsmtp (tls-encrypted) => . (tls-decrypted) <= 250 2.0.0 OK 1586650839 o16sm4571323qki.110 - gsmtp (tls-encrypted) => RSET (tls-decrypted) <= 250 2.1.5 Flushed o16sm4571323qki.110 - gsmtp (tls-encrypted) => MAIL FROM: (tls-decrypted) <= 250 2.1.0 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => RCPT TO: (tls-decrypted) <= 250 2.1.5 OK o16sm4571323qki.110 - gsmtp (tls-encrypted) => DATA (tls-decrypted) <= 354 Go ahead o16sm4571323qki.110 - gsmtp (tls-encrypted) => . (tls-decrypted) <= 250 2.0.0 OK 1586650840 o16sm4571323qki.110 - gsmtp (tls-encrypted) => QUIT (tls-decrypted) <= 221 2.0.0 closing connection o16sm4571323qki.110 - gsmtp which looks to me like it tried both destinations, got 250 back for them.. ... and then did an RSET and sent as two separate SMTP transactions. which had me going WTF?? (and it of course didn't help my mood that this doesn't match the reported problem behavior, which sounds like 'send' did a 'forw -mime', but the embedded message wasn't recognized as MIME message/822 and all the headers displayed in the body of the message, which of course confused all the non-expert recipients...) pgpSWknsJCcL0.pgp Description: PGP signature
Re: questions about the Previous-Sequence
On Mon, 23 Mar 2020 13:16:56 +0100, Philipp said: > [2020-03-22 14:53] Ken Hornstein > > >We think currently about removing the Previous-Sequence support for > > >mmh. But because we don't use it we are not sure, if we missed some > > >aspect of it. Therefor I would like to ask some questions. > > > > I personally find the previous-sequence rather useful myself (when you > > find, for example, the results of "pick" were rather larger than you > > expected and didn't put it in a sequence). But that's up to you. > > May I ask, why do you prefer it over the history and command line editing? Keep in mind that some of us have been using Unix-style systems since *long* before readline existed, so all the fancy 'command line editing" didn't exist, and before shell history sprouted all its fancy features. So alternatives were invented. And muscle memory is hard to overcome. (Says the guy still using e16 as a window manager rather than Gnome, mostly because of muscle memory type reasons) pgp2NHqBnMtL2.pgp Description: PGP signature
Re: nmh and fdm question
On Tue, 25 Feb 2020 12:26:48 +0700, Robert Elz said: > There was a caret there in the message I saw (0x5e) which perhaps > your font is somehow missing (here it is: ^). Assuming that means Gaak. Totally right. Now I have to delve into two messes. Why my laptop has a font that borked, and why the arcane magic that is fontconfig chose it (or what the the name of the chosen font even *IS*). pgpvtyHXpkqzo.pgp Description: PGP signature
Re: nmh and fdm question
On Mon, 24 Feb 2020 21:10:15 -0500, aalin...@riseup.net said: > This is the raw email From line: > > From: "The New Yorker" > > And this is the line in my ~/.fdm.conf file: > > match "^From:.*@eml.condenast.com" in headers action pipe > "/usr/local/libexec/nmh/rcvstore +trash" > > My question is, why doesn't this work? I'm seeing a wonky square box character between the " and From in that match line, it's probably a control character of some sort that's being included in the match and failing because the actual mail has an F in column 1 rather than a wonky control character. pgpZYSmAYnYqU.pgp Description: PGP signature
Re: Thank you all
On Mon, 16 Dec 2019 07:39:48 -0800, n...@dad.org said: > With Comcast as my Internet Provider, Gmail as my Email server, and nmh as my > Email client, all seems to be well. Thank you so much. Glad it all worked out for you. :) pgpAuDIi0uk1Y.pgp Description: PGP signature
Re: Help with Gmail
On Thu, 05 Dec 2019 21:30:22 -0500, David Levine said: > The description or the semantics? It really did/does use the login > name for the password. I think it's long past time that we remove > that. Gaak. That's so "No Even Wrong" that every time I've read that, I've parsed it as "use the login name to search .netrc for the password". Yes, that should be removed - and if that manages to break anybody's setup, they should be *glad* we broke it to protect them from themselves. pgpxcCjym6ESG.pgp Description: PGP signature
Re: Help with Gmail
On Thu, 05 Dec 2019 15:54:50 +, Ralph Corderoy said: > Hi Ken, > > > Norm, if you create a .netrc file I bet it will work. If you've > > forgotten the format of a .netrc file, you want the file to contain a > > line that looks like this: > > > > machine pop.gmail.com login normanzalmonshap...@gmail.com password foobar What I have in my .mh_profile: send: -nomime -msgid -server smtp.gmail.com -port 587 -tls -sasl -user val...@vt.edu What I have in my .netrc: machine smtp.gmail.com login val...@vt.edu password my-passwd-here And no need for a 'credentials:' line. Note that's sufficient for 'send', and I use fetchmail/procmail rather than inc, 'man inc' says it supports '-user username', so a .mh_profile entry: inc: -tls -sasl -user n...@gmail.com and a .netrc entry: machine pop.gmail.com login n...@gmail.com password norms-passwd-here should work. pgpENcrBHop0N.pgp Description: PGP signature
Re: format and output all received: lines in an e-mail message
On Fri, 22 Nov 2019 20:51:52 +0100, Steffen Nurpmeso said: > I prefer people using Mail-Followup-To: instead of some ML > software modifying the address lists, they could as well just > avoid resending the mail!?! Yes, i mean, well. > I really like looking into old archives and i hope what i see is > the real original thing, which i think is a value by itself. > But the world does not seem to cherish this. A bigger issue is GMail's handling of Message-Id: If you post to a mailing list, it notes the Message-Id: on the way out, and when the list sends its copy to you, it gets silently munched by the duplicate suppressor. So unless you are careful with Fcc: and have nmh save a copy in the appropriate folder, your comments in a thread go poof. pgpGvEg27G0Er.pgp Description: PGP signature
Re: format and output all received: lines in an e-mail message
On Wed, 20 Nov 2019 10:41:34 +0530, Greg Minshall said: > hi. i'd like first, of course, to thank you all for nmh! > > then, i'd like to use something like fmttest(1) to print out all the > "Received:" lines in an e-mail message. ideally, each "Received:" line > would come out on a separate line; less ideally, but i'm sure very > practical, a very long line would come out, with some odd ascii code > separating the individual lines. Well in the "not using mh tools at all" category, if you have procmail installed, you can just use: [~] cat Mail/inbox/1 | formail -c -x Received from localhost (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.6.Beta1/8.12.6.Beta1) with ESMTP id g86N6Pbs020540 for ; Fri, 6 Sep 2002 19:06:25 -0400 from fan.cc.vt.edu [198.82.161.8] by localhost with POP3 (fetchmail-5.9.0)for valdis@localhost (single-drop); Fri, 06 Sep 2002 19:06:25 -0400 (EDT) from dagger.cc.vt.edu ([10.1.1.11]) by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.2001.05.04.11.50.p10) with ESMTP id <0h210069rhg...@gkar.cc.vt.edu> for valdis@sims-ms-daemon; Fri, 6 Sep 2002 19:05:21 -0400 (EDT) from mail01.corp.tellme.com (mail01.corp.tellme.com [209.157.157.98]) by dagger.cc.vt.edu (Mirapoint Messaging Server MOS 3.2.0-GA) with ESMTP id AQM10446; Fri, 06 Sep 2002 19:05:20 -0400 (EDT) from mail01.corp.tellme.com (localhost [127.0.0.1]) by localhost.tellme.com (Postfix) with ESMTP id 1EE5744BDD for ; Fri, 06 Sep 2002 16:05:19 -0700 (PDT) from dhcp157-180.corp.tellme.com (dhcp157-180.corp.tellme.com [209.157.157.180]) by mail01.corp.tellme.com (Postfix) with ESMTP id A6F5444BDA for ; Fri, 06 Sep 2002 16:05:18 -0700 (PDT) (Note that this returns the *values* of the lines, not the line. | sed -e 's/^/Received: /' if that matters to you. pgpfZqsSToygm.pgp Description: PGP signature
Re: 4 of 108 tests failed testing nmh
On Wed, 06 Nov 2019 19:56:45 -0800, "Chris Richmond" said: > Not sure what you need to know, but this is on a current Devuan 2.0.0 > install. This is what failed: That's unusual behavior. Can you tell us where you got the source tree,' and what release of gcc you're using? 4 of 108 tests failed (7 tests were not run) Might be interesting to figure out which 7 weren't run - on my Fedora laptop, all 115 tests run cleanly using gcc 9.2.1. pgpWA8ORI88YH.pgp Description: PGP signature
Re: nmh query
On Sun, 03 Nov 2019 15:08:12 -0500, David Levine said: > And it looks like BCC: has never listed the bcc recipients. This > is from the MH 6.8.5 post.c: > > fprintf (out, "BCC:\n"); That's proper behavior. BCC is *blind* carbon copy, specifically intended to *not* show who else got copies. I'd argue that the only time it's acceptable to list recipients there is if you are feeding to an MSA that's like 'sendmail -t' that needs it to get additional recipients because you can't speak SMTP and hand off RCPT TO:<...> for the Bcc people. And of course, you trust your MTA to then promptly eat that header and not promulgate it any further. I'll go further and assert that if there is still a Bcc: header in the RFC822 headers once the MSA has accepted the mail for further processing, that somebody has dropped the ball because sometimes, even a Bcc: that shows that there *were* other recipients may be an unacceptable information leak pgpw8DkFlpVvb.pgp Description: PGP signature
Re: [nmh-workers] sendmail/pipe default config?
On Sun, 20 Oct 2019 12:11:03 +1000, Alexander Zangerl said: > 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). The only thing I've ever used 'whom' for is to verify that it picked the right Mike out of .mh_alias, or to see what the aliases expanded to. I've never expected any further validation than "this is a syntactically correct address", and wasn't even really aware that it *would* do further attempts at verification. But then, it's been 2 decades since I've actually used 'whom' on a system where validating the actual addresses was feasible. Does 'whom -check' have any real relevance in today's world? pgpvcqSesnAkz.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] FSF is changing Mailman list settings unless you opt out (fwd)
On Thu, 26 Sep 2019 12:36:41 -0400, Ken Hornstein said: > I received this email, and I wanted to pass it along. The executive > summary is: in the near future subject lines to nmh-workers will no > longer be prefixed with "[nmh-workers]" and there won't be a footer > at the end of the message anyone saying that this is the nmh-workers OK by me., my procmailrc already uses '*^(To:|cc:).*nmh-workers@nongnu.org' so it won't bother my set-up. > mailing list. You can read the details in the message for the complete > technical reasons why this is happening; the other option is to do > what is called "Munge From" and I personally think this is 100x worse Amen to that. Listserv also adopted a Munge-from solution, and the users rioted. In particular, the users whose From: got munged were incensed, because it makes 'reply from' very ugly and sometimes non-functional. (For the backstory of why this matters - if a Yahoo user (as opposed to a random non-Yahoo-using yahoo) sends a mail to a list, and the list modifies the Subject: line, then when it gets to the final recipient, their MTA looks at it, sees that Yahoo specifies very strict DMARC, which got borked by the change of the Subject: line. If the recipient MTA does DMARC checking on receipt, it potentially generates either a 5xx error inline or a bounce message that eventually get back to Mailman/Listserv/ whatever list management software. The end result is that if enough Yahoo users post to a list in a short time period, then you have a flurry of *NON*-Yahoo users being mysteriously unsubscribed from the list for no really immediately obvious reason. pgpKnrl8BOnkQ.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] 'dist' in "1 line noninteractive script"
On Thu, 25 Jul 2019 11:09:38 -0500, n...@trodman.com said: > On Tue 7/23/19 21:44 -0400 Ken Hornstein wrote: > >> mhannotate=Resent mhaltmsg=~/Mail/sent/bar mhdist=1 send > >> ~/Mail/drafts/foo > > > >It wouldn't surprise me that the problem is that ~ in mhaltmsg. Is that > >actually being expanded? If you run send with -debug, do you maybe > >see a message saying "$mhaltmsg mismatch"? > > $ ( set -x ; x=~ true ) > + x=/a/rodmant > + true > > So bash expands ~ before send sees it. But that may not be true for something that invokes execve() rather than system(), or a cronjob (which is what started this discussion). pgpGnHJNlgbPh.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Bleeping idiots!
On Tue, 16 Jul 2019 09:44:58 +0100, Ralph Corderoy said: > Hi Ken, > > > >Content-Type: text/html; charset="ansi_x3.4-1968" > > > > That character set is interesting. > > The 1968 revision allows LF to occur on its own compared to 1967's where > it always had to be LF CR or CR LF, but other than that still had many > of 67's oddities, e.g. ‘!’ could be rendered as ‘!’ or ‘|’, ditto ‘^’ > that was allowed to look like ‘�’. Probably not the creator of that > Content-Type field's intention. Maybe the creator was an embittered ex-PL/I programmer? :) pgpnP_DGqG6Wt.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] logging outgoing messages
On Tue, 09 Jul 2019 17:43:06 -0400, Steven Winikoff said:
> sm_reply.length = rp - sm_reply.text;
> sm_reply.text[sm_reply.length] = 0;
> +#ifndef NOSYSLOG
> +if (strncmp(sm_reply.text, "OK id=", 6) == 0)
> +{
This is highly dependent on the remote MTA.
Google, for instance, returns:
250 2.0.0 OK 1562718444 r17sm180161qtf.26 - gsmtp
The 250 is required. 2.0.0 (or similar) if the remote server does extended
return codes. The rest is up for grabs.
pgp9KL4F2M5Mn.pgp
Description: PGP signature
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Ordinal Indicators.
On Mon, 08 Jul 2019 17:25:42 +0100, Ralph Corderoy said: > Is -42nd handled? I admit being totally mystified as to what situations require proper handling of negative ordinals pgpM4SES7TBLk.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Superhuman MUA.
On Mon, 10 Jun 2019 11:25:30 -0700, Bakul Shah said: > On Mon, 10 Jun 2019 18:45:45 +0100 Ralph Corderoy > wrote: > > > > > Like "Undo Send" ... how does THAT work? > > > > What now? send -delay 30m > > Great idea! Until actual send occurs, the message stays in > +outgoing. "send -delay 5m" should be the default :-) Gives > the one some time to reflect on whether it was *really* > necessary to send that inflammatory message or to recover from > a fat fingered send! "Fred Smith would like to recall the message" Yes, I'm sure he would. That genie isn't going quietly back into the bottle, though. pgpMMNHTjW2gi.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Stupid 'pick' question...
On Sat, 08 Jun 2019 17:17:40 -0700, Bakul Shah said: > > So pick runs -search on header lines as well as the body a header specific > option is only run against headers. In a world of Microsoft Office attachments, is having -search go through the body by default as well still a good idea? Maybe having a separate -searchbody would be better? (Due to events not under my control, I'm currently stuck on a laptop with a Celeron CPU, and disk I/O is painful (it's managing only 3-5Mbytes/sec even with an SSD in it... Ouch) pgpZUdgvZqcDg.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Stupid 'pick' question...
On Fri, 07 Jun 2019 16:19:15 -0700, Bakul Shah said: > You can directly use search as follows: > > -search 'Subject[ \t]:[ \t]*\[PATCH [45]\.[0-9]' [~] grep ^Subject Mail/linux-kernel/321805 Subject: Re: [PATCH 4.9 04/20] net: Fix for_each_netdev_feature on Big endian [~] scan `pick +linux-kernel 321805 -search 'Subject: \[PATCH [45]\.[0-9]' -and -from gre...@linuxfoundation.org -list` 321805 * Thu 21Feb 7k Greg Kroah-Hartma Re: [PATCH 4.9 04/20] net: Fix for_each_netdev_feature on Big endian < pgprtuNFrLPxk.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
On Sat, 08 Jun 2019 14:55:01 +0100, Ralph Corderoy said: > I often switch to another user to see if they've any new email they'd > like to know about. All I really need for that is setuid inc that scans > the From and Subject fields. At which point the other user can't use their preferred mail tools on /var/spool/mail/otheruser, so if they aren't also nmh users they're in trouble pgp7F9QeYBmGh.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
[nmh-workers] Stupid 'pick' question...
So trying to work with the linux-kernel mailing list firehose (800-1500 messages a day), and hitting a problem with 'pick'. Am trying to match all messages from a given person with a given part of a subject line. pick -from -subject '\[PATCH [45]\.[0-9]' *almost* does what I want - catch all messages that have '[PATCH 4.9]' or '[PATCH 4.14]' or '[PATCH 5.0]'. However, it *also* catches messages of the form 'Subject: Re: [PATCH ' which is unacceptable for the use case in question. So I tried an anchored search using -subject '^\[PATCH [45]\.[0-9]' but that results in nothing matching. So much for this from the manpage: A modified grep(1) is used to perform the matching, so the full regular expression (see ed(1)) facility is available within pattern. With -search, pattern is used directly, and with the others, the grep pattern constructed is: So is ^ to anchor the search in fact unsupported? Broken? I'm using it wrong? Oddly enough, $ for tail-anchor seems to work: 18:56:33 0 [~/Mail/kernel-patches] scan `pick +linux-kernel last:3000 -from gre...@linuxfoundation.org -and -subject 'path' -list` | more 416491 * 17:38 +02 6k Greg Kroah-Hartma [PATCH 4.14 04/69] net: fec: fix the clk mismatch in failed_reset path < [ Upstre 416492 * 17:38 +02 6k Greg Kroah-Hartma [PATCH 4.14 14/69] net: mvneta: Fix err code path of probe < [ Upstre 416502 * 17:39 +02 6k Greg Kroah-Hartma [PATCH 4.14 30/69] USB: sisusbvga: fix oops in error path of sisusb_probe < comm 416537 * 17:38 +02 6k Greg Kroah-Hartma [PATCH 4.19 10/73] USB: sisusbvga: fix oops in error path of sisusb_probe < comm 416689 * 17:38 +02 6k Greg Kroah-Hartma [PATCH 5.1 10/85] USB: sisusbvga: fix oops in error path of sisusb_probe < commi 18:56:52 0 [~/Mail/kernel-patches] scan `pick +linux-kernel last:3000 -from gre...@linuxfoundation.org -and -subject 'path$' -list` | more 416491 * 17:38 +02 6k Greg Kroah-Hartma [PATCH 4.14 04/69] net: fec: fix the clk mismatch in failed_reset path < [ Upstre 18:57:08 0 [~/Mail/kernel-patches] pgpjYVXoVMbUk.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
On Tue, 04 Jun 2019 13:08:43 -0400, Ken Hornstein said: > True story: a long time ago we had a number of IRIX systems. The inetd > on those systems was buggy so it was common when you changed the inetd > configuration you just restarted it instead of sending it a HUP signal. > But even though the person who did this had su'd to root, some of their > user environment variables were inherited by their root shell and then > inherited by inetd ... and those made it down into various daemons > spawned by inetd which caused a whole bunch of confusing behavior at > login time. This behavior wasn't limited to IRIX or inetd. It could bite you on anything that used sysvinit or other schemes that had /etc/rc*.d/S34foobar scripts, where 'service foobar restart' would run the script inline. One particularly difficult to debug issue was an occasional hang of one of our Oracle databases. Finally tracked it down to part of the nightly automation which did the backups - it would wait till it got an e-mail saying the *previous* night's backup ran so it was safe to re-use the checkpoint area for this night's backup. Worked fine till one day I restarted Legato Networker around 1PM - and from there on all the "Your backup completed" mails went out as valdis@backupserver rather than root@backupserver... Whoops. :) (And yes, I did convince the DBAs to come up with a less brittle way of doing their nightlies. :) pgpCP8YwXF5aX.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh 1.7.1 compile errors
On Mon, 03 Jun 2019 15:58:18 -, masud.anw...@hmrc.gsi.gov.uk said: > I get the following compile errors compiling on solaris 10 - sparc and I'm > not sure how to resolve it. > Sun Compiler developer studio ansi C compiler > "/usr/include/curses.h", line 86: invalid type combination > 85 #if !defined(__cplusplus) && !defined(_BOOL) > 86 typedef char bool; > 87 #endif /* !defined(__cplusplus) && !defined(_BOOL) */ Apparently, the Sun compiler has sprouted internal support for 'bool'. Adding -D_BOOL to the CCFLAGS should work around this, but I'm not sure what you're using to configure/build nmh, so it's unclear where the best place to add it is. Anybody else still using Solaris 10 with either gcc or the Sun compiler? We'll need some testing to make sure if we add this to the autoconfigure stuff, we don't break it for other Solaris/compiler combinations... pgpWXr88gPfCn.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh 1.7.1 compile errors
On Mon, 03 Jun 2019 15:58:18 -, masud.anw...@hmrc.gsi.gov.uk said: > 73 * bool is a built-in type in standard C++ and as such is not > 74 * defined here when using standard C++. However, the GNU compiler > 75 * fixincludes utility nonetheless creates it's own version of this > 76 * header for use by gcc and g++. In that version it adds a redundant > 77 * guard for __cplusplus. To avoid the creation of a gcc/g++ specific > 78 * header we need to include the following magic comment: Didn't fixincludes pass into the realm of myth and legend quite a while ago? (Which is why I'm worried that this is brittle system code that breaks all too easily...) pgpGdk2ZdYq5w.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
On Sat, 01 Jun 2019 18:51:35 -0700, Bakul Shah said: > If you are calling procmail from ~/.forward, mail may not be > left in your system mailbox Also true if you've configured your system to skip a step and invoke procmail as the local delivery agent directly pgp1hCsM6HcIT.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Flagging messages
On Sun, 26 May 2019 10:12:56 +0100, Ralph Corderoy said: > anno does have a -component option, but pick doesn't. > I think you mean > > scan `pick --x-reminder bill` > > with the double dash. Gaah. And I even checked 'man pick' because I don't use 'pick' that often, so figured I better double-check. Which is why I screwed it up. ;) Manpage quibble: Note that '--component pattern' has 'component' bolded as if it is a keyword rather than a user-supplied value. See image below. Also... maybe I need to run out to the supermarket and get some more caffeine, but this is still confusing me: The expression `--component pattern' is a shorthand for specifying `-search "component[ \t]*:.*pattern" ' I even went back and checked rfc822, and it says: field = field-name ":" [ field-body ] CRLF field-name = 1* So what is that '[ \t]*' there for? Does that ever actually happen? pgpbQ6tUa8Fe7.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Flagging messages
On Sat, 25 May 2019 10:37:17 -0400, aalin...@riseup.net said: > Is there a way to do something similar in nmh? If not how do nmh users handle > such a situation? Hmm.. 'anno +folder cur -component X-Reminder -text "Pay This Bill" and then run scan `pick -component X-Reminder` Or 'refile +reminders cur -link'and then 'scan +reminders' The latter may be more efficient, especially for large inboxes pgpwxPPlxd103.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] for me a useful script
On Thu, 23 May 2019 13:45:02 -0400, Jude DaShiell said: > echo "first available message:" > scan -width 6|head -1 scan -width 6 first will be much faster. > echo "last available message:" > scan -width 6|tail -1 scan -width 6 last will be much faster. If you have 10,000 entries in a folder, scan first/last still has to read and sort the directory, but it can find first and last without opening a file. A quick test: [~] strace -f scan -width 6 +inbox 2>| /tmp/inbox | head -1 1 [~] grep open /tmp/inbox | tail -1 openat(AT_FDCWD, "1171", O_RDONLY) = 3 Yes, it reads that many files before the back-pressure SIGPIPE from 'head -1' exiting catches up with it. scan | tail will have to open and read all 10,000 files. pgpM7ok5rjbbv.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] #ifdef UK
On Sun, 19 May 2019 01:24:26 +0700, Robert Elz said: > That's it, entirely -- nothing related to ancient UK backwards domain > names or anything else exotic like that. I always wished the rest of the Internet had gone that way - it would have made it at least theoretically possible to tab-complete through a domain name. Until we lost the plot on the whole 'tree structure' and dumped 140 million similar names into .com, anyhow... pgpWER0xnmgFc.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] #ifdef UK
On Fri, 17 May 2019 14:01:53 -0400, Ken Hornstein said: > Apologies to our friends across the pond, but I noticed the #ifdef UK > in scansbr.h today, and I couldn't help wonder if anyone still uses this. As noted elsewhere, it probably shouldn't be an ifdef. On top of that, the behavior selected isn't even specific to the UK - large chunks of the non-UK part of the planet do things that way as well. pgpARgdhOZ0yj.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Change {encrypted} to %(encrypted) in mh-format
On Thu, 16 May 2019 23:10:32 -0400, Ken Hornstein said: > >Note that 'E' in the format is different to the alternate annotations > >that can occur in the same position (and trump the E if more than one > >applies) in that the others tell what I have done to the message > >(that I have replied, or forwarded it) - which is useful information > >to have in the scan listing. Random extracts related to content type > >is not. > > I'll let you and Valdis fight THAT one out :-) My point was actually just that if we're dragging around an E for encrypted, we may want an S for signed as well, when the latter is much more common, at least in the mail I get. The other stuff in my quote is *ancient* - I'm talking "measuring the uptake of RFC1341" levels of ancient, and thus can probably leave - I see at least two other special-case lines in my default scan that have been obsolete since Virginia Tech decommissioned their IBM 3090 mainframe Dec 1, 1999. My .procmailrc probably has equally out of date stuff in it.. :) pgpumwsAY3usT.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Change {encrypted} to %(encrypted) in mh-format
On Thu, 16 May 2019 20:56:28 -0400, Ken Hornstein said:
> It occur to me that this might still be useful, but making this switch
> on a component is obviously wrong, and it should really be a function
> escape. So I propose we switch all of the default scan formats from
> using %{encrypted} to a yet-to-be-written function escape %(encrypted).
> Since we don't really support encrypted email yet, this would always
> return false for now, but this would be a much better solution for future
> support rather than relying on a nonexistent header.
Probably need to be a bit more ambitious than that, and MIME-compliant.
What I have in my own scan file:
%(void{content-type})\
%<(match text/plain) \
%?(match text/html)H\
%?(match multipart/signed)S\
%?(match multipart/encrypted)E\
%|%<{content-type}M%|?%>%> \
although now that the vast majority of stuff is multipart/alternative with
a text/plain and text/html, retiring the M may make sense. I'm amazed at
how often I still see an 'H' or a '?' though. :)
pgpONYhqhoXYG.pgp
Description: PGP signature
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
On Fri, 10 May 2019 23:30:45 -0400, Ken Hornstein said: > Hoo boy, some names from the past in that thread. And Valdis, of course :-) Hey, I didn't post at all in that particular food fight. :) pgpZ7HdwrlIx4.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
On Fri, 10 May 2019 12:58:22 -0400, Ken Hornstein said: > >And many MIME-extension-fields may be present. > >https://www.rfc-editor.org/rfc/rfc2045.html#section-9 suggests that's a > >header matching /^content-/i, including `Content-: foo', I presume, > >unless some RFC says a header can't end in a `-'. > > Huh, that's a new one for me. RFC 5322 says: Section 9 is essentially reserving a namespace for MIME-specific headers. 9. Additional MIME Header Fields Future documents may elect to define additional MIME header fields for various purposes. Any new header field that further describes the content of a message should begin with the string "Content-" to allow such fields which appear in a message header to be distinguished from ordinary RFC 822 message header fields. MIME-extension-field := So the two of you are in what's often referred to as "violently in agreement" :) > Yeah, I am TRYING to understand the reasoning for the deletion of the > Content-Type header; it was clearly deliberate and existed way back in > MH 6.8.3 (and earlier; the earliest version I can find of mhn.c had that My under-caffeinated mind is whispering about a myth regarding ancient software on SunOS that stuck in things like 'Content-Type: uuencode' when using its pre-MIME scheme for sending non-text data. Of course, that was before recorded history^W^WGoogle, so records are sketchy, incomplete, and contradictory. There is even rumor that that some machines stored 6 6-bit or 5 7-bit bytes in one memory location, and as a result special incantations were needed if you wished to converse with a font of knowledge known as "simtel20". pgp9gYBvPT8Mf.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
[nmh-workers] Oddball question... %(num) and friends...
I know %(num) gets you the current message number in a folder. Is there an easy way to get the *name* of the folder? (Part of a truly bletcherous plan to use Fcc: and/or Bcc: to subvert GMail's auto-suppression of messages that result in you usually not getting a copy of mail you post to a list, because it saw the Message-ID: outbound so it munches the copy from the list. If I get something that works that isn't too nausea-inducing I'll send a copy for the contrib/ directory.) pgpBWlA8Jxosz.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] detecting enclosed msg as spam - unicode regex help needed, I think; spam unicode chars in header
On Sat, 04 May 2019 06:16:27 -0500, n...@trodman.com said:
> This is OT/not a nmh issue. It does concern spam unicode chars in the mail
> header
> though, so maybe you could direct me a bit.
> I use procmail, so I should be able to filter out msgs like the above,
> but I could use some tips on a general strategy.
Note that the presence of =?utf-8? in the headers is *not* always proof of
spam (see headers of this message), so be prepared to deal with false positives
appropriately (but see below).
Also, note that while procmail does support onboard regular expressions, they're
not a full PCRE set of expressions. So, for instance, you can't look for utf-8
strings
of more than a certain length by searching for
'=?utf-8?q?(=[0-9a-fA-F][0-9a-fA-F]){5}',
nor can you check for more than 10 occurrences via '(=?utf-8?.*){10}'.
You're probably better served by installing SpamAssassin and calling that from
procmail (as it will help with things other than utf-8 as well.
There's 90 presumed-spam messages in my spam folder at the moment. Of those,
12 have
one bodypart and specify charset=utf-8 in the rfc822 headers, while 44 specify
multipart and thus the charset=, if any, is buried in the body. 10 have raw
utf-8
in the From: line, and 17 have raw utf-8 in the Subject: line (but see below)
And something in the e-mail ecosphere is filtering and converting explicit
=?utf8? encoding in rc-822 headers. I was going to blame mhfixmsg, but it's
happening before procmail gets hold of it. I send mail to myself, 'send'
tosses it to Google, Google hands it back to me via fetchmail/imap thence to
sendmail and procmail, and the =?utf8 has been already decoded. I invoke
mhfixmsg as '| tee $tmpfile | mhfixmsg -noverbose -file - -outfile -', and the
version in $tmpfile is already converted. Meanwhile, some other mail
arrives with raw chars, while some *does* arrive with =?utf-8? still intact.
Weird.
pgpNF8DYJqLW3.pgp
Description: PGP signature
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] closefds() _before_ fork?
On Wed, 24 Apr 2019 03:46:04 +0700, Robert Elz said: > fd is also made to be fd 3. > > If it is good enough to be stdin, it is good enough to be 3 as well, > if there is (or once was) some reason this is important. Derp. -ENOCAFFEINE :) -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] closefds() _before_ fork?
On Tue, 23 Apr 2019 13:35:44 +0100, Ralph Corderoy said:
> It's not the only one, e.g. docs/historical/mh-6.8.5/uip/post.c has
>
> 2622 if (fd != 0)
> 2623 (void) dup2 (fd, 0);
> 2624 (void) freopen ("/dev/null", "w", stdout);
> 2625 (void) freopen ("/dev/null", "w", stderr);
> 2626 if (fd != 3)/* backwards compatible... */
> 2627 (void) dup2 (fd, 3);
> 2628 closefds (4);
>
> Note the comment.
The *real* WTF there is that the code doesn't actually know if fd 3 is
known to be open on a file that should, or if it's just a stray leaked fd.
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Reply to Ralph Corderoy
On Sun, 21 Apr 2019 18:29:57 +0100, Ralph Corderoy said: > ISTM it's also a bug to ignore problems opening a file that exists, and > to ignore a file given in an environment variable not existing. I agree on the first. The second probably need to be more nuanced, and "a *specific* file given in the environment". Consider how *PATH variables work, and it's possible that none of the directories contain the file in question and it's still OK. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Reply to Ralph Corderoy
On Sun, 21 Apr 2019 17:05:58 +0100, Ralph Corderoy said: > works. If so, then /etc/nmh/mts.conf's `servers' entry isn't being > obeyed. Either it isn't being read, or its getting trumped by something > else. I wonder if the file got installed with wrong permissions? I've seen installers screw the pooch because root's default umask was 077, and I'm insufficiently caffeinated to suss out what nmh does. This works for me: 12:24:12 0 [~] ls -l /usr/local/etc/nmh/mts.conf -rw-r--r--. 1 root root 1778 Feb 13 14:52 /usr/local/etc/nmh/mts.conf 12:24:15 0 [~] egrep -v '^$|^#' /usr/local/etc/nmh/mts.conf mts: smtp mmdfldir: /var/mail mmdflfil: servers: localhost 12:24:36 0 [~] grep send .mh_profile send: -nomime -msgid -server smtp.gmail.com -port 587 -tls -sasl -user val...@vt.edu (I never added the proper server name to mts.conf because it was bouncing all over the place, partly due to hysterical raisins, while my employer was first drinking the Google kook-aid.) -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] mhshow: invalid BASE64 encoding in --
On Mon, 18 Mar 2019 21:10:45 -0400, Ken Hornstein said: > But the email you sent out was marked as having a character set of UTF-8 > with characters encoded as ISO-8859-1. Dude, I know you could do better > (also, I am puzzled as to how that happened; I think with nmh you'd have > to work to make that happen). Note that exmh is now over 47,000 lines of tk/tcl, of which 'git blame' says I'm the guilty party for 1,297. I may be the current maintainer, but that doesn't mean I wrote all of it. :) Well, the chapter symbol as it showed up in your mail was a 2-byte UTF 'C2A7', and what ended up in the outbound mail was only a Q-P encoded =A7, so the question is what ate the C2 and why. Testing indicates that when I do the reply, the file when it's in Mail/drafts/ it's got the 2-byte string in it, but by the time it ends up in the Fcc: folder it's lost the first byte and the second byte is QP-encoded. It seems to work fine if it ends up with: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit but the failing message had this instead: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable which at least gives me a place to start digging in more detail. Current theory is an off-by-one (Cleaning up the non-ascii support is on the to-do list, but now that I have a specific failure case to chase, it's time to get some caffeine and beat this bug into submission..) -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] mhshow: invalid BASE64 encoding in --
On Sun, 17 Mar 2019 20:43:40 -0400, David Levine said: > Note the "in base64-encoded data". The characters in the footer are after > the end of the base64-encoded data, per the use of "end" here: > >Special processing is performed if fewer than 24 bits are available >at the end of the data being encoded. A full encoding quantum is >always completed at the end of a body. >From the very next paragraph: Because it is used only for padding at the end of the data, the occurrence of any "=" characters may be taken as evidence that the end of the data has been reached (without truncation in transit). No such assurance is possible, however, when the number of octets transmitted was a multiple of three and no "=" characters are present. In other words, you only have 2/3 chance of detecting that you've hit the intentional end of the input by looking for an '='. If you're ignoring line breaks and illegal characters, that means you've got a 1 in 3 chance of continuing to keep pulling in stuff and decoding stuff that wasn't intended to be decoded. > If we do want to handle this input, I don't think that we should make the > base64 decoder more lenient. Instead, I think that mhfixmsg should transform > it such that the rest of nmh could handle it. That still doesn't address the *real* question, which is what form that transform should take. Deciding whether the detection of an issue should be in the bse64 decoder or elsewhere is bikeshedding compared to trying to decide what semantics you want.. > I think that it is what I meant. But I also suspect that I'm missing your > point. The point is that accidentally glomming non-base64 data into the decoder is almost certainly *not* what you meant by 'see all of the content'. Particularly if the data wasn't ASCII - if it was a base64 of a zip file that got a bunch of basically random bytes appended to the end, you're going to have a *really* hard time figuring out why it was corrupted. Feel free to give this a try: cd /tmp echo ab > shortfile gzip shortfile (base64 shortfile.gz; echo "I think that it is what I meant. But I also suspect that I'm missing your point") | tr -dc '[A-Za-z+/\\n]' | base64 -d > short2.gz gunzip short2.gz At *best*, "see all the content" mean you get handed a bunch of decoded bytes that were never encoded, so you get random trash splatted out. At worst, you get difficult-to-diagnose data corruption. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] mhshow: invalid BASE64 encoding in --
On Sun, 17 Mar 2019 17:29:16 -0400, Ken Hornstein said: > >My reading of RFC2045 says a conforming base64 decoder is allowed to toss out > >the blanks and the '!' char and decode the rest. > > > > Any characters outside of the base64 alphabet are to be ignored in > > base64-encoded data. > > > >Yeah. That's pretty definitive. :) > > Oh, hm, you know you learn something new every day, and this is my new > thing for today. As much as I've read RFC 2045 over the years, I missed > this! (This is in �6.8, in case others want to look it up). There's this other related gem a few paragraphs earlier: The encoded output stream must be represented in lines of no more than 76 characters each. All line breaks or other characters not found in Table 1 must be ignored by decoding software. In base64 data, characters other than those in Table 1, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances. I'm still trying to get even a lower-case 'must be ignored' to line up with 'a rejection might be appropriate'.. :) -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] mhshow: invalid BASE64 encoding in --
On Sun, 17 Mar 2019 09:28:53 -0400, David Levine said: > More generally, what if a sender (improperly) had annotated an already > encoded message with, say, "DO NOT FORWARD THIS!"? Bad, yes, but could lead > to > undesired results if that was dropped. My reading of RFC2045 says a conforming base64 decoder is allowed to toss out the blanks and the '!' char and decode the rest. Any characters outside of the base64 alphabet are to be ignored in base64-encoded data. Yeah. That's pretty definitive. :) Which means your sender just prepended the string '?NLSXCLr' to the message (where the ? is an 'lower case a with circumflex') Somehow, I doubt that's going to stop it from being forwarded. > In other words, I'd like to see all of the content or an error message. Oh, and what happens if a conforming implementation takes that 'you are receiving this message' whoopsie and decodes it? This. Which is probably *not* what you meant by 'see all of the content'. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] mhshow: invalid BASE64 encoding in --
On Sat, 16 Mar 2019 22:14:41 -0600, "Anthony J. Bentley" said: > "mhshow: invalid BASE64 encoding in --" > > Since it's a public mailing list, one of these messages is enclosed below. > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: base64 Yeah that's a reasonable thing to do if you're sending UTF-8/ > Message-ID: <6c5e3c76d90a7...@poolp.org> > > Ck9uIE1hciAxNiwgMjAxOSA1OjA5IFBNLCBUaG9tYXMgQm9obCA8b3BlbnNtdHBkLW1pc2MtNjQ2 So here we start the UTF-8 > bnN1YnNjcmliZSwgc2VuZCBhIG1haWwgdG86IG1pc2MrdW5zdWJzY3JpYmVAb3BlbnNtdHBkLm9y > Zwo+Cg== And here we finish it.. > > -- > You received this mail because you are subscribed to m...@opensmtpd.org > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org And this is a crock, because it's still part of the (only) bodypart, but is obviously not base64. What *should* happen if mailing list software feels the need to stick a footer on is to repackage the mail as a multipart/related, with the first body part being the UTF-8 body of the mail, and the second the mailing list's footer. Somebody should complain to the administrator of that list - mailman has been able to do this rewrite correctly for aeons now. Having said that, there's certainly plenty of room in "be lenient what you accept" that maybe if we're looking at base64, if we encounter a blank line we toss the rest of the body part. (I have an equivalent on my to-do list for exmh for this same issue.) -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
