on 2/22/03 5:34 AM, hzqbbc <[EMAIL PROTECTED]> wrote: > Hi bigler: > May i have your patch ? I have the same need as yours :)) and you done it, > I will appreciate for your kindness if you send me that patch. :) 3q!
Well I got involved today in discussing all this with Jesse Guardiani today and I didn't have time to create a patch for the latest version. Meanwhile Jesse has now come up with something which should include the functionality of my patch, which will be part of the official version soon. Jesse said he would post the patch in the next couple of days. I will try his patch on my system tomorrow, and if it works, I will let you know - or you can also try it yourself. You may need to upgrade if you don't have the latest. The latest release is SqWebMail 3.5.0. Plus there is something called SqWebMail 20030215. I suspect this is an interrim test version but I'm not familiar with the scheme. I don't know whether SqWebMail 20030215 is a patch or a full install. I don't know whether you will need SqWebMail 20030215 or just 3.5.0. Maybe Jesse can clarify this for us. In any case something good is coming soon one way or another, but I don't want to do redundant work, so I'm waiting to try Jesse's patch whenever he finishes it, which I think he said might be tomorrow. -Kurt Bigler > > > Kurt Bigler writes: > >> on 2/21/03 8:55 AM, Dale <[EMAIL PROTECTED]> wrote: >> >>> I am trying to figure out if there is a way to have >>> the login automatically send a default domain for >>> domain based templates. >>> ie: www.domian1.com when using that webmail the login >>> name automatically sends [EMAIL PROTECTED] >>> >>> and user using thisdomain.com when logs in >>> automatically sends [EMAIL PROTECTED] without having >>> to enter the @thisdomain.com or @domain1.com >> >> I have worked out a solution _related_ to what you are asking about. The >> solution involves a change to the sqwebmail source. I am planning on >> researching how to make this change as general-purpose as possible and >> submitting it as a change to sqebmail. Since you asked this question, I >> will go ahead an start this research now, and will appreciate anyone's >> input. Meanwhile what I write here may help you solve your problem right >> away, if I have not misunderstood what you are asking. >> >> I do not have per-domain templates. However, for each mail <domain> I have >> a distinct webmail domain of the form "webmail.<domain>". >> >> The sqwebmail website domain is available to sqwebmail through the HTTP_HOST >> environment variable. >> >> I am currently making this work in combination with the logindomainlist >> feature, wherein the file /usr/local/share/sqwebmail/logindomainlist >> (perhaps path may vary) triggers the presence of a popup list of domains for >> the user to chose from when logging in. There are other ways to do this, >> however this approach will suffice as an example. I wanted to arrange that >> the popup list of domains would default to a domain that "matches" the one >> obtained from the HTTP_HOST environment variable. This required only a few >> lines to be added to sqwebmail/sqwebmail.c. However, the code I use >> currently depends on the "webmail." convention that I use, wherein I have a >> webmail subdomain for each domain that supports webmail access. >> >> I would like to solicit input on how to make this more general, possibly >> also supporting a situation in which the popup domain list is not involved. >> With per-domain templates, this could be accomplished via a hidden field in >> the template which specifies the mail login domain to be used. However, I >> would also like to chose an approach which does not depend on a per-domain >> set of templates. >> >> It occurs to me that an easy solution might be to set a WEBMAIL_LOGIN_DOMAIN >> environment variable per apache virtual domain. I actually haven't >> investigated how this is done in apache yet - I have heard it is possible, >> but have not even confirmed this. >> >> >> So to summarize the possibilities, there are two aspects to the problem: >> >> >> 1. How to determine the mail login domain, or (if applicable) the default >> mail login domain. There are 3 possibilities I can think of: >> >> * to infer it from the HTTP_HOST environment variable, by some matching >> process >> >> * to get it directly from a per-domain WEBMAIL_LOGIN_DOMAIN environment >> variable >> >> * to allow it to be specified as a hidden field in the template >> >> One or more of these possibilities could be supported, but of course I don't >> want to add undue complexity, so if any one of these represents a good >> general solution then that is the one to use, I think. >> >> >> 2. In the case of the first two possibilities above, there would be various >> options: >> >> * to use the mail login domain obtained as described as the default for the >> logindomainlist popup >> >> * to use it directly - not as a default - allowing the user no choice of >> mail domain >> >> * to use it to set a separate editable-text domain field, which I believe >> does not curently exist >> >> >> I can send in a patch for what I have currently done, if anyone is >> interested, but I need to come back to that later. >> >> >> -Kurt Bigler >> >> >> >> >> >> > >
