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.
