It would probably help if I spelled "virtdomains" correctly in the imapd.conf file... I had been using "virtualdomains" instead and not surprisingly that was doing nothing. But I AM surprised that no error message is produced when an unrecognized option is specified (that would have saved me a lot of trouble). I guess I can see the logic behind that if options that are applicable to a particular module are specified but the module is not loaded - you wouldn't want errors being produced simply because an optional module was not loaded.
Anyway, my current configuration requires the following settings to work properly: virtdomains: userid defaultdomain: imap.sample.domain.com loginrealms: imap.sample.domain.com This is fine, but in the real world our email addresses are of the form "[email protected]" and our MX mail exchange systems (which serve the "sample.domain.com" domain) redirect emails to the actual IMAP server which is named "imap.sample.domain.com". It would be nice if our users could use either domain as their login ID, and *loginrealms* allows this: loginrealms: imap.sample.domain.com sample.domain.com However, *virtdomains* only works if *defaultdomain* is specified, and *defaultdomain* only allows one value. This seems incorrect. I would expect *defaultdomain* to only be used when a local-part (e.g. "person") login is specified, then the concatenation of "person@<defaultdomain>" would be used as the login name (and compared against *loginrealms* as it is when a user specifies a full email address). Why allow logins against any domain listed in *loginrealms* to succeed if the code turns around and rejects any that aren't the *defaultdomain*? ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/Tae2b59346d586220-M3177ed61de6d68b42a5d5143 Delivery options: https://cyrus.topicbox.com/groups/info/subscription
