I second Milan on IMAP usage. Folder updating was a mess using raw mbsync.
JS On 26-01-05 15:54, Milan Straka wrote: > Hi all, > > I have been using exclusively mutt for reading all my emails since 2003 > and I am very happy with it 😁 > > In the past emails, "mutt" has been mentioned together with "die" quite > a few times; personally I do not think that mutt is going to die anytime > soon just because it is in maintenance mode. Personally I am happy with > this situation and thanks 🙇 Kevin 🙇 that you are still maintaining it 🙏. > > Cheers, > Milan S. > > PS: I am using exclusively IMAP to access my email on multiple servers, > because GDPR rules disallows me to download some of the emails locally, > so I do not think mutt should only read local mailboxes as mentioned in > one of the emails. > > > -----Original message----- > > From: [email protected] > > Sent: 5 Jan 2026, 15:28 > > > > Dear all, > > > > moreless ordinary mutt user here (only once I submitted a new functionality > > - not accepted); but for all the years I read all discussions on this ML > > with great interest. > > > > Mutt is perfect match for its predictability - once you learn/customize, no > > breaking changes ever. This is the pinnacle of a good software. Kudos for > > that! > > > > Said that, if mutt is going to die, *let it be in all of its glory*. With > > one last version, last tarball and last farawell celebration, so we, end > > users, have a good memories. It would be pity for such a great sw, as mutt > > is, to end uf slowly forgotten and removed from repos during the years to > > come. > > > > Just my few cents, > > Martin > > > > > > > > V 20260105 1417, Alejandro Colomar via Mutt-dev napsal(a): > > > Hi all, > > > > > > On Sun, Jan 04, 2026 at 09:44:18PM -0800, David Champion wrote: > > > > I've been trying to get back into Mutt. Sometimes I have time, > > > > sometimes I > > > > don't — it's hard to make any kind of commitment. If everyone capable of > > > > leading the project is in the same boat, then what Kurt describes is the > > > > only kind of growth solution I can see. > > > > > > > > I admit I haven't been paying close attention for a while, but I haven't > > > > seen many people who are recognized contributors step forward to > > > > volunteer > > > > time. I don't know whether that's because nobody can or will, or because > > > > those who can and will don't think it's wanted. > > > > > > I've been a mutt(1) user before becoming a neomutt(1) user. I would > > > have loved to stay in mutt(1), because I want my mail client to have as > > > few features as possible, but I *needed* to add some more GPG features > > > to it, and neomutt(1) was the only project that accepted new patches. > > > So, currently, I'm using neomutt(1). > > > > > > But the idea of forking mutt(1) or neomutt(1) and removing as many > > > unnecessary features from it as I can, and end up with a very slim > > > mail clent (maybe I could call it m(1)), has crossed my mind a few times > > > already. > > > > > > For a starter, I'd love to remove IMAP support, as that belongs in a > > > separate tool (mbsync(1)). That would have removed most of the bugs > > > I see reported in neomutt(1). A mail client should only talk SMTP, and > > > mbox & maildir, IMHO. > > > > > > > I'm certainly willing to remain to the extent that I have been, but we > > > > need > > > > there to be more people. I have code I technically could push, but I'd > > > > rather have review and commentary on it because I know that for all the > > > > hours I've put into it, it's not really enough to have one veteran who's > > > > been semi-retired for 10 years thinking about it alone in a cabin. > > > > > > > > If anyone else qualified in experience (with both C and the project) has > > > > even a modicum of time to make available, let's talk. > > > > > > I can give time reviewing patches, mostly with C expertise, but not so > > > much project expertise. I don't consider myself a mail expert. > > > > > > At the moment, I'm contributing patches to neomutt(1) making the source > > > code more robust, and reviewing those, and patches to the manual pages. > > > > > > > > > > > But we also have to ask and answer: is that what mutt users want? Or is > > > > the > > > > community satisfied with maintenance mode and low growth? > > > > > > > > On Sun, Jan 4, 2026 at 6:53 PM Kurt Hackenberg <[email protected]> wrote: > > > > > > > > > On Sun, Jan 04, 2026 at 11:59:52AM +0800, Kevin J. McCarthy wrote: > > > > > > > > > > >No, sorry it's highly unlikely. Mutt has been in maintenance mode > > > > > >for > > > > > >the past 4 years. At this point my time is very limited, so I handle > > > > > >security issues or occasionally tiny fixes or improvements. But not > > > > > >large changes like this anymore. > > > > > > > > > > > >You might want to head over to the NeoMutt project and see what they > > > > > think. > > > > > > > > > > If this continues, eventually Mutt will die. That's what happens to > > > > > software when development ends. > > > > > > > > > > I don't want that. Mutt is a programmer's mail reader -- powerful, > > > > > flexible, configurable -- and done at high quality. I'm not satisfied > > > > > with NeoMutt as a successor. Anyway, if Mutt dies, NeoMutt will > > > > > probably die sometime later. > > > > > > To me, it was, but I can't use it as a programmer anymore, because I > > > need to sign my patches, and verify that patches sent to me are signed, > > > and I can only do that with neomutt(1). > > > <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/git#n35> > > > <https://neomutt.org/feature/cli-crypto> > > > > > > And another necessary feature is encrypting patches, and verifying the > > > encryption information. This is useful when discussing embargoed > > > vulnerabilities. > > > <https://neomutt.org/feature/encryption-info> > > > > > > I would love to see mutt(1) do that. > > > > > > > > > Have a lovely day! > > > Alex > > > > > > > > Kevin is trying to step down from being the maintainer. Nobody has > > > > > volunteered to take over his job as it is, understandably. He seems to > > > > > have done it mostly by himself, and that's a lot of work. > > > > > > > > > > I think we need a different organization, one that distributes the > > > > > responsibility and work, and the control of the code, among more > > > > > people. Maybe there could be a team of 5-10 people that takes > > > > > responsibility for Mutt, with contributions from many other people, > > > > > who > > > > > might join the core team someday. Part of the job would be ongoing > > > > > encouragement and help for contributors. > > > > > > > > > > Ideas? > > > > > > > > > > > -- > > > <https://www.alejandro-colomar.es> > > > > > >
signature.asc
Description: PGP signature
