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

[josh at endries.org]

Sigh...correction:

Using the unqualified name still appends the DNS domain, not the  
specified defaultdomain. However, now I can login using  
admin at mail.blah.com whereas when the passwords were the same, it used  
admin at blah.com first and never logged me in as @mail.blah.com. Now at  
least it (I'm guessing) fails as admin at blah.com and then tries  
admin at mail.blah.com as typed, which works. (my defaultdomain is  
"something.fake" right now BTW).

Josh

Quoting josh at endries.org:
> 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...
>
> ----
> 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
>