I know you already refuted your own comments, Jesse, but I just want to reply anyway in order to avoid confusion:
On Wednesday 26 February 2003 11:47, Jesse Cablek wrote: > Jesse Guardiani 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, > >> <snip> > > This might work if we use wildcards in the fields as Martin suggested. In > > that case, the following record: > > > > *:mail.*:*allvirtual > > Isn't this what the domain alias lines you implemented handle? No. Both of the current patches I have released handle direct domain to domain mapping. The example above implements wildcard mapping, which is more flexible than the solution I proposed in the original 'new file proposal' email. It's kinda like an apache rewrite rule, except not as powerful. > Alias mail.example.com to example.com in the domain list and forget > wildcard domains? Or was that functionality removed? > > I thought I remember you mentioning something like: > 127.0.0.1:example.com:* > mail.example.com:example.com:@ > mail2.example.com:example.com:@ > > Or something similar? > > > 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. > > Which may not be good, allow the user to decide which part of the host > to use, mail.example.com could be a legit domain to accept/check mail > for - I had done this having exmaple.com as a virtual domain but > mail.example.com as a local domain so that postmaster/etc.. messages get > sent to @mail.example.com It just depends on how you've set up your domains. If you were smart, then you have implemented all of your domains the same way. If you're consistent, then wildcard mapping should take care of 99% of your domains. The other 1% can be handled by inserting records BEFORE (above) the wildcard mapping to override the wildcard mapping for one particular domain or a small group of special case domains. If you weren't consistent in your implementation of domains, then you're just going to have to enter each domain individually into logindomainlist. > > [...] > > > 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. > > [..] > > I think the * as default is a better option. Maybe thie hidden option > could even be represented as ! or ^ since aren't those commonly used > "not" operators? Too bad. :-] It's going to be @ unless I think of a really good reason to do otherwise. I think that the '*' character is synonymous with wildcarding. That's why it's going to be the wildcard modifier. The '@' symbol is synonymous with email addresses, and when you use it to mark a 'hidden' field domain, you'll automatically see '@whateverdomain.com' next to the userid for clarity. I think the '@' character is more mnemonic for it's function here than a '*' character, especially now that I'm going to be implementing wildcarding. Thanks for the comments! I appreciate ALL input. This patch never would have become what it is without different people suggesting things. > > /jesse -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net We are actively looking for companies that do a lot of long distance faxing and want to cut their long distance bill by up to 50%. Contact [EMAIL PROTECTED] for more info.
