virtdomains and defaultdomain issue

[Jorey Bump]

Edwin Boersma wrote, at 02/23/2009 07:43 AM:
> Hi,
> 
> Just to make it clear: the problem only occurs with the default domain,
> not with other virtual domains. All user are in the SQL database, and
> cyrus does a correct translation to the mailbox for all the others. The
> only problem is that the default domain is replaced with the local
> computer name.
[snip]
> In my opinion (can you give me yours, Andrew?), cyrus should not rewrite
> the default domain when using %r, but internally redirect to the local
> mailbox (so after login). Or provide a mechanism where the local mailbox
> is transformed into a virtual domain box.


>> 2009/2/18 Edwin Boersma <edwin.boersma at secureoffice.net>:
>>   
>>> Hi,
>>>
>>> To be able to have user names like <user>@<our.domain> and
>>> <sameuser>@<another.domain>, I have changed our IMAP config to use virtual
>>> domains. To be able to access the existing mailboxes, I added the
>>> "defaultdomain" option to imapd.conf.

You will probably also want to set servername to prevent cyrus from
using gethostname:

>>> Here's the imapd.conf:

>>> defaultdomain: secureoffice.net

  servername: secureoffice.net


Is there a problem you are trying to solve with user at domain logins? In
most cases, this is done to support similar logins across multiple
domains (support at example.com, support at example.net, etc.). However, I
find that this confuses clients, who will try to use alias addresses as
logins, and prefer to assign unique logins across all domains
(foosupport, barsupport, etc.). This way, I don't need to enable
virtdomains in Cyrus IMAPd, and just put everyone in the same realm (a
single arbitrary domain, it doesn't even need to exist in DNS or accept
email). Then I set defaultdomain and servername to that realm in
imapd.conf along with smtpd_sasl_local_domain in the Postfix main.cf. As
a result, all lookups are done against this single realm and users can
authenticate with a bare login without appending the realm. This
approach still supports multiple email domains, but simplifies
configuration and may even improve portability (but I'm using sasldb,
not SQL, so there may be other issues I'm not considering). The only
caveat is that all logins must be unique; two users of different
accounts can't each login as "support". On the other hand, this
arrangement has come in handy when we've had to replace heavily spammed
public addresses like info at example.com with information at example.com,
because it isn't necessary to change login credentials in the client. I
only mention this as an alternative, in case you really don't need to
support full user at domain logins.