[neomutt-devel] neomutt NNTP and Active Directory usernames

[Sirius]

In days of yore (Tue, 09 Apr 2024), Richard Russon thus quoth: 
> Hi,
> 
> > I would like to leverage neomutt's capabilities to connect to NNTP for
> > reviewing upstream kernel work.
> 
> Great.  I'd welcome any feedback on the NNTP support.

Once I got the caching working, it worked great for what I am currently
doing (reviewing upstream CXL timeline over patchsets).

Something that I have not (yet) figured out, is the ability to set a
number of articles to cache per group, so I am running with the generic
setting set to 50,000 which is too much for some groups like linux-cxl and
linux-nfs as I see further back than I need, but for linux-kernel that
might not be enough.

> Quick history.  Vsevolod Volkov created a patch for Mutt and maintained
> it out-of-tree for twenty years.  We merged and updated it slightly, but
> it's still a bit clunky.
> 
> Any suggestions you have would be appreciated.

I will have a deeper dig into it when I have completed the document I am
writing up for our product management and kernel engineering, which at the
speed I am going will be finished later today.

Ability to configure a per group amount of articles to cache would be
great. The usecase here is, taking org.kernel.vger.linux-cxl at
nntp.lore.kernel.org as the example, that initially, I need to see all the
articles, and there is about 15,500 of them at the moment. When I have
gone over all of them, I can likely reduce the amount of cached articles
to 2-3,000 as that will cover the more immediate history for periodically
updating the document with the new things.

For a group like org.kernel.vger.linux-kernel, 3,000 articles cover about
two days of posts, so that is not enough to cache if I need to do a
similar document. I may need to cache ten to twenty times that to capture
a whole thread of discussion. So per-group cache would be very useful.

Not worked out how to display the groups in the sidebar yet either. Will
get to that as well.

A second thing may be ability to define more than one NNTP host, but then
I may be asking for too much. :) Rationale here is that
nntp.lore.kernel.org carries groups that are quite specific to linux
kernel, but nothing else, and if I want to access other UseNet groups I
need another NNTP server.

A possible solution is that I configure up Inn and run it myself and work
out how to pull from multiple upstream NNTP servers into one Inn instance.
(Thinking out loud - that is a great usecase for containerisation
actually.)

> > I am faced with a bit of a problem...
> > For some reason, it has replaced the '@' with '_' in the path.
> 
> Ah, sorry about that.  It's an overzealous search'n'replace.

Usernames containing an '@' is not common on Linux, so that is
understandable. It was just handy to leverage my NAS for AD and get the
account handling included.

> I've had a closer look and figured out what to fix, but
> it's not a one-liner, so it may not make next week's release.
> 
> Reto's fix will be safe enough until then :-)

It is working and allowing me to do what I need to do so I am happy. :-D
I was trying out both slrn and nn before, and they were driving me batty
with how they function. With neomutt I have muscle memory for certain
operations so it is great being able to use it for this work.

> > I built neomutt with './configure --gnutls --gpgme --gss --gsasl --tokyocabinet'
> 
> We'd recommend using `--lmdb` instead of `--tokyocabinet` (if possible).
> It's much faster.

Rebuilt with lmdb and I agree, it is much better. For mutt I had used qdbm
with compression, but I switched that to lmdb as well.


A final note. The NAS I have is Synology and the mailserver on it is
called MailPlus Server. neomutt label handling (for working with notmuch)
is the same as what MailPlus use, so that is quite useful for manipulating
server labels via the client.

-- 
Kind regards,

/S