on 2/21/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> On Friday 21 February 2003 15:26, Kurt Bigler wrote:
>> on 2/21/03 11:33 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>> On Friday 21 February 2003 13:58, Kurt Bigler wrote:
>>>> on 2/21/03 10:07 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>>>> On Friday 21 February 2003 11:55, Dale wrote:
[snip]
>>> The method I am working on (mostly in my head right now) will consist of
>>> a comma
>>> or colon delimited flat file, with one IP:DOMAIN pair per line, as in the
>>> example
>>> below:
>>>
>>> IP1:DOMAIN1
>>> IP2:DOMAIN2
>>> etc...
[snip]
>> My server is set up to do name-based virtual hosting, and so I haven't had
>> experience with anything else. My server has only one IP address. Does
>> what you are suggesting apply to this situation? Perhaps you are solving a
>> problem at an entirely different level from the one I was trying to solve.
>>
>> So to clarify, what I would envision as a alternative to what you were
>> suggesting, but which would solve the problem I need to solve, would be a
>> similar table:
>>
>> webmail-http-domain-1:email-login-domain-1
>> webmail-http-domain-2:email-login-domain-2
>> etc.
>>
>> Where the first field is the HTTP_HOST value and the second field is the
>> associated login domain.
>>
>> This is because I do not want to assume that it will always look like this:
>>
>> webmail.somedomain1.com:somedomain1.com
>> webmail.somedomain2.com:somedomain2.com
>> webmail.somedomain3.com:somedomain3.com
[snip]
>> How does this relate to what you are doing?
>
> It doesn't. My solution will only be applicable to IP based domains.
>
> Can you currently log into IMAP or POP3 on your domain without specifying
> [EMAIL PROTECTED] as the userid?
Absolutely, but of course it is not a login to IMAP or POP3 but into a
Maildir, whose contents could have been put there by any means.
So yes, I started by using the logindomainlist feature, so right away
entering [EMAIL PROTECTED] was not necessary, but I still had to select the domain
from the popup list. But then I changed sqwebmail.c so that it would set a
default value for the popup list by recognizing the list item that matched
HTTP_HOST with "webmail." prepended. As I said, not a general solution yet.
But in any case, it is good that you are working on the _correponding_
problem, but for IP-based rather than name-based hosting. Because I'm
almost sure all the external configuration issues will be analogous. In
fact I suspect the implementation will also be analogous, i.e. that the same
files will be touched in roughtly the same places to solve both problems.
I suspect that the same configuration file could specify either a name or an
ip, and accordingly you would match it against either SERVER_ADDR or
HTTP_HOST. Once you do a lookup in either case you are determining a login
domain NAME, so the rest of the implementation should be identical.
Can I get you to buy into the idea that this can all be done using
logindomainlist? Use records of one of two formats:
logindomain:http_host:popup_flag
logindomain:server_addr:popup_flag
Perhaps name and ip-based virtual hosting can't coexist on the same server
(can it?), in which case what I am proposing here is overly general solution
with redundant information, i.e. every record basically specifies whether
name or ip-based hosting is being used. But still perhaps this is ok. I
think it is friendly for the administrator in either case.
If I'm right then you could trivially include the name-hosting solution when
you code what you are working on. I will be glad to test it and work on it
as needed, but we might as well do both things at once if at all possible.
Only problem may be that our schedules won't coincide and the process will
take more time. But 9 chances out of 10 your solution will just work for
the name-based situation if you just keep in mind HTTP_HOST as well as
SERVER_ADDR. But if you want to code yours first and pass it to me, that is
also fine. If I'm not missing something big here, I can turn it around
fairly quickly.
Let me know. I'll be around on and off this afternoon, until 5 or 6 pacific
time.
-Kurt Bigler
> If you CAN, then I will try to figure out what vpopmail is doing to facilitate
> this functionality. If you CAN'T, then I don't think it will be unreasonable
> of me to implement this solution for IP based domains only.
>
> You could implement a string matching operation as you mentioned above. But
> I don't run virtual DNS domains, so I wouldn't be the person to code it.
>
> I'd be happy to discuss implementation issue with you though. :)
>
> Jesse