Re: [nmh-workers] Superhuman MUA.
On Monday, 10 June 2019 22:41:18 UTC Ken Hornstein wrote: > >$ cd `mhpath +future` > >$ find -type f > >./2019-06-10T18:13/1 > >$ > > Maybe it's the rocket engines, but it sure doesn't seem like that's how > it works. It implies you can "Undo Send" anything. you seem to be implying that a new-economy technical company with a great looking web site and venture backing might be making specious claims. that just cannot be. by simple elimination, i deduce that they have invented either time travel, or less likely but possible, a portable secure cooperative universal inbox editor. either way, we can be sure they're not _lying_. -- Paul -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Superhuman MUA.
>> Like "Undo Send" ... how does THAT work? > >What now? send -delay 30m > >$ cd `mhpath +future` >$ find -type f >./2019-06-10T18:13/1 >$ Maybe it's the rocket engines, but it sure doesn't seem like that's how it works. It implies you can "Undo Send" anything. --Ken -- 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] Superhuman MUA.
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! -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Superhuman MUA.
Hi Ken, > The web site sure does look great, and features rocket engines, > sparklers, and attractive people playing tennis. Which ... I guess is > related to email? I think we're meant to recognise ourselves in the photos and therefore realise it's the product for us. > Like "Undo Send" ... how does THAT work? What now? send -delay 30m $ cd `mhpath +future` $ find -type f ./2019-06-10T18:13/1 $ With something coming along to send/post anything in a `past' folders? -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Superhuman MUA.
>I heard of this Gmail-competitor MUA recently. https://superhuman.com/ >Reading through its list of features, it seems quite easy to think of >scripting some of them, e.g. delayed sending by refiling into a to-send >folder that's posted in the background, or appending a future reminder >to a per-day file to be inc'd. I had not heard of it, so I took a look at it. The web site sure does look great, and features rocket engines, sparklers, and attractive people playing tennis. Which ... I guess is related to email? Maybe if I spend less time emailing I'll have more time to play tennis and I'll be more attractive. And a few of the features they claim to support seem ... impossible? Like "Undo Send" ... how does THAT work? >For the avoidance of doubt, this isn't suggesting we ship features like >this, just a reaffirmation that being able to script mail-processing >programs that work well together, and with the rest of Unix, is >powerful. Yeah, it's just convincing people of that (and getting our MIME support) up to snuff). --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
Hi Ken, > In the "old days", it was common for the mail spool to only be > writable by group 'mail' (or something similar) and if you did dot > locking you couldn't create a lock file in the spool directory unless > your mail program was setgid mail (you can see this code in the > original MH). Doesn't nmh still do this, e.g. configure may define MAILGROUP? > > Regardless of whether it's a good idea, since the kernel is using > > effective user and group IDs for testing permissions, if a user ID > > is used to determine what files to access then it should be the > > effective one rather than the real one. Do you agree? > > Well ... no, not in this case. > > First, I do wonder what you think you're accomplishing by making > inc(1) setuid; we don't do any of the right stuff in terms of changing > the effective userid BACK when writing out the messages. And I wouldn't want it to. If setuid to foo then I'd expect user foo's mail spool to be read, and its +inbox to be written, all based on its .mh_profile. But inc is a distraction. As I said originally, that everyone ignored and just replied about inc :-), this is Unix and file stuff where the kernel is using the euid should be paired with userspace using the euid, e.g. don't attempt to read my file with your permissions. If we want to document nmh can't run setuid or setgid, apart from explicit exceptions, then that's fine, but at the moment it doesn't say that and actively codes for those cases, e.g. environment variable MHTMPDIR is ignored if either setuid or setgid. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
[nmh-workers] Superhuman MUA.
Hi, I heard of this Gmail-competitor MUA recently. https://superhuman.com/ Reading through its list of features, it seems quite easy to think of scripting some of them, e.g. delayed sending by refiling into a to-send folder that's posted in the background, or appending a future reminder to a per-day file to be inc'd. For the avoidance of doubt, this isn't suggesting we ship features like this, just a reaffirmation that being able to script mail-processing programs that work well together, and with the rest of Unix, is powerful. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
