Please change the DNS lookup = defaultdomain process, and use defaultdomain as the default domain.

josh at endries.org josh at endries.org
Wed Jul 1 10:14:15 EDT 2009


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 at blah.com" 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 at blah.com, 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...



More information about the Info-cyrus mailing list