Re: Macintosh for nmh?
Orbiting back, It looks to have only been deployed in anger with Google POP. And, in NEWS and the code it's marked as deprecated/unsupported for various reasons. But I would imagine it still works fine on the SMTP side. for O365 I am using mbsync with the python oauth2 external proxy, because I need to coordinate MH with imap and this mechanism maintains a smallish statefile on the MH side, which tracks the current IMAP message store state. Its "handle this imap store in a way which inc can read from, but inc is now dependent on 3rd party code" hell. A hell I am comfortable in, its the one with Banjos and Accordions but the food is good. It very probably works, and works well if your inc use-case is POP, and works for SMTP. I haven't tested this. -G On Sun, Dec 31, 2023 at 10:25 AM George Michaelson wrote: > I will have to find out why I couldn't get things to work before. I would > love less components in my supply chain, so to speak. > > G > > On Sun, 31 Dec 2023, 10:21 am Ken Hornstein, wrote: > >> >If you're on a mac and using O365 you may need >> >https://github.com/simonrob/email-oauth2-proxy >> > >> >Using it for a year, happily. >> >> We DO support XOAUTH2 natively, BTW. >> >> --Ken >> >>
Re: Macintosh for nmh?
I will have to find out why I couldn't get things to work before. I would love less components in my supply chain, so to speak. G On Sun, 31 Dec 2023, 10:21 am Ken Hornstein, wrote: > >If you're on a mac and using O365 you may need > >https://github.com/simonrob/email-oauth2-proxy > > > >Using it for a year, happily. > > We DO support XOAUTH2 natively, BTW. > > --Ken > >
Re: Macintosh for nmh?
If you're on a mac and using O365 you may need https://github.com/simonrob/email-oauth2-proxy Using it for a year, happily.
Re: inc -file truncates, manual pages say it doesn't
more than just possible: certain! ripe % grep inc ~/.mh_profile inc: -form inc.comps -truncate -audit history ripe % apologies. Go back to sleep, nothing to see here, move along -G
inc -file truncates, manual pages say it doesn't
lir-wg % ls -l lir-wg-1997-January.txt -rw-r--r-- 1 ggm staff 18029 17 Oct 10:50 lir-wg-1997-January.txt lir-wg % inc +ripe/lir-wg/1997 -file lir-wg-1997-January.txt Incorporating new mail into ripe/lir-wg/1997... 5+ 01/08 Mike NorrisLIR mtg at RIPE 26 - draft agenda<
Re: Unsupported nroff macros on MacOS X
Big +1 to homebrew and macports depends. They just work. But .. you obv. want a generalised maximal fix. (And rightly so) G
Re: Unsupported nroff macros on MacOS X
You're using macports, homebrew or fink. If the command is in /usr/local/bin then "its not in OSX" stands as a problem. Its not in $PATH for a native install without adjunct s/w All of this can be avoided if nmh adopts "install package x" requirements because groff does handle .fc. The point is, (I believe) Ken is (rightly) trying to minimise the surface of required dependencies to install, to ones in the base distro of most Unixen. -G
Re: Unsupported nroff macros on MacOS X
I have ventura but not a clean install. it found homebrew nroff. /usr/bin/mandoc is in the base. Thats probably why the man command worked. what you said otherwise, I concur with. -G
Re: Unsupported nroff macros on MacOS X
Not to prolong the agony, I tried the example on OSX for man tbl: .TS tab(@); ccc. This@is@centered Well,@this@also .TE It didn't work with the nroff -man they supply. It did work with mandoc So my summary of understanding so far: FreeBSD: does not honour .fc no longer has functional tbl or nroff in base, does have mandoc which honours .TS/.TE OSX: does not honour .fc, no longer has functional tbl, nroff is braindead, does have mandoc which honours .TS/TE debian: has nroff and tbl. nroff appears to be groff. honours .fc. The minimal install does not have mandoc. apt install mandoc and it works.
Re: Unsupported nroff macros on MacOS X
On Tue, 4 Apr 2023, 07:10 doug dougwellington.com, wrote: > > Us. > > Of course. There are 26 members on Savannah. Is that all of us that > are left? > I wouldn't personally put it much more than 10x that number. You could argue 100x but it would be insane to argue 1000x. mhonarc has significant usage. Does that count? G >
Re: Unsupported nroff macros on MacOS X
On Tue, 4 Apr 2023, 06:48 doug dougwellington.com, wrote: > > , but who are we maintaining nmh for? > Us. >
Re: Unsupported nroff macros on MacOS X
Apologies. enter (send) before typing. on FreeBSD 13.1 fc [delimchar [padchar]]Define a delimiting and a padding character for fields. Currently unsupported. Also, fc is not recognised in mdoc as far as I can tell. A different mechanism might be needed no matter what. in which case, dropping use of fc and retaining man might work, but that said, this comment from the man 7 man on OSX: DESCRIPTION The man language was the standard formatting language for AT UNIX manual pages from 1979 to 1989. Do not use it to write new manual pages: it is a purely presentational language and lacks support for semantic markup. Use the mdoc(7) language, instead. -G
Re: Unsupported nroff macros on MacOS X
On Mon, Apr 3, 2023 at 3:43 PM Anthony J. Bentley wrote: > Ken Hornstein writes: > > - Switch to tbl(1) macros which as far as I can tell are supported by > > mandoc and seem to work everywhere. > > tbl is supported by mandoc, yes. In my opinion, this is the best option. > Well, converting to mdoc macros would be nicer, but also much more work, > and who would do it? > > > (I do not know when tbl(1) was created, but it wouldn't surprise me > > if MH predated it). > > According to the mandoc manuals: > > HISTORY > The tbl utility, a preprocessor for troff, was originally written by > M. E. Lesk at Bell Labs in 1975. > >
Re: flist -- "Killed" -- oom (*not* 1.8 related)
I've always done sortm -verbose after big delete fests. verbose because I love watching the towers of hanoi shuffle along. lots of GUI mail systems have 'compact mailbox' command options. I assumed that everyone did periodic tidyup anyway. I'm not saying this isn't a problem. But, I seriously wonder how BIG a problem this is. If you can renumber out of it, then isn't that a viable work-around? -G
Re: (Not-so) hypothetical question: What to do about NULs?
> if a NUL appears in the header somewhere all bets are off. I think it would be fascinating to understand how that happened. Depending on how the parse tree is done, it could be marginally bad, or catastrophic. I really would be amazed if this is seen in the wild. But its a big network: maybe its out there? The IETF "modern SMTP" stuff John Klensin is working on (with others) might want to talk to that: a lot of the ICANN UA stuff is a push for UTF-8 clean across the board. -G
Re: mhfixmsg character set conversion
I went looking, and Mac Mail.app will replace "..." quote marks with “.. " which is half-pregnant: it modified only one side of the pair. This causes a text/plain to be sent which is detected by vi(m) as UTF-8. So I kind-of like Mac for making an outcome which is correctly typed for encoding, and I kind-of hate Mac for calling this text/plain but then modifying what I typed to uplift 7 bit ascii clean typing to a modern world. I guess text/plain is true: its text, it's just not petroglyphs. -G
Re: mhfixmsg character set conversion
On Thu, Feb 10, 2022 at 10:50 AM Steven Winikoff wrote: > > >Try ‘:se fileencoding?’ when vim-ing good and again with bad. > > Good point: > >$ vim good >:set fileencoding >fileencoding=utf-8 > >$ vim bad >:set fileencoding >fileencoding=latin1 > > > >I expect the bad file has something earlier on which fixes vim's idea of > >the encoding to ISO 8859-1 > > That does seem to be the case. Do you have any idea what kind of thing > that might be? (I know you can't diagnose a file you haven't seen, but in > general, what sorts of things should I look for?) > Typically for me (at least) bad encoded files have been processed to find 'thing' and converted to the Microsoft belief you meant to use the real pair of quote marks they prefer. processed by super-smart software. the worst kind. "I was only trying to help" software. Cut/Paste of text in from a web browser can trigger this. I usually see it doing python file read. I have to remember to brute-force open as UTF-8 or else python does what it thinks is needful and marks the stream as binary, and not suitable for use in the str() function suite. -G
Re: In Memoriam: Norman Z. Shapiro 1932-2021
The RAND etiquette report was enormously influential on my thinking. I've referred to it many times since '85. I think it resonates to this day. It's a good read. G
Re: crufty mhn.default.sh stuff
I think xv may be falling off the maintenance list. I struggle to compile it on OSX but that may just be that better native (nonX) tools exist. Mplayer forked. Many people use MPV now. On Sun, 19 Dec 2021, 8:18 am David Levine, wrote: > Paul wrote: > > > "mpeg_play" isn't even available on a current Ubuntu (so also not > > Debian, right?) release. > > Also not readily available for Fedora. > > > Seems like the right swiss army knife to be using these days would > > be mplayer, which appears to be available in most places, and which > > has never failed to play any type of video I've given it. > > I like it. How about ffplay as a fallback? > > > I got curious, and found that the mpeg_play support was in the > > initial Doug Morris version, dated April '99. There are other > > suspicious program recommendations from the same commit: > > > > ivs_replay (for mhshow-show-application/x-ivs) > > richtext (for text/richtext) > > rt2raw (for text/richtext) > > None of those are readily available for Fedora. > > > plus probably half a dozen someone archaic looking programs for audio > > support. > > I don't use any of them. > > > And others that Doug didn't introduce, but which are somewhat long in > > the tooth: > > xv > > soffice > > Both are readily available and work on Fedora. It can create /bin/soffice > as a symlink to libreoffice. > > > Seems like some of this could be cleaned up, but some degree of > > backward compatibility (for folks that actually have mpeg_play > > installed, or for those that actually have all of the patches and > > libraries needed for xv these days) would probably be good. > > The current choices could be left as the initial choices in > mhn.defaults.sh. Though I wouldn't mind if the obvious obsolete ones > were ripped out. > > David > >
Re: super-mime-encoded..
thanks for this Ken. That's quite a recipe. Heuristic. Kabbalistic incantation... -G On Thu, Dec 16, 2021 at 1:12 PM Ken Hornstein wrote: > > >I have some mails which appear to be PKCS7 SMIME bodypart.. > >containing... PKCS7 SMIME bodypart. > > In my $DAYJOB, I deal with a lot of these as you can imagine. My > reading of the relevant specs is that the first encapsulation is > encryption, and the second is signing. The encryption is what I care > about, since in our environment that's typically encrypted using a > key on a smartcard. > > >It's like some emailers have to super-encode things. I haven't done > >much debug, and I know this is being super-lazy, but even the Mail.app > >on OSX barfs on it. I suspect its O365 which is sending it. > > Well, it depends what you're talking about. > > As far as I know, Mail.app works fine as long as it's "vanilla" S/MIME, > including the double signing/encryption. What messes things up is > if Microsoft products generate a TNEF-format file, which is their > proprietary MIME-like format. Mail.app cannot handle that, unfortunately. > In theory Microsoft products aren't supposed to be doing that when sending > external email, but it happens. > > >So.. is there a trick to get NMH to know to unwrap-the-unwrap? > > Yes. You mentioned OS X, so I'll tell you what I do: > > - mhstore the first S/MIME part, which will probably end up a file called > smime.p7s (or something close to that) > - Use the MacOS X command "security cms -D < smime.p7s > output" to decode > the signed data. If the outer part is signed you don't need a private > key at this point. > - Edit "output" and convert it to Unix-style line endings to deal with a bug > in nmh (fixed in current). > - Use "mhstore -file output" to store the raw S/MIME data; you can also > use "mhlist -file output" to see the MIME parts (but in this case there > is typically only one). > - Use the same "security" command again to decrypt the data. At this point > you will need the appropriate certificate/private key in your keychain > or on a smartcard (you can specify it, but if there is an associated > certificate the security command usually can find it). > > I have a plan to eventually add S/MIME support to nmh, but ... so little > time. > > --Ken
super-mime-encoded..
I have some mails which appear to be PKCS7 SMIME bodypart.. containing... PKCS7 SMIME bodypart. It's like some emailers have to super-encode things. I haven't done much debug, and I know this is being super-lazy, but even the Mail.app on OSX barfs on it. I suspect its O365 which is sending it. So.. is there a trick to get NMH to know to unwrap-the-unwrap? What I've been doing is hand-decoding the SMIME bodypart once the outer wrap is done, using OpenSSL. Probably, I'm asking if you can take a non-header SMIME body, and somehow coerce NMH into doing its decode on a 'naked' body with no header, but with basic MIME decor. -G
Re: application/pkcs7 handling (receive not send)
Thanks for the "security" thing. Didn't know about that one. I suspect I've got bare keys in the loop, either frighteningly bare (on-disk) or via a fork/exec inheritance like ssh-agent (or keychain, either OSX or GPG) to get round some of this. So I have a workable (as in, I can read things) state, via the nasty path. But it's pretty nasty, in all senses. It isn't very discriminating about what to show me in the MIME bodyparts, And it has all the problems you identified. Basically, I leveraged MHN to "hand the problem off to something else" in shell. I have to explicitly call | less with gpgsm because MHN calling gpgsm doesn't seem to invoke MHL over the output. Emacs appears to have a lot of this built in now, because (I believe) more mail packages than MH-E want secure mail to work. So I suspect inside Emacs, it's ignoring what .mh_profile says for MHN for this MIME bodytype. and doing its own thing. Probably that stems from having to "pipe" a header/body into the emacs hooks for a visible pane. I did a search down the .EL files, It looks to have a bunch of MIME types and actions defined in MH-E related LISP code. Thats why I think the decode is outside of the MH space: Respect the file, use inc and post, but handle display "yourself" I'm also now a bit leery of where to set things. Using the Emacs built in 'configuration tools' wound up writing some things in .emacs but I can't work out where it did anything about SMIME. Oh well. Any program written in LISP is probably self-aware anyway. Skymesh won't build itself. I don't intend sending PKCS7. The stupid Mail.app has a sticky behaviour around signed/sealed mail which is an infection that leaks: I get stuff, because people turned it on once, and it stuck (when it detected a cert for me) So I wanted to be able to at least read stuff. Overall MIME sucks a bit for good old terminal mail. Not to disrespect Ned Freed, Nat Borenstein , but Mostly I just want to send people text. (Although with Markdown I increasingly expect *emphasis* to uplift so there you go: I'm no better than anyone else here) And I'm responding to this inside GMail so .. who knows how bad the payload is! -G
Re: application/pkcs7 handling (receive not send)
To answer my own mail: mhn-show-application/pkcs7-mime: %pgpgsm --decrypt '%F' sort-of works, but seems not to invoke mhl. But thats a minor issue. What I missed is that the temporary file emitted IS the mime bodypart after Base64 decode , so you don't need to tell gpgsm to de-base64 it. -G On Wed, Jul 21, 2021 at 3:43 PM George Michaelson wrote: > > Sorry to awaken an old story from 2019, but I would love to know what > frobs to tweak, to be able to decode PKCS7 S/MIME encoded payload. > > MH-E is (I think) breaking out of the classic NMH path to do this, > with the payload. So, I don't "see" a clean path in mhnshow > definitions to do this. > > The fine mail archive terminates in 2019 with a discussion on how to > SEND SMIME pkcs7. I just want to read at this point. > > I successfully imported my "own" work certificate via P12 -> Firefox > -> P12 (in another format) -> gpgsm --import (gpgsm is fussy about > what P12 "is" apparently)) so I have a .kbx now with this magic. And > some call out from emacs is finding it. > > (getting MH-E working was this works bundle-of-joy. It actually went > smoother than I feared, and that includes getting "modern auth" > working with Outlook 365 backed inbound Mail via mbsync, but sending > is classic password AUTH LOGIN over SMTP/587 via msmtp) > > all cluestick hits greatfully received. > > -G
application/pkcs7 handling (receive not send)
Sorry to awaken an old story from 2019, but I would love to know what frobs to tweak, to be able to decode PKCS7 S/MIME encoded payload. MH-E is (I think) breaking out of the classic NMH path to do this, with the payload. So, I don't "see" a clean path in mhnshow definitions to do this. The fine mail archive terminates in 2019 with a discussion on how to SEND SMIME pkcs7. I just want to read at this point. I successfully imported my "own" work certificate via P12 -> Firefox -> P12 (in another format) -> gpgsm --import (gpgsm is fussy about what P12 "is" apparently)) so I have a .kbx now with this magic. And some call out from emacs is finding it. (getting MH-E working was this works bundle-of-joy. It actually went smoother than I feared, and that includes getting "modern auth" working with Outlook 365 backed inbound Mail via mbsync, but sending is classic password AUTH LOGIN over SMTP/587 via msmtp) all cluestick hits greatfully received. -G
Re: IBM's 18-month company-wide email system migration has been a disaster, sources say
I hadn't realised "notes" was still a thing. On Fri, 2 Jul 2021, 5:18 am News via Norman Shapiro, wrote: > https://www.theregister.com/2021/06/30/ibm_email_outage/ > > I sent you this link because I believe, for one reason or another, that it > might > be of interest to you. My doing so DOES NOT MEAN that I agree with or > endorse the > content of the link. > Norman Shapiro > >
Re: Message header formatting
I do occasionally look at X-List-Archive: to get a url for the thread, to pass to other people. Thats the only novel header I view and I can do that with the file path from mhpath and grep when I need it. G
Re: Message header formatting
Brilliant idea! I too would use an inverse match logic. Shorter rules, easier to apply, probably faster. G On Sun, 6 Jun 2021, 8:17 am Jon Steinhart, wrote: > I've been getting increasingly annoyed at the number of header lines > that fill a screen or two before I can even see message contents. I > keep adding to an already huge ignores line in my mhl.format but new > headers seem to be created daily. > > Is there any incantation for "show only the headers explicitly listed > in mhl.format" so that new and uninteresting headers from everybody's > latest spam filter, mailing list manager, and internal tracking don't > fill the screen. > > BTW, when looking at this I noticed that while the mhl man page has > examples for the ignores variable that it's missing from the list of > variables on that page. > > Jon > >
Re: Very large folderTo:
Its always been my belief that large folders cause multi level directory block chaining in traditional UNIX fs. This itself incurs costs and consequences on how the cross-system file buffer cache works. Basically, any operation which requires all the directory blocks to be walked in sequence flood kernel file buffers. It has impacts on other uses of the OS. It is likely more modern FS like ZFS handle this differently but I don't know, I've never seen an analysis. Your system has cronjobs doing things like find . -type f -mtime which may run slower, you may be causing general systems slowdowns. I think it would make sense to filter out the things you want. I Share your problem, mails from now dead relatives it is exquisitely painful for me to read but I am unwilling to delete, and the thought of having to write filters to find and file them doesn't fill me with joy. On the other hand, I have replicated the data because you have other risks: disk media is fragile. Don't have only one copy of these mails. A cloud mail provider like Google might be a good backup, and has filter, search and tag options. Cheers G On Sun, 6 Jun 2021, 7:10 am , wrote: > Starting in late 2014 I have stopped deleting messages, putting them in a > directory, +gone, which now contains 465,147 messages and uses about 17 > gigabytes. The bulk of these messages were of transitory or of less > interest > to me. But they include 1,702 messages from my daughter. They were almost > all > of no interest or use to me within a day or two of when she sent them. But > she > recently died (the worst thing by far that's ever happened to me). Now > every > byte she ever wrote is precious to me. So I am glad that I stopped deleting > messages that I no longer care about. > > In practice this large folder has little impact on performance. For > example, > whenever I do a pick which is, or in a script which might be, +gone, I > give it > an argument like last:10. I could, if necessary split +gone into > several > smaller folders, but I would rather not. But I'm concerned that a bug in > nmh > might cause a problem. For example, some kind of a buffer overflow. > > So, what is the likelihood of such a bug? Does anybody have any experience > dealing with such large folders? > > > > > > > Norman Shapiro > > -- > Starting in late 2014 I have stopped deleting messages, putting them in > a directory, +gone, which now contains 465,147 messages and uses > about 17 gigabytes. The bulk of these messages were of transitory or of > less > interest to me. But they include 1,702 messages from my daughter. They > were almost > all of no interest or use to me within a day or two of when she sent them. > But she recently died (the worst thing by far that's ever happened to me). > Now every byte she ever wrote is precious to me. So I am glad that I > stopped > deleting messages that I no longer care about. > > In practice this large folder has little impact on performance. For > example, > whenever I do a pick which is, or in a script which might be, +gone I give > it an argument like last:10. I could, if necessary split +gone into > several smaller folders, but I would rather not. But I'm concerned that a > bug > in nmh might cause a problem. For example, some kind of a buffer overflow. > > So, what is the likelihood of such a bug? Does anybody have any experience > dealing with such large folders? > such a large folder might > > > > > > > Norman Shapiro > >
whats the brew nmh ownership?
I'm not very clueful about how things like homebrew get prodded for release update. Always interests me which side of the fence makes it happen. Is it NMH people, or Homebrew people? (its on 1.7.1 via url "https://download.savannah.gnu.org/releases/nmh/nmh-1.7.1.tar.gz;) It doesn't actually matter right now because I'm not exposed to a significant bug on OSX/Homebrew, so I'm really just being nosy: there's no compelling problem to fix here. -G
coming back to (N)mh after a 15 year hiatus..
I'm trying to come back to nmh after 15 years in the wilderness of Mail.app and related. So far, its been good except I had to add 2 extra digits into my scan profile entry because I hoarde more mail per year. The inc -file ~/Maildir thing has been a godsend: mbsync to fetch imap Maildir from o365, and the .uidvalidity file seems to keep state/sync with the NMH model. Many thanks for the refresh. George
