Sigh...correction: Using the unqualified name still appends the DNS domain, not the specified defaultdomain. However, now I can login using admin@xxxxxxxxxxxxx whereas when the passwords were the same, it used admin@xxxxxxxx first and never logged me in as @mail.blah.com. Now at least it (I'm guessing) fails as admin@xxxxxxxx and then tries admin@xxxxxxxxxxxxx as typed, which works. (my defaultdomain is "something.fake" right now BTW). Josh Quoting josh@xxxxxxxxxxx: > 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 > ---- 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
