on 2/26/03 8:38 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> ----- Original Message -----
> From: "Jesse Cablek" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, February 26, 2003 10:51 AM
> Subject: Re: [sqwebmail] new file proposal
>
>
>> Jesse Guardiani wrote:
>>> Greetings list,
>>>
>>
>> How about in the "MODIFIER" field of your current patch? In addition to
>> a * you can have characters added.. *v would mean what * currently
>> means, AND use vpopmail as the default, *a would use allvirtual as
>> default, just straight v would be different, etc.. or however it's
>> setup. All you need to do is check the modifiers one char at a time to
>> see how to process that specific line.
>>
>> Also make sure that if someone sets more than one default, then have it
>> just use the first in the list in the given alias/group.
>
> Hmmm... so you're a one-file-only kinda guy too eh? :)
>
> This might work if we use wildcards in the fields as Martin suggested. In
> that case, the following record:
>
> *:mail.*:*allvirtual
As most of the previous examples over the last week or so have illustrated,
this is exactly the kind of thing we were already trying to accomplish in
many cases by listing all the domains explicitly, i.e. in my case
essentially to "remove" all the "webmail." prefixes in order to obtain the
login domain.
You had already balked at regular expressions, so I didn't even dare to
mention this yesterday! I guess you're a one-change-at-a-time kind of guy.
Would you do this exactly the same way that shells do globbing? Of course
there is no need to special case domains starting with a ".".
You are going one step farther than globbing by using "*" on the replace
side of the equation. Hmm... remind me, is there already precedent for this
in unix somewhere?
Globbing normally involves the possibility of more than one "*". Do you
need this? It might present some troublsome ambiguities for the replace
side fo the equation.
Regular expressions would of course, provide the most general solution! :)
In any case I tried to think of a counter-example - something that wouldn't
work in this approach, but I only came up with another situation that DOES
work, which I'll mention anyway. Suppose some company hosts all mail
domains as subdomains under their company domain name. So in this case the
non-wildcard-based logindomainlist would look something like this:
domain1.org:domain1.org.thewebmailcompany.com
domain2.com:domain2.com.thewebmailcompany.com
In this case the wildcard approach would look like this:
*:*.thewebmailcompany.com
which works fine!
-Kurt Bigler
> Would suggest that we first check for an HTTP_HOST string that includes the
> substring 'mail.' at the beginning, then remove the 'mail.' substring from
> the beginning of the HTTP_HOST string, and use the remaining string as our
> default domain.
>
> Now, with the way the file is currently processed, this would mean that all
> further evaluation of the logindomainlist file would cease for any domain
> that matches 'mail.*'. So these records should appear at the END of the
> logindomainlist file if you wish to attempt a match on other records first,
> or override your default entry.
>
> I think I like this idea. It won't be overly difficult to implement, and I
> believe it will solve two problems at once (Martin's 'mail.' quandry, and
> Tim's need for default domain support).
>
> Also, I'd like to make the '*' modifier mean something different than it
> currently means. It like to designate it as the 'defaultdomain' modifier and
> make the '@' symbol the 'hidden field' modifier.
>
> Why? Because I think the behavior of the '@' operator is ALWAYS desirable
> over the behavior of the current patch's '*' operator.
>
> Does anyone disagree?
>
> Any comments?
>
> If not, then I'll try to start work on this new code ASAP. (which does NOT
> mean it'll definately be ready today. :-] )
>
> Thanks!
>
> Jesse
>
>>
>> /jesse
>>
>>
>>
>
>
>
