Re: vixie out
Ken Hornstein wrote: > >The new system is Office 365 and all employees are *required* to use > >Lookout on their Windows and Mac systems as an MUA using a badge for > >authentication. Given that, I'm pessimistic there is an open way to > >access NASA email. Linux users currently have a waiver to continue using > >IMAP, but that will go away once NASA IT finds a solution. It is likely > >to be a dictated MUA (as with the Mac and Windows) rather than a general > >mechanism. > > Geez, you really should be more up-to-date on the mailing list :-) We're in agreement there! > I can't promise this will work for you, but this message might be > helpful: > > https://lists.nongnu.org/archive/html/nmh-workers/2019-05/msg00029.html Indeed. If you're still associated with the navy, you're certainly feeling the same pain, as the requirements come from the NIST, I think. I'll look forward to trying it when I return to the office. Thanks for pointing out the thread as I clearly missed it during my skim. > --Ken -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: vixie out
>The new system is Office 365 and all employees are *required* to use >Lookout on their Windows and Mac systems as an MUA using a badge for >authentication. Given that, I'm pessimistic there is an open way to >access NASA email. Linux users currently have a waiver to continue using >IMAP, but that will go away once NASA IT finds a solution. It is likely >to be a dictated MUA (as with the Mac and Windows) rather than a general >mechanism. Geez, you really should be more up-to-date on the mailing list :-) I can't promise this will work for you, but this message might be helpful: https://lists.nongnu.org/archive/html/nmh-workers/2019-05/msg00029.html --Ken
Re: vixie out
Ken Hornstein wrote: > Geez, Bill, you HAVE been out of it for a little while, haven't you? :-) > > >Dovecot is a server and Maildir is mail storage format. What are you > >using as a UI? > > Paul has mentioned this before, but to fill you in ... I forget which > MUA he uses (I want to say Thunderbird, maybe?) but the key point here > is Dovecot stores it's messages in Maildir folders. So he was interested > in tools that could work directly on Maildir folders. This is a _BIT_ > challenging. Thanks for that. My mail to p...@vix.com bounced. > As a larger note ... I always thought the use of Maildir as a message > folder format was a bit weird. I have no objections if people want to > add that support for Maildir folders, but there are some challenges, and > I think the number of people who would find that useful is small compared > to the number of people who would find IMAP useful, so it wasn't something > I was going to work on (we do, today, have support in inc(1) for Maildir). > > >Yeah, with all of the security that NASA is adding, my days of fetchmail > >and procmail are numbered at work, and with it, MH and MH-E, unless I > >can find a way to bridge the gap between the NASA Linux email UI > >(Evolution?) and the MH mail store. > > I can't speak for exactly what you guys are doing, but I believe we > support all of the relevant security protocols with regards to POP > and SMTP. So if you guys have a POP server and a SMTP server you point > Evolution to, I don't think there's a reason you couldn't use nmh with it. The new system is Office 365 and all employees are *required* to use Lookout on their Windows and Mac systems as an MUA using a badge for authentication. Given that, I'm pessimistic there is an open way to access NASA email. Linux users currently have a waiver to continue using IMAP, but that will go away once NASA IT finds a solution. It is likely to be a dictated MUA (as with the Mac and Windows) rather than a general mechanism. > --Ken -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: vixie out
Geez, Bill, you HAVE been out of it for a little while, haven't you? :-) >Dovecot is a server and Maildir is mail storage format. What are you >using as a UI? Paul has mentioned this before, but to fill you in ... I forget which MUA he uses (I want to say Thunderbird, maybe?) but the key point here is Dovecot stores it's messages in Maildir folders. So he was interested in tools that could work directly on Maildir folders. This is a _BIT_ challenging. As a larger note ... I always thought the use of Maildir as a message folder format was a bit weird. I have no objections if people want to add that support for Maildir folders, but there are some challenges, and I think the number of people who would find that useful is small compared to the number of people who would find IMAP useful, so it wasn't something I was going to work on (we do, today, have support in inc(1) for Maildir). >Yeah, with all of the security that NASA is adding, my days of fetchmail >and procmail are numbered at work, and with it, MH and MH-E, unless I >can find a way to bridge the gap between the NASA Linux email UI >(Evolution?) and the MH mail store. I can't speak for exactly what you guys are doing, but I believe we support all of the relevant security protocols with regards to POP and SMTP. So if you guys have a POP server and a SMTP server you point Evolution to, I don't think there's a reason you couldn't use nmh with it. --Ken
Re: vixie out
Paul Vixie writes: > folks, it's been a blast. i used MH from 1985 to 2005 exclusively, > then from 2005 to 2015 in parallel with uw-imapd, and not at all since > mark crispen's death when i moved to dovecot and Maildir. Dovecot is a server and Maildir is mail storage format. What are you using as a UI? > i've helped find and fix bugs in the MH library, i regularly tested > and patched the MH (and Kerberos) parts of uw-imap, i even wrote some > hooks (thanks, jon!) for maintaining and using a BDB index for NMH's > folders. > > i've operated a 32-bit NMH build server back when i had 32-bit > servers, and i've started a few and joined many discussions as to > software portability and system architecture here. > > but i think it's time i admitted that IMAP and MIME are my future, and > that i will probably never use NMH or MH-E again. Yeah, with all of the security that NASA is adding, my days of fetchmail and procmail are numbered at work, and with it, MH and MH-E, unless I can find a way to bridge the gap between the NASA Linux email UI (Evolution?) and the MH mail store. > you are a great team but it's time i said goodbye. i'm about to answer > the unsubscribe-verify e-mail; i don't see any non-cc'd followups. And all the best to you. > goodbye all! > > -- > P Vixie -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: Future directions for nmh
Wow, have I been away since 2016? Assuming it's no longer moot, I have a couple of thoughts regarding grepable mail: 1. I use grep via MH-E probably on a weekly basis to find messages in non-indexed folders. 2. I also use grep to discover deleted messages more often than I'd like to admit. 3. I use mairix to index my email. It appears mairix supports Maildir. In another thread, pack and sortm were mentioned. I use those on a regular, if annual, basis and would like to see these preserved with any new mail store. Being able to access my mail folders remotely (via the Gmail app on Android, for example) is very attractive. If Maildir or IMAP gets us there, then I'm all for it. 3,000 more messages to go... I'll surely find discussions on these topics along the way. Ken Hornstein writes: > So, since my simple question about a new release spawned a whole thread > about the future direction of nmh I wanted to create a distinct thread > to discuess those ideas. If you're interested in commenting on future > ideas for nmh, this is the place to do it. > > I am first going on the assumption that completely redoing the email parser > and making all of the nmh tools MIME-aware is a noncontroversial subject. > If you disagree, please speak up. Also, if you are unclear what exactly > I mean by that, also speak up. > > To address other things brought up recently: > > 1) I do not think converting and storing incoming messages as UTF-8 is wise. >In terms of just simplicity alone I think messages should be stored >(somewhere) in their on-the-wire format; this is more robust and >would prevent loss of mail if there is an issue with character >conversion at mail incorporation time. I'm talking about the default >here; if you want to convert them to some other form using mhfixmsg >or some yet-written tool, that's your business. > > 2) Assuming you agree with 1) (I know Lyndon does not :-) ), then I think >converting stuff internally to UTF-8 before output would not be a net >gain; it might make some things easier, but I think in general it would >make things more complex. The system we have where character conversion >happens somewhere after parsing and before display, while a bit >haphazard, seems to be fine in practice, and it's close to what other >open source MUAs do when I looked at them. If we were on Plan 9 >then this would be a different decision, but we've heard from enough >users that do not use UTF-8 locales that makes me think this is a serious >concern. > > 3) Like I said, I am officially neutral on creating a grep(1)able mail >store; I think it's an exercise in futility, but enough people want >it that it's clearly not something that is worth dismissing. As >Jerrad pointed out, you can probably accomplish most of this today >with his MIME-Hooks. Do we include that? If we do not, we should >put it in contrib if there isn't a good home for it. Would that >be sufficient for people that wanted it? I just don't feel great >about having the "exploded" message being the canonical format. >Maybe Paul Vixie is right about me holding onto this idea that nmh >should keep the original mail store; maybe that's driven by me still >using exmh. I'd make the point that at some point we have to process >a RFC5322-format message for every piece of email, so that code still >needs to be written regardless of doing anything else. > > 4) In terms of alternate mail stores, be they Maildir or IMAP (I think >those are the two major candidates now, right?), I think those ideas >are interesting. The #1 problem with those ideas is how to map MH >message numbers (which can range 1-MAXINT, with holes) to the internal >key used by those mail stores; everything else is relatively easy >to deal with. > >For IMAP ... well, it occurs to me that locally you have a database that >would map message numbers to IMAP UIDs. This local database could also >store annotations, sequences, and maybe something else I'm forgetting. >If you found a message that wasn't in your database, you'd have a new >message and add it to your local database; if a message was missing, >you'd have a hole in the message number sequence. sort(1)/pack(1) would >really be about shuffling around this list of message numbers. This >would have the disadvantage that if you accessed your IMAP store from >another system you'd have new message numbers, sequences, and annotations, >but it would be tons better than what we have now (which is that it >doesn't work at all). I have some thoughts on how to create a shareable >database for that stuff in IMAP, but I'd need to include a trigger >warning for Lyndon so he could start drinking heavily before he >read it :-) > >For Maildir, a similar idea, except that you could do annontations >directly in the message. Really,
Re: ics files with nhm / mh-e
Axel, Once you find something that works on the command line, I can think of a couple of ways to access your method with MH-E: 1. Use the `|' (mh-pipe-msg) command to pipe the entire message through an appropriate command. https://mh-e.sourceforge.io/manual/mh-e.html#Files-and-Pipes 2. Use `K e' (mh-display-with-external-viewer) to 'view' the ICS attachment with an appropriate command. https://mh-e.sourceforge.io/manual/mh-e.html#Viewing-Attachments Axel Jantsch wrote: > Hi, > > What are the best ways to deal with ics calendar files with nhm and/or mh-e ? > > I use nmh with mh-e as front end, and get regularly ics files. When > getting such a file I would like to do the following: > > 1 a) Add the event to my google calendar; > b) Make an update to an existing event in my google calendar > > 2 a) Add it to the emacs diary file; > b) Make an update to an existing entry in emacs diary; > > 3) Acknowledge / accept / reject the event; > > > For (1a) I use gcalcli but I feel it is a bit unreliable; it worked > well, then it did not work for several months due to an update; then it > worked again on some of my platforms but not others. So I wonder if > there is a better alternative. > > For (1b) and (3) I have no working solution. > > What methods do others use? > > Cheers, > Axel > > -- > Axel Jantsch > TU Wien > Email: axel.jant...@tuwien.ac.at > Web: www.ict.tuwien.ac.at > > > ___ > mh-e-users mailing list > mh-e-us...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mh-e-users > -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: ics files with nhm / mh-e
Axel Jantsch wrote:
> What are the best ways to deal with ics calendar files with nhm and/or
> mh-e ?
> I use nmh with mh-e as front end, and get regularly ics files. When
> getting such a file I would like to do the following:
> 1 a) Add the event to my google calendar;
> b) Make an update to an existing event in my google calendar
I bounce the email to my gmail account :-(
If there were a reliable IMAP server that could serve my desktop +inbox,
then I'd point gmail and/or Thunderbird (with Google Calendar plugin) at it.
{my desktop has public IPv6}
> 2 a) Add it to the emacs diary file;
> b) Make an update to an existing entry in emacs diary;
I tried to use it once, but I didn't get far.
> 3) Acknowledge / accept / reject the event;
You can do that from google calendar, once it is in place.
> For (1a) I use gcalcli but I feel it is a bit unreliable; it worked
> well, then it did not work for several months due to an update; then it
> worked again on some of my platforms but not others. So I wonder if
> there is a better alternative.
I never got gcalcli working. Maybe I tried when it didn't work.
That seems like the best solution to me.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
Re: ics files with nhm / mh-e
Someone else will have to speak toward the MH-E side of things, but speaking in terms of pure nmh ... >I use nmh with mh-e as front end, and get regularly ics files. When >getting such a file I would like to do the following: > >1 a) Add the event to my google calendar; > b) Make an update to an existing event in my google calendar We don't have any native tools for interfacing with an server speaking the CalDev network protocol, which is sounds like is what you want for this piece. I see there is a project called "calendar-cli" which might do that. The one piece I wish we did here was have mhical convert a "request" into a pure calendar entry, for the case where I use nmh to reply to the calendar request but want to add it to my calendar (basically, strip out the method line). I keep meaning to bring that up to David (who wrote mhical) or do that myself, but now is a good as of a time as any to mention it, I suspect. >2 a) Add it to the emacs diary file; > b) Make an update to an existing entry in emacs diary; It seems like you could use mhical to extract out the bits from the calendar entry so it was what emacs needed. >3) Acknowledge / accept / reject the event; You can do this natively in nmh. You can look at "replaliases" in the nmh contrib directory for "replaliases" that has the shell aliases "calaccept", "caldecline", "caltentative", "cancancel" (I do not believe iCalendar supports an "acknowledge" response). The shell aliases end up running something like this: % repl -noformat -editor mhbuild \ -convertargs text/calendar '-reply accept -contenttype' --Ken
Re: ics files with nhm / mh-e
Hi Axel, > What are the best ways to deal with ics calendar files with nhm and/or > mh-e ? I've not used it so I don't know how well it covers your requirements. $ man -k icalendar mhical (1) - nmh's manipulator of iCalendar event requests Its author is on the nmh-workers@nongnu.org list. -- Cheers, Ralph.
