Quoting Steve Litt (sl...@troubleshooters.com): > 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! _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
