Christian Schmidt wrote: > Hello Philip, > > Philip Hazel, 22.04.2006 (d.m.y): > > >>On Fri, 21 Apr 2006, Christian Schmidt wrote: >> >> >>>How can I make exim (or better: the appendfile transport) decide if a >>>mail shall be dropped into an existing mbox file or a maildir? >> >>The file_format option of the appendfile transport allows for different >>formats of single-file mailbox. You might be able to coerce it into >>doing the right thing, but then again it might not work. I suspect >>you'll have to make the decision at routing time (e.g. by checking for >>the existence of appropriate files/directories). > > > Thanks, Philip. > > But as I already mentioned, I haven't thought of problems occurring > with the IMAP/POP server - so I'd choose a one-step-migration solution > when it comes to migrate to maildir. > > Regards, > Christian >
You *can* do it. Dovecot-pgsql or -msql are easiest, as the location and type can be user-specific. - Something like: user_query = SELECT pg_mailroot||'/'||pg_login_name||'/' ||pg_mailstore AS mail, pg_uid AS uid, pg_gid AS gid FROM mailprof WHERE pg_recv_login||'@'||pg_domain_id ='%u' AND pg_active LIMIT 1 Where: mailprof(ile) is the [EMAIL PROTECTED] preferences table pg_<variable> are the DB attributes, reasonably self-documenting pg_active is a boolean flag for active/suspended accounts 'mail' is Dovecots variable for user-specific storage %u is Dovecot's variable for <[EMAIL PROTECTED]> The concatenation builds a path to the mailstore location and type, i.e: /data/mail/domain/user/Maildir or /data/mail/domain/user/mbox Courier-IMAP/POP can be handled in a similar manner. And the same effect can be had with lighter-weight lookups than SQL - CDB, for example. That said, as with an abcessed tooth, a one-step migration is probably more easily managed. Acute pain, rather than chronic... ;-) Bill -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
