[5420] in Release_7.7_team
Re: nmh and IMAP
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Thu Mar 2 13:54:05 2006
Mime-Version: 1.0
Message-Id: <p05230101c02ce9bbb593@[18.152.1.192]>
In-Reply-To: <200603021825.k22IPmLo004516@egyptian-gods.mit.edu>
Date: Thu, 2 Mar 2006 13:53:08 -0500
To: Greg Hudson <ghudson@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
Cc: release-team@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
I would be thrilled if option 1 was chosen, causing nmh (and, by
extension, xmh and exmh) to ride off into the sunset. This would
leave Pine as OLC's only supported tty client, and would allow us to
focus on supporting more advanced features and customization of pine.
I don't forsee any feasibility barriers; I can't think of any method
of connecting to Athena in which a curses-based client wouldn't work
but nmh would.
Some of our client base probably would object to nmh going away, but
I'm sure they are the same people who insist on using mail(1) for
outgoing e-mail and still have NFS homedirs. I suspect they could be
transitioned to pine or evolution without much effort - we had one
client the other day who wanted an alternative to checking his mail
via a combination of Tether, HostExplorer, and inc. We showed him
Webmail (he already had DSL at home), and he was thrilled. As far as
students go, I'll note that we completely dropped any mention of nmh
from the Intro to Athena minicourses this year, and I believe that
was also the case for the last two years, so I think the majority of
students who check mail on Athena are using Evolution, pine, or
webmail.
As far as outside interaction, I'd be happy to coordinate with
Training & Pubs to attempt to offer a couple of Pine or Evolution
quickstart classes to help transition users away from nmh.
That having been said, I would be happy if there were _also_
server-side changes to a modern version of POP. Plenty of folks
still like the POP mentality, and I think POP should be migrated to
something like POP over SSL (which Gmail POP users are familiar with)
or POP with krb5. Presumably IMAP would also migrate to IMAP with
GSSAPI, which would allow us use stock pine builds and give users the
flexibility to use POP or IMAP without having to worry about athena
pine vs SIPB pine. But I don't know if such server-side changes
would conflict with the IS&T-wide push to eliminate users of POP.
As far as option 3, I think once people are made aware of the
mitmailfoo tools, they actually like them a fair bit, and don't feel
the need to revert to nmh for managing their mail on the command line.
Wow, this was far longer than I intended it to be.
-Jon
At 1:25 PM -0500 3/2/06, Greg Hudson wrote:
>I looked at the current state of nmh development, and it does not
>appear that they have added IMAP support. The last discussion I saw
>was an iteration of a five-year-old debate ("should we add support for
>IMAP as a pull protocol, like we use POP, or should we make it so that
>nmh commands can operate directly on an IMAP mail store").
>
>So, our options for getting away from nmh as a krb4 client are:
>
> 1. Sunset nmh support
> 2. Adapt KPOP to krb5 (server and client changes)
> 3. Write our own IMAP pulling support (client changes only)
>
>The first option minimizes coding but maximizes outside interaction;
>the third option maxmizes coding but minimizes outside interaction.
--
-------------------
Jonathan Reed
jdreed@mit.edu
-------------------
