Argh, vent time. I don't know if this is fixed in later versions, I really really hope so, but this machine has 2.2 on it. This problem is a huge PITA. I've ran into it before and stumbled across a random (trial-and-error) workaround each time, though I don't remember what they were...I don't change these things very often. The problem, which I believe is a ridiculous bug, has to do with the combination of DNS lookups, defaultdomain and virtdomains. I don't really know if virtdomains is involved, but since I run with them enabled I'll mention it. I have a server, mail.blah.com, serving mail for various domains. The defaultdomain parameter is set to mail.blah.com, though that doesn't seem very relevant--certainly it isn't the "default". The server does a reverse DNS lookup on it's own IP when logging in with an unqualified address (e.g. "admin"), appends the domain name from that lookup AND NOT defaultdomain, and uses that as the effective address for logging in. I happen to serve blah.com out of this machine, and happen to have "admin" as a global admin and "admin@xxxxxxxx" as another user. Amazingly, it appended the DNS domain to my unqualified login and worked! It took me a while to figure out but both passwords were the same, so it "defaulted" to the made-up DNS-based address. When I changed the password for admin@xxxxxxxx, leaving admin alone, and logged in with admin's password, it instead used the defaultdomain parameter as expected and logged in successfully as the global admin user. Holy crap. Nonsense. If anything, that order should be reversed. I seem to remember previously messing with defaultdomain and the machine's hostname to work around it before, maybe using the hosts file, unfortunately I don't remember what I did previously. Some combination of DNS and/or fake hostname and/or fake defaultdomain setting maybe...I know it wasn't due to identical passwords, but it was due to using the reverse DNS lookup as the default domain. I think it really should just simply append the defaultdomain to unqualified login names and try that, and if it doesn't work, fail. That, I think, is expected behavior. Alternatively this procedure should be documented somewhere, like in imapd.conf, to save people hours of frustration... It also makes me wonder what other sorts of wonky things it might do behind the scenes. Now, on to work on my mysterious no-vacation-messages sieve problem... ---- 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
