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@xxxxxxxxxxxxxxxx>: >> >>> 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@domain logins? In most cases, this is done to support similar logins across multiple domains (support@xxxxxxxxxxx, support@xxxxxxxxxxx, 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@xxxxxxxxxxx with information@xxxxxxxxxxx, 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@domain logins. ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
