migrating to virtual domain support

[Stefan Palme]

Hi Torsten,

thanks for your answer - I guess the "imapsync" stuff is exactly 
what I'm looking for. 

But I want to discuss some of your hints regarding whether or not
to use the "real" virtual mailbox approach:

> I once built a larger system that way and I am suffering from that
> until today. So my takeaway was that I would never do it again that
> way, for a number of reasons. Well, it heavily depends on what kind of
> system you're running and for whom.

We are no ISP or something like that. We are a software development
company, and some of our customers want us to host their email accounts.
All in all there are no more than 50 domains with at most 10 accounts
per domain - so its really "tiny" :) 

The mail systems runs on a single linux box using Postfix, Cyrus-IMAP-
Server, an OpenLDAP server for storing user accounts and the SASL Auth
Daemon for glueing all this together.

> I have built a newer, large system by using entirely domain agnostic
> mailbox names, i.e. xxxYYYYY where xxx is a prefix and YYYYY is just
> an ID number. They have nothing to do with email addresses.

I've taken this approach into account, too. But our customers are
very - hrrm - "special" ones who don't like logins like "dom1203859",
instead they insist on using easy to remember accounts like
fred.domain2 (old style) or even better fred at domain2.com
(new style). 
I guess it does not make sense to discuss about this attitude - it's
just one thing that took be towards using virtual domains...

> We moved the email address -> mailbox name conversion entirely into
> the MTA, which gives you way more flexibility. Someone wants an
> additional email address? No problem. Someone wants to change the
> email address while keeping the mailbox untouched? (Think people
> changing their names after a marriage or divorce, for example.) No
> problem.

The email address -> mailbox name stuff is in the MTA in my solution,
too. The email address which is used as IMAP auth name has nothing
to do with the real email adresses. The MTA maps all the valid email
addresses fred at domain2.com, f at domain2.dom and fred at otherdomain.com
to the IMAP account fred at domain2.com (the IMAP account name could 
even be fred at domain2.invalid - the domain part is only used to 
distinguish users, not for really sending or receiving any mails).

So the email addresses used by the outside world are independent
of the mailbox name in the IMAP server, so additional email addresses
would be no problem.

The only "ugly" thing concerning this: when a user has the IMAP 
mailbox account fred at domain2.com, and the holder of domain2.com
decides to use betterdomain.com from now, the user still had to 
login using the old name fred at domain2.com - which may be a little 
big ugly and confusing.

(But when I know how to rename mailboxes, this would be no longer
a problem).

> And the #1 issue we have been facing with virtual domains: We do have
> lots of users who have their domain registered in multiple TLDs but
> use one local namespace, i.e. they want to have mail for
> johndoe at acme.com / johndoe at acme.net / johndoe at acme.de go into the same
> mailbox.

In this case one of these email addresses could be the ID for the
IMAP account (like johndoe at acme.com or even johndoe at acme), and 
ALL these email addresses can be mapped to this account.

> I need to make you aware though that this concept introduces extra
> complexity when it comes to authentication. You will need to use a
> SASL canon plugin to turn the email address into a mailbox name for
> IMAP auth and potentially also for SMTP auth. (Has nothing to do with
> Cyrus IMAPd, but should be left out.)

This is no problem here: user accounts are stored in an LDAP server
in the following structure:

  ROOT
    ou=domain2.com
      cn=fred
    ou=otherdomain.com
      cn=alice

Using saslauthd with the LDAP backend and appropriate configuration
this makes it very easy to have user accounts fred at domain2.com and
alice at otherdomain.com. Since both Cyrus-IMAP-Server and Postfix
can use SASL based authentication this solution is absolutely
straightforward and works for IMAP authentication as well as for 
SMTP authentication. 
The only thing one has to remember when thinking about all this is: 
the  account IDs for IMAP and SMTP "look like" email adresses (because 
of the @), but they don't need to be related to real email addresses.

As mentioned earlier, this part is already solved and working...


Best regards
-stefan-