Trevor Astrope writes: > This is how I did it. Using the logindomainlist was not an option for me, > since I have 5000 virtual domains already configured with unique > usernames, so having them all listed in logindomainlist was not practical > and seems like a spammer's honeypot to me.
If each of those virtual domains has a unique domain name that follows a sensible pattern then the - modifier with suitable wildcards is the right way to go. On our shared servers the access to webmail for domain foo.com is through http://mail.foo.com and so an entry of *:mail.*:- in the logindomainlist does the trick. Instead of a drop-down it populates a text input field with the mail domain foo.com. No drop-down, which would be very slow and would leak information about who our clients are to all the other clients (some of our clients are business competitors of other of our clients). The idea of assigning every single user a unique username is a horrible way of doing things. You can't let each domain maintain their userlist themselves using something like qmailadmin and they have to trouble you each time they want to add a new user (if you wanted to place a limit on how many users a domain can have there are better ways of doing it). You also get the problem that users have to remember that just because they're [EMAIL PROTECTED] their POP3 username is not fred or [EMAIL PROTECTED] but instead it is waq37v. Most users pick a password they can remember but with your method every time Outlook trashes their e-mail details they're going to have to ask you for their username again because they've lost the piece of paper they wrote it down on. Last week I migrated a company from their ISP's mail system where each user had picked up mail with a username like xar28v and I thought their ISP had done it that way because the techies there did not know about sqwebmail/vpopmail/qmailadmin and had essentially put together a nasty hack around a MTA that did not directly support virtual domains. Never did I dream that they might have forced that horrible system on top of sqwebmail/vpopmail, but now I have to wonder if that's what they did. The only worse way of implementing virtual domains would be to insist that the local part of the mailbox name is unique so that if somebody grabs sales for his virtual domain then none of the other virtual domains can use it. I've seen a system set up that way too and thought the people who did it were idiots. > Also, I needed pop to use the same authentication method, so it wasn't > practical to force 5000 users to change their email configurations to > include the domain in their pop configurations. Well, yes, it's too late now. But with a little thought beforehand you could have done it the sensible way... > It's not pretty, but it works. For some value of "works." Even setting up virtual domains the sensible way and then putting aliases in place to deliver [EMAIL PROTECTED] to [EMAIL PROTECTED] would be less broken than all the kluges you had to put in place to get your method to work. You are understating the case when you say your solution is not pretty. Many people have put in a lot of time writing sqwebmail, vpopmail, and qmailadmin (not to mention the alternaive webmail packages, alternatve mail admin web interfaces, and alternative mail delivery packages) so that you can implement virtual domains in a sensible manner. You're proposing a system that means more work for the server admin and more problems for end-users while gaining nothing (that I can see) by doing it that way. What on earth possessed you to ignore all the support for doing virtual domains properly and come up with a horrendous bodge like that? What gives you the idea that you're doing anyone any favours by encouraging others to do the same? If I had locked myself into a setup like that through ignorance and only later learned I could have done it more sensibly and with less hassle for everyone concerned I'd be trying to conceal the fact, not offer my bad solution to other people. -- Paul Allen Softflare Support
