On Thu, Jun 03, 2004 at 11:42:00AM +1000, Joshua Goodall wrote:
Just because you don't use it, doesn't mean that others won't.
That's true. All I meant was, when choosing where to expend development effort, perhaps it would be better to defer working on things which are arguably bad practice in the first place, and for which workarounds already exist (i.e. in this case bind a separate server instance to each IP address).
Now, if you weren't worried about disambiguating usernames, but wanted to select a different certificate for POP3/IMAP over TLS for each virtual domain, then I'd have more sympathy. It's a huge shame that the POP3/IMAP S(TART)TLS commands don't give a way to select a certificate before negotiating TLS. HTTP now does (RFC2817), although I don't know how widely that's implemented.
In our case, those people who used TLS for POP3 weren't willing to pay for their own certificate, so they were happy to share ours (they got a 'certificate name mismatch' but otherwise had a valid signed certificate; that's better than having a self-signed certificate)
However, if all you're trying to do is have POP3 users 'fred' connecting to pop3.domain1.com and 'fred' connecting to pop3.domain2.com be unambiguous, then I really can't sympathise. You really should be making all these users login as 'fred@domain1.com' and 'fred@domain2.com', even if you happen to have different IP addresses available for pop3.domain1.com and pop3.domain2.com; it's no harder for the end-user to configure, and it's shortsighted not to. You'll regret it one day.
Cheers,
Brian.