Re: [exim] dbm to MySQL migration

On 8/31/06, W B Hacker <wbh@???> wrote:
>
>
> Maildir is better for most use, not all. But we also store per-user
> selection
> of storage type (Maildir, mailstore, Mbox...) and storage location
> (concatenating the path and folder names) in several fields in the DB.
>
> We do not offer POP, use Dovecot vs Courier, as it is closer to Exim w/r
> PostgreSQL configuration. Have used Courier-IMAP with MySQL, and
> Courier-MTA
> (IMAP/POP) with PostgreSQL.
>
> Dovecot is *way* easier to configure and integrate in an SQL environment.



I still have to look into the advantages of the Maildir format, just like
which POP/IMAP daemon
to use next.

Why offer only IMAP? Okay I run a small system but so far I've never receive
a question to
provide IMAP. I also did some work for a large ISP (over 1.5 million
mailboxes) they also only
offer POP3 and use IMAP only on their backend network for webmail use so not
directly
to customers. And this is mainly because they create a spam folder where
they put all spam
tagged mail. Which can only be viewed / removed through webmail.


> For 'convergence' (aliases) we list each 'identity' in its own record. To
> the
> DB, there need not have to be any functional distinction between an alias
> and a
> 'real' account.
>
> We simply load the same storage type and directory location into both
> records.


So just to be sure I understand:

localalias: localuser1,localuser2,remote@address

would become 3 different records in the database? And you retrieve the
destinations
with one single SQL query?


> Webmail has an entirely separate ID:PWD set, similarly arranged, which
> allows a
> traveler to change their webmail UID:PWD after each use of an untrusted
> box,
> (and not via said untrusted box!) to protect against key-loggers, while
> leaving
> their normal MUA UID:PWD alone.


Cool feature. You still see a lot of mailbox / FTP account / whatever
password sharing
but it's quite nice to seperate accounts for different use. Although
sometimes may be
confusing to the customer.


You will, however, also find my name on other posts saying we *use* SQL
> DB-driven Exim, but do NOT recommend it to others.


Well my system was setup about 6-8 years ago with Exim3. With an even
smaller group of accounts and domains. And as was mentioned in another post
I was not a big fan of putting user info into a database as databases may
become unreachable and a password file always works fine (and if it doesn't
you probably have bigger issues).

Even though the system still works fine I am looking at a redesign of the
whole
system. It would be nice to virtualize the users into the database. Making
everything
authenticate against the database. Besides mail also FTP accounts and
probably
more to think off. We also have a really small (and lame...) customer care
center
for people to change their mail aliases and create accounts. Also want to
redevelop
this as well and improve the stuff a customer can change regarding mail /
pop, dns,
ftp, websites etc.

Which ofcourse it probably is easier to switch to Plesk, DirectAdmin or
whatever.
But so far have no intentions to do so.

The reasoning is that the DB side is likely to be more work with a steeper
> learning curve than the Exim side - unless you are already quite
> SQL-expert.


Wouldn't call myself a SQL expert. Though not inexperienced either. But as
it
is not my every day job to create datamodels or sql queries I struggle at
first
to make a good setup. Hence the question for some assistance in this ;-)


> By no means should you try to migrate your one-and-only production box to
> SQL-driven unless you are into SM & Bondage as well as SQL!
>
> I like the pain, and ofcourse I would like to share my pain with my users
as
they are just there for my enjoyment... :-) *BOFH*

I guess I still have to create and probably refine, and refine and refine a
datamodel
for this and just start fooling around on a playground system and see how it
all
works.

Thanks for the answer so far :)

Cheers,
Pascal