[plug] [OT] Local-user IMAP

[James Devenish]

Hi,

I'm trying to come to grips with IMAP (actually, no, I'm trying to
ignore it and only deal with it when it can't be avoided). Anyway,
I am seeking some assistance in doing things the "IMAP way" while
at the same time attempting to preserve a workflow that currently
uses direct filesystem access. If you want to know what my questions
are, they are stated at the end of this e-mail. The basic problem
is that I would like to convert the following scenario to IMAP:

 - Mail is currently delivered to a special-purpose UNIX account on a
   server (this account does not represent any individual real-life
   person). The account is used only for this mail-related application.
 - The account has a .procmailrc that filters mail either into some
   Maildirs or an mbox spool.
 - There is a policy daemon and a cronjob, which run under the UNIX
   account. These processes periodically read and modify the Maildirs.
 - There are real people who can log in remotely via POP to draw mail
   out of the spool file.

Now, the nice thing about the policy daemon and cronjob is that they
have "passwordless" access to the Maildirs and mbox, simply because of
the UNIX permissions system. I want to change this workflow to be
IMAP-based. That is, the software would no longer access Maildirs or
mbox directly, but would access IMAP mailboxes (with no regard to how
they are stored on disk). There are real reasons why this is being
proposed -- it is not just a flight of fancy for the sake of using IMAP.
As part of this, the following additional changes are expected to take
place:

 - The remote users will gain an ability to access the Maildirs
   remotely, in addition to the mbox that they can already access.
   (Of course, they will not be accessing Maildirs or mboxes but rather
   they will be accessing IMAP mailboxes.)
 - The policy daemon and cronjob will continue to need passwordless
   access to the Maildirs, but this will be done via the IMAP protocol.

The IMAP server in this case is Cyrus. Now, the immediate hurdles that I
recognise are:

 - I don't know enough about IMAP or the authentication mechanisms
   available (these authentication methods obviously have to be
   supported by both Cyrus and the remote clients).
 - I don't know how to give the policy daemon and cronjob
   passwordless access to IMAP mailboxes via Cyrus.
 - I don't know how to do passwordless authentication with mutt.

Some constraints are:

 - None of the autonomous IMAP access should require any "priming" with
   passwords (i.e. it is not okay if a human has to intervene to provide
   a password or passphrase for the policy daemon or cronjob).
 - No one's IMAP access should require any pre-establishment of
   long-running tunnels. It is quite fine for the remote users to have
   to enter a password in the same fashion as currently done with POP.

I did a bit of reading on the mutt web page and one thing that caught my
eye was this:

    <http://mutt.sourceforge.net/imap/>
    1.2.1.3. Using a tunnel to your IMAP server
        set tunnel="ssh -q mailhost /usr/libexec/imapd"

What caught my eye was the fact that I initially inferred that the
/usr/libexec/imapd process was a method for a local UNIX user to
access its own IMAP mailboxes on the localhost. However, I think my
interpretation is wrong because I don't understand how this could work.
The point of this e-mail is really to ask three things:

 - Does anyone have any good pointers to information about passwordless
   IMAP access for autonomous processes running on the same server as a
   Cyrus IMAP server? These processes will run as a specific UNIX user
   and will only need to access the mailbox account for that user.
 - Can anyone guess what the mutt webpage is trying to demonstrate?
 - When using mutt to shuffle mail between IMAP mailboxes belonging
   to a single user, it is necessary to "enter your password every time"
   within a single mutt session?