----- 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

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
>
>
>


Reply via email to