Re: [exim] IMAP and Maildir?

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: W B Hacker
Fecha:  
A: exim users
Asunto: Re: [exim] IMAP and Maildir?
Morgan Gangwere wrote:
> Y'all
>
> I'm trying to get IMAP and Maildir delivery working... Only to see something
> odd happen.
>
> I want mail to live in ~/Maildir/[folders]
> I don't want the directories my MUA thinks should exist cluttering up my home
> dir.
>
>
> What I want is something like this:
> ~/Maildir/inbox/...
> ~/Maildir/sent/...
> ~/Maildir/[etc...]
>
> How can I configure uw-imapd to do this? /can/ uw-imapd do this?
>
>



Dovecot can certainly use a bespoke mailstore. I'll have to plead lack of even
remotely current experience on uw-imap, but STR it can do so as well.

However, I wouldn't make 'Maildir' the top-level of the fs mount, but rather,
something such as our use:

/mail (an fs mount usually on its own separate RAID array)

used as:

/mail/<[primary|secondary]-IP>/<domain.tld>/<userid>/Maildir [1]

where <userid> is not even necessarily the $local_part, but in our case is
derived from $local_part via a DB relation (makes shared folders, identity
change, old/new/combined working easier).

To the extent that it is Exim, not the IMAP daemon, that places the messages
INTO <mailstore-wherever>, along with their EUID:EGID ownership and r/w
privileges, THAT part is easy and a road well-traveled. It can be hard-coded,
looked-up, or a combination of both. EG: you can 'build' the path to suit your
needs.

That is done in Exim's router/transport coding.

Thereafter it is the IMAP daemon that needs to be told where to *find* the
messages for a given user, so as to make them available to his MUA.

THAT coding has nought to do with Exim, so needs (in your case) some help from
the uw-imap docs. CAVEAT: be careful not to create a situation wherein one valid
login can munge his MUA settings so as to read messages not his own [2].

Likewise, in any other situation wherein Exim hands-off the traffic to other
than its own queue, it is that 'next-stage' critter - even a chain of such -
that needs to be configured for the style of mailstore you wish it to utilize.

HTH,

Bill Hacker


NB:

[1] <primary/secondary-IP> is for use with a failover scenario, wherein copies
of traffic are replicated to a hot standby in anticipation of a future need.

But even without any such array, it can be handy over time for keeping track of
what is what for anyone running multiple boxes with virtual domains.

[2] unless you need to. We (may) allow 'Supervisors' to read the messages of
some of all of their own staff, for example.