on 2/28/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Thursday 27 February 2003 13:01, George Shaunfield wrote: >> Jesse, I want to say thanks for the work you have put into enhancing >> Sqwebmail. While my use is pretty simple, I know there are many who will >> benefit greatly from the new logindomainlist improvements you have made. >> Many of the features went beyond your particular need in order to benefit >> the greater Sqwebmail community. Thanks for giving of your time and >> expertise to all of us. > > You're welcome! I needed new functionality for my company, and I figured that > the best way to get that functionality included in the distribution would be > to write it as flexibly as possible in order to accomodate as many individual > community needs as I could. Hey, I may need that functionality sometime in > the future too! > > I encourage EVERYONE who could use this functionality to TEST this patch on > their systems! I am a fairly decent C programmer (6+ years of non-professional > experience), but I have VERY LITTLE Unix experience, and I would like to > verify > that my code is properly portable to all of the platforms that sqwebmail runs > on. (I run FreeBSD 4.7-RELEASE on all of my boxes) > > All of the functions I used for string manipulation are ISO/IEC 9899:1990 > compliant, but I don't really have any idea what that's worth! TEST TEST > TEST! And together we'll insure that this functionality runs as smoothly as > possible in sqwebmail builds now and in the future. > > I'll try to release some documentation for the distribution soon. > > Sam, if you could just glance over my code for any obvious compatibility > issues, I'd appreciate it. > > Also, if anyone is still really hurting for functionality, NOW IS THE TIME to > mention it! The worst that can happen is that I'll say "heck no, write it > yourself!" If you never mention it, then I probably won't think of it on my > own. And if you wait too long, I'm more likely to say "no" because I won't > remember my code as clearly.
Well, after having a day off, I want to come back to the other issues I was bringing up. In fact, you have implemented everything you need, everything I _really_ need, most things that others came up with, with some extra growing room. So let me join everyone else in thanking you for pulling that all off, and in very little time. When I was in the thick of trying to assimilate it all a couple days back with not enough time available, I think my words were a little rough. What I really want to offer at this point is to to clean up a couple things for posterity, even if it is just icing on the cake. I won't go deep into the details here, but I think there are advantages to having a single concept that handles everything it can rather than introducing additional options. And the wildcard concept you have already picked is quite capable of doing it, so I say let's just do it. I only propose this on the basis that there will be no disadvantages, and that you will like the result. And you _don't_ have to do all the work yourself! Here is what I propose. Let me test your latest, look at your code, and see if I can come up with some minor changes to that code that will accomplish what I am suggesting. Then I'll run those changes by you first. If you find disadvantages, then we just forget it. If it turns out ok, you can leave the next patch release to me if you want, or do it yourself. In the meantime, if you want, we can discuss the actual user-interface (logoindomainlist file) details on the list. I'll just summarize here briefly what I would like to see. I would like the wildcarding implementation to be "complete" by the following criterion, which I will describe in terms of how the doc will look. I would like the documentation to be able to say (not in exactly these words) that you can do anything you want using a single wildcard (*) appearing anywhere in the second field, when used to match against HTTP_HOST, and if a * appears in the first field, it stands for whatever the * matched in the 2nd field. But the * is not required to appear in the 1st field, which can even be blank. I see several advantages: (1) it allows the allvirtual option to go away (2) it avoids needing to add what you were describing 2 days ago as the '-' modifier (3) it probably allows one more feature, important or not, that I don't think was brought up, which is to map several web domains via wildcard onto a single mail domain - perhaps useful if you have a .com/.org/.net combo but don't have aliased mail domains (4) maybe by fully implemeting wildcarding it allows something else we haven't thought of yet Though I am being spare on details here, I think I have learned from experiences over the last week that for the participation of the whole list to work well, it is good to have the details spelled out in examples. So if you approve, I will write something up in the next couple of days. I might want to install your latest patch first, so I can see the code and have the implementation in mind. I certainly don't want to go ahead without your approval, since there is no point in fragmenting the community by moving without consensus. Thanks again for listening. -Kurt Bigler > > Thanks everyone! > > Enjoy the new code! > > Jesse > > >> >> George >> >> Jesse Guardiani writes: >>> Greetings list, >>> >>> Submitted in this email, for your testing, is the second incarnation of >>> my logindomainlist patch. As before, this patch is against >>> sqwebmail-3.5.0.20030215. You'll need to download that version to apply >>> the patch. >>> >>> What's New? >>> ----------- >>> >>> 1.) First and foremost, wildcarding is now supported in the first and >>> second fields. Just remember to specify the '*' modifier in the third >>> field. Here are some wildcarding examples: >>> >>> *:mail.*:* >>> *.org:mail.*.com:* >>> mail.*:*:* >>> >>> The above are all valid. Whatever matches the asterisk in the second >>> field gets inserted where the asterisk is in the first field. Otherwise, >>> this functionality is similar to using the '@' modifier. A hidden field >>> is generated, along with a text display of the domain to the right of the >>> userid field. >>> >>> >>> 2.) You can now specify a domain as an 'explicit non-default domain' with >>> the '-' modifier. This means that if you wish to exclude a domain that >>> would normally included by a wildcard record, but you DON'T want this >>> record to set a default domain (for system accounts and such), just put a >>> '-' in the modifier field. >>> >>> Example: >>> >>> domain2.com:mail.domain2.com:- >>> *:mail.*:* >>> >>> In the above example, mail.domain2.com would normally become a default >>> domain of domain2.com because of the wildcard record below it. However, >>> since we've inserted a '-' modifier, it now becomes an 'explicit >>> non-default domain'. No hidden fields, no drop downs, no text. Just a >>> login field. >>> >>> 3.) In my previous logindomainlist patch, the drop down list would appear >>> even if no records matched HTTP_HOST or SERVER_ADDR. The very existance >>> of the logindomainlist file triggered the drop down. >>> >>> This is now fixed. If a match isn't found, a default isn't displayed. >>> Period. >>> >>> Testing >>> ------- >>> >>> Honestly, I've tested this patch pretty thoroughly. It should be quite >>> capable. However, as with any code (especially C), my debugging skills >>> aren't perfect, and surprises sometimes happen. I'd like to see as many >>> people as possible test this patch so that I can verify it's solidity. >>> >>> Documentation will hopefully follow tommorrow. >>> >>> Also, please note that this will probably be the last major release for >>> this patch. I may release another patch with built in vpopmail IP-alias >>> support in the future, but until then, this is it! >>> >>> Happy testing! >>> >>> And good luck! >>> >>> -- >>> 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.
