Quoting Steve Litt (slitt@???):

> Can GNUS be used as a window into a local multilevel many-mailboxed
> Dovecot IMAPserver?

Um, dunno, sorry. I don't do emacs. (I'm a sysadmin, not a coder.
C-x C-c is just about all the emacs I know -- the commands to get the
hell out.)


> Same question with mutt: I haven't gotten it to
> happen, correctly, all the time.

Er, I _think_ so. But there's a thing, that I should explain.

Chez Moen, however (where linuxmafia.com is), I'm either famous or
infamous -- take your pick -- for insisting on radically simple IT
infrastructure for my Internet presence and operations. Back in the
late '80s when I first started doing my own *ix servers, initially on
386BSD, the way you did mail was:

1. You run an SMTP smarthost, which sends/receives mail to/from other
smarthosts, and hands off incoming mail to an LDA (local delivery
agent), which was procmail. The LDA plonked down the incoming SMTP
bitstream whereever so directed according to its recipes, by default
into /var/spool/mail/[username] in mbox format, or else somewhere else
such as ~/mail/* mbox files if given non-default instructions.

2. Your MUA operated _there_, because that's where the mail was.
Take your pick of mail (primitive), mailx (primitive), elm, or (ooh,
shiny!) pine. Later, mutt. The MTA (mail transfer agent, the smarthost
daemon) picked up and whisked away any outbound mail the MUA generated,
typically by the MUA invoking /usr/sbin/sendmail to handle it (that
being present as an additional hardlink even for non-sendmail
alternatives such as Exim4,Postfix, and Courier-MTA).


That works and is dirt-simple. Your mail is always _right there_; none
of this bullshit of 'Oh, I don't have access to that mail now because I
pulled it down over IMAP at work and now I'm at home. TO read your
mail, you did telnet (later, ssh) to the smarthost. You read mail, you
replied. the replies got picked up by the smarthost and sent out, you
logged off.

Some time around 1995, I was running RHL5 or such and it had a POP3
daemon that ran under [x]inetd. I permitted this, and a couple of my
users started relying on it because for some reason they preferred
Eudora or something over elm or pine or mutt. I had no use for the
in.pop3d service, myself, so I ignored it.

One fine day, I came to grips with the fact that POP3 posed an
unacceptable security risk on account of plaintext transmission of
passwords also usable for inbound ssh. Rejecting the workarounds
(APOP, POP3-SSL, POP3 tunnelled over ssh, etc.) on various grounds, I
told my users (who, I should stress, were friends paying nothing at all,
not clients) that I'd shut down the POP3 daemon and it wasn't coming
back. I said, either use one of the linuxmafia.com-local MUAs the way I
did, or transport mail to your workstationey-thing in some other
ssh-mediated way, the obvious choice being rsync. (IMAP4 was not yet a
thing.)

One user, Alice, reacted by throwing a fit. She _needed_ to use Eudora!
I said I had no objection. But that means I _needed_ to turn the pop3d
back on! I said, no means no. My server, my rules. And I pointed out
that the sysadmin, the guy I shave, had examined the much smaller attack
surface from all angles and found it pleasing to his eyes. Alice
attempted the time-honoured method of solving problems known to user
helpdesks the world over: If you yell progressively louder and more
operatically, eventually the world will give you exactly what you want,
because you are a Special Person. I admired the display (mostly over a
telephone call or three), interjected 'Let me know if you want modest
help with rsync, albeit with limits resulting from my not having touched
a Windows box since WfW 3.11.' Eventually she got tired of yelling and
went to some fleabitten ISP, and I think is now a GMail user. Because
of course she is.

It may surprise you to hear that, having solved the POP3 security
problem by having no POP3, I later solved all problems with IMAP by
having no IMAP, too. The attack surface remains pleasingly small. And,
to this day, some of my mail's in /var/mail/rick (after Debian pulled
some bullshit where they EOLed /var/spool/mail and replaced it with a
symlink) in bog-standard Neanderthal mbox format. The rest is in
~/inboxes/[thing] in bog-standard Neanderthal mbox format -- except for
archived old mail that's tucked away in bog-standard Neanderthal mbox
format, gzipped.

Accordingly, mutt has absolutely no access problems getting to my
mboxes, in as much as they are local to mutt. Best solution to IMAP
problems ever invented: no IMAP!

In case you're curious, I leave a couple of specialised-role instances
of mutt running 24x7 under GNU screen.[1] Anywhere I am in the world, I
just ssh to my server, reattach the screen sessions of interest, running
their respective mutt copies, and I'm exactly where I was with mutt the
last time I connected. Disconnect screen later, close ssh session, go
to sleep. Lather, rinse, repeat.

So, how do I deal with the problem of access to a local multilevel
many-mailboxed Dovecot IMAPserver? In classic Taoist fashion: by not
_having_ a multilevel many-mailboxed Dovecot IMAPserver (or any other
IMAP or other remote Mail Delivery Agent). Works for Me[tm]!

And yes, I've heard many times that mbox is terrible and that I should
use Maildir instead because it's much better for NFS file locking and
for IMAP access. But: no NFS here, no IMAP here. Thus, no NFS
problems and no IMAP problems.

The Neaderthal lifestyle has its advantages, y'see.

Accordingly, if I wanted the answer to your question, the most direct
way would be to construct a test setup, but, sorry, I'm not up for that.


[1] Yes, I've heard about tmux. KTHXBYE!