"Jim Ramsay" <[EMAIL PROTECTED]> writes: > Well, according to tmda-ofmipd (off which I am basing most of the new > Auth.py), the "vhome script" takes two arguments: the username and the > domain, and returns the resulting home directory.
This is correct, although I'm afraid that part of the documentation is the example script. I haven't had time to document this in detail yet. For instance, although both the VMailMgr and VPopMail scripts take the username and domain on the command line, vpopmail-vdir.sh pastes them back together whereas vmailmgr-vdir.sh is, well, a lot weirder :) > If I'm reading the code correctly, tmda-ofmipd requires that a username used > for logging in for a virtual user be [EMAIL PROTECTED], not just > billybob. This isn't exactly correct, but it's close. VPopMail can be configured to use IP-based domains, where the IP that the user logs into causes a mapping to occur to the domain. This allows users to simply use 'billybob' as their login name. It also obviously restricts which domain 'billybob' is a member of, so there won't be any clashes between identical usernames, since there is only one domain. Second, VPopMail can be also be configured to use a default domain. Again, if this is true, a simple username (no domain) can be used and the domain will default to the default domain specified at compile time. I must admit I have no idea what happens if you try to configure both a default domain and IP-based domains in the same build. Most of this I've gleaned by reading the VPopMail code. In the final case, where multiple virtual domains are hosted on a single IP, users have always had to include the domain as part of their login name. This is true with VMailMgr as well. > tmda-ofmipd also checks the domain part of this login username against > qmail's virtualdomains file, but I don't know if this is necessary. Any > thoughts? This is only the case in the code path that supports VMailMgr, because of a different implementation of virtual domains. VMailMgr uses a system account (UID) per virtual domain. VPopMail is usually configured with all virtual domains under a single UID. Part of the task of building good software is understanding all these crazy idiosyncrasies and supporting them all. The virtual domain support initially took me longer than I'd planned because I had to research all this stuff. To be perfectly honest, I'm not at all sure that I have it 100% right. It's mostly right, I think, but there are no guarantees! Jim, if you're working on this for the Auth.py module and you come across anything weird, please feel free to ask me here on -workers and we can try to figure out what to do. > Does the authentication mechanism then (whether it be file, checkpassword, > or remote) expect that the username passed to IT is [EMAIL PROTECTED] > I'm going to assume for now (unless told otherwise) that this is what it > expects because I don't know what else would make sense. Heh. Again, yes and no, for exactly the same reasons given above. For instance, if a system admin has 10 IP aliases on a box and has compiled VPopMail with IP-based domains, he can tell the users of his 10 different domains to use, e.g. pop.dom1.com, pop.dom2.com, etc. as appropriate. He or she would also tell them that their username was just the simple username, no '@dom1.com' or '%dom1.com'. The upshot is that the simple username is what tmda-ofmipd would see in that case. As long as VPopMail is properly configured to work in the absence of tmda-ofmipd, all authentication mechanisms should work. You can even mix and match in the same VPopMail installation; you can have some IP-based domains and a whole set of others on a single IP. Obviously, then, you can't ever assume that there is or isn't a domain portion on the end of a username. You can try to pull it off, if there's a reason you need it, but just because it's not there doesn't mean anything's wrong. Great fun, huh? <grin> Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
