on 2/26/03 2:10 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Wednesday 26 February 2003 16:40, Kurt Bigler wrote: >> 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: > > <snip> > >>> *: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. > > Yes. This is the "simple to implement" method. The first method I chose. > >> >> 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. > > You hit the nail on the head. I like to build on the code I've already > written. > Once I implemented your suggestions for the logindomainlist file, my mind > instantly started exploring the possibilities beyond that, and now that it's > not that large of a mental jump to envision, I'm willing to write it. > > Some functionality is better envisioned from the top down, but in this case, > I think it was better to write it from the bottom up, using a file format > that is flexible and capable of future change. > >> >> 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? > > Maybe. But I think I'm going to keep it simple. Implementing this simple > wildcard functionality will, I think, solve 98% of the generic problems > that people will encounter with email domains. In the future, replacing > the wildcard functionality with regular expression matching is possible, > but I have other projects beating on my door, and I have to wrap this up > quickly. > > The wildcarding algorithm I've been toying with for the second field will > simply remove everything before the asterisk, and everything after the > asterisk from the beginning and end of the SERVER_ADDR and HTTP_HOST > variables, respectively, BEFORE attempting a strcmp() function. > > In the first field, whatever was eventually matched in the second field > will be inserted where the asterisk is. Or, more programmatically, everything > before the asterisk and everything after the asterisk will be prepended > and appended, respectively, to whatever string actually passed the strcmp() > function from the second field. > > This will be easy to implement, and should offer enough functionality to > keep 98% of the administrators out there happy. > >> >> 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! :) > > And the most difficult to code in C. I've never seen C regular expression > code. > I'll have to look some up sometime. > > Either way, that's not the route I'm taking. > >> >> 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! > > Great! If you can't think of any problems, and I can't think of any problems, > then it might actually be a decent idea! I'm going to try to code it tonight. > My boss is pushing me to finish this nonsense up!
Actually, I didn't mean to imply that there were no problems elsewhere in this idea. Actually I think it has gotten (to me) more complex by a factor of 10, so that I can't imagine jumping into implementing it. It seems to me there are several levels of new issues here. And with all the emails flying by I'm not sure where all the issues stand. I would kind of recommend bouncing a "final" spec around - a spec which includes all the features in one message - until it truly becomes final. Lacking time to fully analyze what appears to me as all the outstanding issues, and not sure even which issues have been decided, I will make a few comments hoping to help in spite of my lack of preparedness (and time) right at this moment. So this is kind of a scattered list of responses: I would be concerned about any implicit prefix being removed from HTTP_HOST. It sounded like this was going to be done. There were some things that it struck me are much less orthogonal than they could have been, regarding handling name-versus-IP-based hosting. The previous approaches have so far been totally symmetrical. I like the idea of using single characters rather than fully-spelled-out options, i.e. v rather than vpopmail and a rather than allvirtual, because that allows for any combination of options to coexist when they can. Otherwise I think they should be separated by spaces or some other delimiter. Some of these options deal with setting environment variables. I seem to recal someone suggesting another environment variable need that I don't recall being addressed in the current set of options - but I'm not sure. Anyway what I'm getting at... now I have to start thinking out loud - so don't just anything until I finish because I think this is leading somewhere. This is a recap of my train of thoughts about this... So rather than having implicit environment variables, why not let people just give the name of the environment variable to be set. This would allow people to set variables in custom ways depending on the domain matching process. Now some commentary... the whole reason this line of thinking came up is because it sounds like a bunch of special cases are being introduced, in spite of a potentially very general option syntax, each option is doing something special, involving hard-coded values (e.g. names of environment variables). So that's why I wanted to generalize it, but then the generalization almost leads to putting a little scripting language inside logindomainlist, and there is NO END to where that leads. The potential categories for options and what they do (besides setting variables) could go on and on. Regardless of which approach, you might be introducing here a "platform" that creates the need for repeated additional enhancement in response to yet-unforseen needs, on all too regular a basis. Did you notice the level of the new buzz of ideas that has arisen today? This suggests to me 2 things: (1) This is no time to start implementing. Better to get back to work and return to this in a week. Otherwise it is likely you are just creating more work, and whatever you do now will become the defacto state of things because you will have run out of time to do more. I for one don't believe I have assimilated a third of what went by today. So if you go ahead you are going without whatever benefit my full understanding might offer, for what its worth. (2) It would be good to put a "cap" on the degree of potential enhancement. One very satisfying way to put a cap on this, is I think to provide a "hook" so everybody can get what they want without your ever needing to enhance this again. Here are two possible hooks that I can think of: * If logindomainlist is executable, execute it. Execute it honoring the mechanism used by shells, honoring the initial #! line. The entire cgi environment gets passed into this executable, plus arguments or more environment variables for additional info that is available to SqWebMail, if needed. This executable can be written in perl, shell, C, etc. It can set environment variables to its hearts content, log webmail logins, you name it. It can do all the things that logindomainlist would have done as a text file, by using if/else logic. It can do all the things that otherwise you would be tempted to create another patch to do. (Actually I guess as a child process it can't create environment variables that are passed back to you - is that right? If so it could still write to standard output the needed information.) In any case having this hook allows you to avoid indefinite proliferation of enhancements. Perhaps it even allows you to dismiss some of the ideas just proposed, and simplify what you were about to approach doing. * The other possible hook: the logindomainlist text file contains a field (maybe another field, maybe just part of the modifier field) with the name of an executable file which can then be determined by the domain matching logic. It could do the same kinds of things as the "main" logindomainlist executable, except driven by the domain matching logic. Ok, this was pretty raw, but I have to go. I hope you haven't started implementing already! I hope some of these ideas might save some trouble. Thats all for now. -Kurt Bigler
