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 "person@xxxxxxxxxxxxxxxxx" 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?
