Re: [sqwebmail] mail filtering issue
This list is dead: the new list is [EMAIL PROTECTED]
http://sourceforge.net/mail/?group_id=5404
on 5/12/05 7:30 AM, Trey Nolen <[EMAIL PROTECTED]> wrote:
> We've got a weird issue going on and I think it is tied to the Sqwebmail
> Maildrop filtering rules. I have had a few people who have mail filtering
> turned on get 10's of thousands of messages overnight. They are all the same
> message, and *SHOULD* be matching one of the rules (although the rule is not
> taking effect). When spam detection is turned off in Qmailadmin (thereby
> stopping Maildrop), they messages stop. We are using Qmailadmin 1.2.3 with
> Vpopmail 5.4.10. Enabling spam detection puts the following line in our
> .qmail files:
> |preline /usr/local/bin/maildrop /etc/mailfilter
>
>
> Our /etc/mailfilter file is:
> VHOME=`/home/vpopmail/bin/vuserinfo -d [EMAIL PROTECTED]
> VPOP="| /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox"
>
> exception {
> include $VHOME/.mailfilter
> }
>
> exception {
> to "$VHOME/Maildir/."
> }
>
> to "$VPOP"
>
>
> We are using Spamassassin to tag messages with *SPAM* on the subject
> line and are instructing users to use Sqwebmail to generate rules to
> automatically move those to a Junk folder or delete the messages. To
> delete the messages, we have users forward them to a special email address
> which goes to null.
> The rule being generated by Sqwebmail and put in the .mailfilter file
> follows:
>
> #MFMAILDROP=2
> #
> # DO NOT EDIT THIS FILE. This is an automatically generated filter.
>
> FROM='[EMAIL PROTECTED]'
> import SENDER
> if ($SENDER eq "")
> {
> SENDER=$FROM
> }
>
> ##Op:contains
> ##Header:From
> ##Value:[EMAIL PROTECTED]
> ##Folder:[EMAIL PROTECTED]
> ##From:
> ##PlainString
> ##Name:spam2
>
>
> if ((/^From:[EMAIL PROTECTED]/))
> {
> to "| $SENDMAIL -f " '"$SENDER"' " [EMAIL PROTECTED]"
> }
>
> ##Op:startswith
> ##Header:subject
> ##Value:*SPAM*
> ##Folder:[EMAIL PROTECTED]
> ##From:
> ##PlainString
> ##Name:spam
>
>
> if ((/^subject: *\*\*\*\*\*SPAM\*\*\*\*\*/))
> {
> to "| $SENDMAIL -f " '"$SENDER"' " [EMAIL PROTECTED]"
> }
>
> to "$VHOME/Maildir/."
>
>
>
>
>
> Most of the time, these rules seem to work OK, but there have been a few
> instances where the problem mentioned above happens. It often results in
> delivery of 1 to 4 GB of mail. As I stated before, turning off the mail
> filter seems to stop it, so I was wondering if there is any way that the
> above rules could somehow be perpetuating the delivery of certain emails.
> The emails that are being repeatedly delivered are tagged with
> *SPAM* in the subject (and the subject STARTS WITH that tag), so
> these messages should be getting forwarded to [EMAIL PROTECTED]
> Any help would be appreciated.
>
> Trey Nolen
>
>
>
Re: [sqwebmail] patch sqwebmail or courier authlib for work with % instead @ ?
This list is dead: the new list is [EMAIL PROTECTED]
http://sourceforge.net/mail/?group_id=5404
on 5/5/05 2:19 AM, -= Texilee =- <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've a problem when I try to use mail address
>
> example%foo.bar instaed [EMAIL PROTECTED]
>
> in version 3.3.4 i've patched
>
> sqwebmail-3.3.4/authlib/preauthvchkpw.c
>
>
> auth.sysuserid=&uid;
> auth.sysgroupid=gid;
> auth.homedir=vpw->pw_dir;
> // patch
> i=0;
> while(userid[i] != '\0')
> {
> if (userid[i] == '%')
> {
> userid[i] = '@';
> break;
> }
> if (userid[i] == '@')
> {
> break;
> }
> i++;
> }
> // end patch
> auth.address=userid;
> auth.fullname=vpw->pw_gecos;
> auth.passwd=vpw->pw_passwd;
>
> and that's works fine with email exmaple%foo.bar
>
> Now my system works fine with current version... so I try to patch
> src courier authlib preauthvchkpw but it doesn't works...
>
> you can see the result in your example...
>
> user webmail%webmail.com
> pass webmail
>
>
> address it will [EMAIL PROTECTED]
>
>
>
> this is a little patch but it's important for me.
>
> finally.. where is the correct place to replace login field from "%" to "@" ?
>
> sorry for my poor english :-)
>
> thanks
>
> bye bye
>
> Texilee
>
Re: [sqwebmail] sqwebamail setup
on 4/8/05 2:21 AM, shaun <[EMAIL PROTECTED]> wrote: > sqwebamail-4.0. > I am trying to setup and run sqwebmail. When I ri=un the authdaemond I get a > error that the file authdaemomrc cannot be found I have looked in that > directory and the file is not there. on 3/16/05 4:59 AM, Brian Candler <[EMAIL PROTECTED]> wrote: > This list is dead: the new list is [EMAIL PROTECTED] > http://sourceforge.net/mail/?group_id=5404
Re: [sqwebmail] I'm gone... Anyone still left?
on 3/30/05 6:26 PM, Bret Busby <[EMAIL PROTECTED]> wrote: > On Fri, 25 Mar 2005, James A Baker wrote: > >> Date: Fri, 25 Mar 2005 13:17:13 -0600 >> From: James A Baker <[EMAIL PROTECTED]> >> Reply-To: sqwebmail@inter7.com >> To: sqwebmail@inter7.com >> Cc: Sam Varshavchik <[EMAIL PROTECTED]> >> Subject: [sqwebmail] I'm gone... Anyone still left? >> >> Well, if anyone is still subscribed here (Brian, maybe?) just thought I'd say >> bye and thanks for being around in the past to help out... And that if you >> get a chance, try _again_ (for me) to convince Sam or that Inter7 guy to >> finally kill off the ability to add subscriptions to this list. -- I'd hate >> for someone to dump SqWebMail because they sign up for the old list to get >> help, and can't get any replies whenever you leave too... assuming you really >> are still here, that is. ;-) >> >> Ciao! >> >> -jab >> > > It is one thing to kill off the old list, but how about getting the new > list to work? > > I am subscribed to the new list, and have been for a while, but the > message below, appears to have been eaten by the new list, as I have not > received a copy that shows the message to have been distributed by the > new list, even though I have been receiving messages distributed by the > new list, both before and after the sending of the message below. I'm having a similar trouble with another sourceforge list, i.e. it doesn't seem to reliably send out messages it receives, although messages appear in the archives reliably. Maybe you could take a look in the archives for your missing message, to help characterize the problem. -Kurt
Re: [sqwebmail] SqWebMail 20031109
on 11/9/03 9:35 AM, Sam Varshavchik <[EMAIL PROTECTED]> wrote: > Download: http://www.courier-mta.org/download.php#sqwebmail > > Changes: > [snip] > > * Replace common smileys in text/plain content with small images. This > build recognizes only a few common smileys. Submissions of additional > artwork is welcome. Oh, good heavens. You're going to make me want to take my mail online all the time. -Kurt Bigler
Re: [sqwebmail] ATT.net Alert? What's this?
on 10/3/03 9:09 AM, DARCY,MATTHEW (HP-UnitedKingdom,ex2) <[EMAIL PROTECTED]> wrote: > I don't understand why someone at inter7 hasn't responded to this (I assume > inter7 manages the list ) I called inter7 on their toll free number. Someone named Jeremy will join the list tomorrow and take care of the issues. Apparently they are not monitoring it but join the list occasionally for a day in order to clean these things up. Funny no one else thought to call them. Its a toll-free number after all. -Kurt Bigler > > -Original Message- > From: Brian Candler [mailto:[EMAIL PROTECTED] > Sent: 03 October 2003 16:47 > To: Rick van Vliet > Cc: [EMAIL PROTECTED] > Subject: Re: [sqwebmail] ATT.net Alert? What's this? > > On Fri, Oct 03, 2003 at 10:41:15AM -0500, Rick van Vliet wrote: >> Is anyone else getting some kind of bounce from cevi.ch and do_not_rplyxx >> at att.net, after sending to the list? > > Yes. It has been discussed several times here. > > The list administrator is ignoring mails and not removing these dead users > (or users with wrong forwarding addresses set up) > > Brian. > >
Re: [sqwebmail] Re: Hardcoded colours - grey and blue
on 7/25/03 6:46 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Friday 25 July 2003 07:31, Brian Candler wrote: >> On Fri, Jul 25, 2003 at 12:17:53PM +0100, Brian Candler wrote: >>> Is there any fundamental reason why I can't replace >>> >>> with >>> ? >>> >>> Or indeed, why this class could not be applied just to the >>> element and not to each of the individual cells? >> >> I can answer the second question myself - the rounded corners wouldn't >> work! >> >> But I just changed the individual cells to use a stylesheet, and it renders >> OK in Konqueror and IE5.0, so I reckon that's the way to go... so I'll make >> a patch and perhaps other people can try it. > > My template is void of "hard coded" template colors. I use a pure stylesheet > setup. It works with Netscape 4.x through 7.2 and all other major browsers. > > Rounded corners work fine. > > Take a look: > > http://mail.wingnet.net > > Click on Webmail (New Look). Yes, but am I missing something or did you have to create new rounded corner images? Or better put, is there a way to create a rounded corner image that can be colorized by a style sheet, and is that what you have done? -Kurt Bigler
Re: [sqwebmail] httpd.conf modifications?
on 6/10/03 1:13 PM, Peters, Michael D. <[EMAIL PROTECTED]> wrote: > Is there anything I need to modify in the Apache 2.0.46 httpd.conf file to > make Sqwebmail work? This depends completely on how you are structuring your webmail domains, and how you want to structure your directories. For myself, I use name-based hosting and I create a single virtual server for all my webmail domains, which share identical functionality. I map them all to a single directory on my server, which I think contains some of the images and maybe the css file in a subdirectory, and an index.html that I use to point to the cgi. My .conf file looks something like this: ### WEBMAIL - ALL DOMAINS DocumentRoot /usr/local/apache/htdocs/webmail ServerName wemail.domain1.com ServerAlias webmail.domain2.com webmail.domain3.com And /usr/local/apache/htdocs/webmail is where I tell sqwebmail to install all the image files. The directory also contains an index.html that looks like this: Web Mail I can't remember whether this index.html file is part of the normal install or not. I know I am doing something unusual in terms of where I am installing the image files. This requires setting another sqwebmail option in a non-default way--I forget the details. There are also other environment variable options you might want to set in your .conf file (which you can do on a per-domain basis), depending on what you need. You might want to search the archives for possibilities (maybe look for "environment variables" - you can find the archives via the inter7 site. -Kurt Bigler > > Thanks, > Michael > >
Re: [sqwebmail] Mail Archive?
on 3/13/03 3:26 PM, Paul Theodoropoulos <[EMAIL PROTECTED]> wrote: > > and particularly considering this is an ezmlm list, it's trivial to add a > footer on each message listing some particulars, like 'unsubscribe' > address, archive address, etc. > > but then, i've mentioned that option at least two or three times before, so > apparently it's not going to happen. i guess those extra 200 bytes of > traffic per mailing would bring the internet to its knees. > > unlike the 20k and 30k threads that were going through the list a week or > two back. Yes, well, maybe that was mostly my fault. And in fact, maybe the message footers WOULD take more bandwidth than the occasional reply to an archive question. And by the way, do those UNSUBSCRIBE messages sent to the list address with no message body actually cause an unsubscribe? If not maybe that would be a good enhancement to ezmlm. And how about non-subscribed senders getting the list info delivered to them on their first message, and getting automatically subscribed on their second? Now that would be ez. Probably should head for the ezmlm list, but figured a brief mention here first would be ok. -Kurt Bigler > > At 03:16 PM 03-13-2003, Kurt Bigler wrote: >> Just posted this 2 days ago, here it is again... >> >> http://marc.theaimsgroup.com/ >> >> or to save a step... >> >> http://marc.theaimsgroup.com/?l=sqwebmail&r=1&w=2 >> >> >> >> People are asking this fairly regularly now. It would be a good thing if >> all web pages to this mailing list were accompanied by a reference to the >> archive. That is actually the ordinary organization for mailing lists, in >> my experience. I usually do not see this question coming up on other >> mailing lists. >> >> -Kurt Bigler >> >> >> >> on 3/13/03 2:34 PM, sqwebmail <[EMAIL PROTECTED]> wrote: >> >>> Hi all, >>> >>> Is there a searchable mail archive for this list? >>> >>> I've got permission problems somewhere and I'm pretty sure that would be in >>> there somewhere. >>> >>> Thanks >>> >>> >>> > > Paul Theodoropoulos > http://www.anastrophe.com > http://folding.stanford.edu > The Nicest Misanthrope on the Net > > > >
Re: [sqwebmail] Mail Archive?
Just posted this 2 days ago, here it is again... http://marc.theaimsgroup.com/ or to save a step... http://marc.theaimsgroup.com/?l=sqwebmail&r=1&w=2 People are asking this fairly regularly now. It would be a good thing if all web pages to this mailing list were accompanied by a reference to the archive. That is actually the ordinary organization for mailing lists, in my experience. I usually do not see this question coming up on other mailing lists. -Kurt Bigler on 3/13/03 2:34 PM, sqwebmail <[EMAIL PROTECTED]> wrote: > Hi all, > > Is there a searchable mail archive for this list? > > I've got permission problems somewhere and I'm pretty sure that would be in > there somewhere. > > Thanks > > >
Re: [sqwebmail] archives
Try... http://marc.theaimsgroup.com/ or to save a step... http://marc.theaimsgroup.com/?l=sqwebmail&r=1&w=2 on 3/11/03 1:44 PM, Kenny Knott <[EMAIL PROTECTED]> wrote: > Is there a searchable mail list archive? > > Kenny Knott > KRK Consulting > (714) 717-4204 > http://www.krkconsulting.com > > > > >
Re: [sqwebmail] Re: logindomainlist patch
on 3/11/03 6:50 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Tuesday 11 March 2003 01:15, Kurt Bigler wrote: >> on 3/10/03 8:56 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: [snip] >> >> Some context was lost from our original discussion - I actually filled a >> little more of it in above - stuff that was snipped. I think you were >> saying the hard default only kicks in when there is no popup. When there >> is a popup and the user choses the empty item, only then are they free to >> type in their domain in the userid field. Did I get that right? > > Hmmm... yes. It appears to be that you can type in a full email address when > the drop down is empty. > > I actually had to test this manually since my patch doesn't actually modify > the code that actually processes the 'logindomain' form variable, and I wasn't > sure if you could do this before I modified the logindomainlist functionality > or not. If you mean the user selecting the empty item, then yes, this always allowed typing the domain, as I recall. For me, selecting the blank item always created the same behavior as if the popup were not there at all. >> If so, then item (4) in the list above is different from items (1) through >> (3). >> >> Enough feedback for one round though. Maybe enough for you to throw back >> another proposal that needs only tiny tweaks, if any? >> >> Leaving the doc for one comment on the features/implementation: The above >> thoughts about the blank item in the popup makes me think that some admins >> might prefer having a way to OMIT the blank item from the popup, in case it >> is not useful, or in case the admin does not want to allow access to other >> domains from that page. Just a thought for the record. Nothing that needs >> to be acted on, until/unless it turns out to actually matter to someone. > > I don't really see this tripping anyone up. Agreed. > Actually, something I'm thinking about implementing in the next patch is a > way to generate a textfield, and a defaulted textfield (with the login domain > already filled in). And maybe even a disabled, defaulted textfield (with the > login domain already filled in). You mean instead of the hidden field? The hidden field and the static text (with the @ sign) were always redundant. If you mean allowing the user to type their domain in a domain field instead of in the userid field, I think that is also useful. I even suggested it at one point very early on. But I also didn't need to make this any harder! > I wouldn't use the functionality myself, but I plan to submit this same patch > to the qmailadmin folks in the near future, and qmailadmin currently uses an > empty text field for the login domain. Some of those folks might want to see > a text field included in this kind of functionality. I would love it if qmailadmin had a domain popup. That would be much more helpful for me. But if I had to go to a different web domain for each email domain and this made the email domain automatic, that would also be much better than what we have now. > Perhaps the '-' modifier could specify a text field? The text field should > accept wild cards too, I should think. > > How does that sound? I'll leave the details on this one to you! But it seems to me that a separate additional 4th field is the best place to put this. Thanks, Kurt > > >> >> -Kurt >> >>> Thanks, >>> >>> Jesse >>> >>>> Thats all! >>>> >>>> -Kurt
Re: [sqwebmail] Re: logindomainlist patch
on 3/10/03 8:56 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > - Original Message - > From: "Kurt Bigler" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Monday, March 10, 2003 7:35 PM > Subject: Re: [sqwebmail] Re: logindomainlist patch > > >> on 3/10/03 12:33 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >> >>> On Monday 10 March 2003 15:27, Kurt Bigler wrote: [snip] >> Well, I looked, and all I found were a couple of points for the >> documentation. I only checked briefly, but I don't think these two points >> have made it into the doc, at least not completely. I think the same >> concepts apply, although the surrounding details have changed. >> >> >> >> on 3/1/03 7:46 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote: >> >>> As I recall, this "original" functionality can result in 4 ways: >>> (1) no logindomainlist file >>> (2) no match found in the logindomainlist file >>> (3) matching entry has first field empty >>> (4) matching entry enables popup list, and the blank entry is chosen >>> >>> (Possible notes there for the documentation.) > > I think this list is a little loose in it's wording. Absolutely, the above wasn't meant to be documentation - just notes. > Here's my take: > > Currently, the logindomainlist functionality can be totally disabled > in the following ways: > > (1) no logindomainlist file > (2) no match found in the logindomainlist file > (3) matching entry has first field empty, and an * or @ is in the third field > > And this item: > > ( ) matching entry has first field empty, and third field is not an * or @ > > Will create a popup list that will default to the empty option. > > > But, you tell me, Kurt (and list, if you're reading), does the documentation > explain these points well enough already? Or do I need to make some changes? I just did another read-through (still fairly quick due to lack of time right now) and correct me if I'm wrong but I didn't see that the current documentation addresses these points explicitly, except for item (3) and then it is not quite explicit - I think the * or @ in the 3rd field has to be taken from context. To me, redundancy in documentation is good as long as it doesn't get too long as result. I like to hear things from several points of view when I am learning - you never know which one will make something click. The point of view I am suggesting here is to focus the "no default" situation, or whatever you want to call it, and point out the various ways that can come about (and whether their are any differences between them - see below). It gives another overview of the whole picture, but with a particular focus. > If so... where? And to what effect? I'll refer to what I previously sent you (apparently off-list?) in a message called "doc comments". These comments are referring to your original "logindomainlist.txt" documentation. * > However, right at that point when you said "This is useful because" I was > wanting to see an explanation for what non-default really means. Maybe... > > The non-default condition is needed to leave the domain unspecified. > When the domain is unspecified the user may type a domain after their > user name. > In addition an unspecified domain is likely to be used for local > "system account" users. > > Note that when a popup list is used, if the empty item is selected, > this creates the same effect - the domain may be typed, or else > the system domain is being accessed. > > > > The wording is not final, but some of it is ok, I think. And I'm not sure if > I'm correct on that last point about the meaninf of the blank popup item. > > After that (or further down?) is where the search order issue could be > addressed. * So in reference to that, after the 3rd paragraph in what I wrote (above), you could in that context add something like: * Thus the non-default condition can arise for 4 different reasons: (1) no logindomainlist file (2) no match found in the logindomainlist file (3) matching entry has first field empty, and an * or @ is in the thirdfield (4) the user choses (explicitly or not) the blank item from the popup Item (4) can result because the popup defaulted to the empty item, and the user did not alter it. The popup will default to the empty item when the matching entry has first field empty, and third field is not an * or @. * The last bit is a little too techie, but you get the idea. I suggest listing the 4 situations. Leaving out the 4th and exl
Re: [sqwebmail] Re: logindomainlist patch
on 3/10/03 12:33 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Monday 10 March 2003 15:27, Kurt Bigler wrote: [snip] >> Been taking a breather. I do still want to check through the "lengthy >> discussions" to make sure there weren't a couple of "tiny" features or >> issues that might have gotten dropped. In any case I am pretty sure these >> won't impact the overall logic in any way. I have a hunch/memory that >> there might be at least one such issue. >> >> It will take me less than an hour this afternoon to do this--just in case >> you want to wait before posting this cleanup. I will try to get to it >> before 3pm pacific time, and probably done by 3:30. > > Go for it. I'm swamped still at work, so I'll be lucky if I can do the cleanup > today. I'm working towards the cleanup, but I just can't be sure that I'll > have time today. [snip rest] Well, I looked, and all I found were a couple of points for the documentation. I only checked briefly, but I don't think these two points have made it into the doc, at least not completely. I think the same concepts apply, although the surrounding details have changed. on 3/1/03 7:46 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote: > As I recall, this "original" functionality can result in 4 ways: > (1) no logindomainlist file > (2) no match found in the logindomainlist file > (3) matching entry has first field empty > (4) matching entry enables popup list, and the blank entry is chosen > > (Possible notes there for the documentation.) and... on 3/3/03 10:36 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote: > on 3/3/03 6:42 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > >>> without the popup is it a default or is >>> it just the login domain? >> >> It's a HARD default. You can't choose anything else. It's a default from the >> perspective of the logindomainlist file, but not necessarily the user. I may >> note this distinction in my docs. > > Good to know. I think that's fine. A short note in the doc will do it. Thats all! -Kurt
Re: [sqwebmail] Re: logindomainlist patch
on 3/9/03 11:15 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > - Original Message - > From: "Sam Varshavchik" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, March 09, 2003 1:15 PM > Subject: [sqwebmail] Re: logindomainlist patch > > >> Jesse Guardiani writes: >> >>> No features will change during cleanup. I'm happy with the current feature >>> set, and I haven't gotten any complaints from others > on >>> the list, so I assume that they're happy too. >>> >>> Wadda ya say, Sam? The ball is in your court, and I'd love to see this code >>> make it into sqwebmail's release versions. >> >> The last patch you posted was on Tuesday. I assume that's the latest >> version of your changes. I have not paid close attention to the lengthy >> discussion for now. I can review your Tue patch; or if you want to clean it >> up first, do that and send me the results. > > Ok. Sure. I'll implement the easiest code cleanups that Kurt and I discussed, > test it thoroughly, and send the list the results, > including documentation. Been taking a breather. I do still want to check through the "lengthy discussions" to make sure there weren't a couple of "tiny" features or issues that might have gotten dropped. In any case I am pretty sure these won't impact the overall logic in any way. I have a hunch/memory that there might be at least one such issue. It will take me less than an hour this afternoon to do this--just in case you want to wait before posting this cleanup. I will try to get to it before 3pm pacific time, and probably done by 3:30. -Kurt > > Thanks. > >> >> >> > > >
Re: [sqwebmail] sqwebmail run-away process
on 3/6/03 10:39 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > Howdy list, > > I found this in my logs a few days ago: > >> pid 26932 (sqwebmail), uid 89: exited on signal 10 >> pid 27115 (sqwebmail), uid 89: exited on signal 10 >> pid 27238 (sqwebmail), uid 89: exited on signal 10 >> pid 27294 (sqwebmail), uid 89: exited on signal 10 >> pid 27366 (sqwebmail), uid 89: exited on signal 10 >> pid 44341 (sqwebmail), uid 89: exited on signal 10 > > And just a few minutes ago I had to kill three sqwebmail > run-away processes that were majorly hogging CPU. > > I'm running sqwebmail-3.5.0.20030301 with my logindomainlist > patch installed on FreeBSD 4.7-RELEASE. > > Has anyone else seen this kind of behavior in the same > or different versions of sqwebmail on FreeBSD? > > I'm aware of the possibility that this issue may be caused > by my logindomainlist patch, and if that's the case then > I need to track down the memory leak. > > Thanks, Im also using FreeBSD. Which log file should I look into? -Kurt Bigler
Re: [sqwebmail] NEW: logindomainlist patch (4rth revision)
Jesse, Ok, I tested most of the features in this latest patch and everything works. The problem that existed in the previous version with domain1:domain2 appears to have been fixed - I no longer have to put a : at the end. I read the doc and that certainly clears up more things. A lot of things that I objected to in the past are all resolved. Your current choices for the modifiers are pretty minimalist, and solve what I think were your goals and mine, in terms of minimizing administrative efforts. It is somewhat of an "implementors interface" (or like you said "modifier-centric"), but with only 2 modifiers to keep track of this doesn't really bother me. Let's put it this way: I would have used 2 modifiers, and you have used 2 modifiers. Details may have differed but where we disagree your opinion is as good as mine. Probably some minor feedback on the doc later, and I will look at your code and point out anything that comes to mind. There might be a couple other truly minor points if I go back through all my comments to find them - corner case kinds of things that I want to make sure didn't get neglected. But I am also ready to bring this to a close, since this has actually been a lot of work for me too, in spite of not writing code - mainly because of installing and testing each version that came along, and of course writing all my comments, which I made into more work than necessary. Thanks again for all, Kurt Bigler on 3/4/03 9:42 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > Greetings list, > > Submitted in this email, for your testing, is the fourth > (and by far the best) incarnation of my logindomainlist > patch. > > To apply the patch, simply unzip and untar it, then > execute something like the following: > > patch sqwebmail-3.5.0.20030301/sqwebmail/sqwebmail.c < > sqwebmail-3.5.0.20030304.patch > > It's diffed against the sqwebmail-3.5.0.20030215 release, > but it works fine with the newer sqwebmail-3.5.0.20030301 > release as well. (I've tested it.) > > > What's New? > --- > > 1.) Code cleanup and restructuring. The old code structure > was making it difficult to write bug free code. The new > code structure should make it easy. Many things were > broken out into separate functions, including the code > in the main template parsing loop. This has an added > side effect of making the code a bit easier to follow. > > 2.) Bug fixes! Fixed a bug that caused sqwebmail to crash > if the logindomainlist file had two fields per record > instead of one or three. > > Also, fixed a bug that caused the following record: > > domain.com:domain.com:* > > To ALWAYS match as long as it was actually reached > when sqwebmail scans the logindomainlist file. > > This kind of record now only matches if domain.com is > in the calling URL (the way it's supposed to be). > > This release has been tested and is running on two of my > production machines. I'm SURE it still has a few bugs in it, > but I couldn't find them. > > Please install this new version on your servers and help > me test it. > > Thanks,
Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision)
Remaining responses from that last round of comments... on 3/4/03 3:44 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > - Original Message - > From: "Kurt Bigler" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, March 04, 2003 1:36 AM > Subject: Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision) > > > > >> Something unspoken is happening here. I have >> basically no clue what you might think is made obvious by the second example >> above. > > I get the feeling that you're no longer trying to understand, but rather > trying to convince me to modify the patch to your specs. > This is a bit unreasonable, and totally unnecessary. I'll release some > documentation, and you can read through it with everyone > else. That should solve the problem. No, the "unspoken" thing was just a bad choice of words. I meant it in the sense that you had something in your mind that was so obvious to you that you never thought to mention it. But it turned out to be even much simpler than I imagined. I knew I was missing something and overestimated the size of it! >> So before you jump, just back off a minute and see if you can appreciate how >> much you confused me with this - and try to get what I must have been >> thinking all this while. Its kind of funny actually. Will be interesting >> to see how this resolves. > > Again, I don't think it's something that a good dose of documentation can't > cure. I've made changes very quickly to this patch. It's > understandable that you'd be confused a bit. Yes, the doc helped a lot. > Not really. I'm just thinking in a 'modifier centric' way in order to > facilitate easy implementation of future functionality, while > I think you're thinking in a 'minimalistic' way. You'd like to see things as > simple as possible. I understand that, but I'm not > willing to give up extensibility for ease of use. Besides, I don't really > think it's going to kill anyone to read what each modifier > can do. Most people will only need to use the '*' modifier. In the end I might disagree a little but the issue is so small at this point as to be not worth any further effort. It is purely just a matter of two different opinions. Drawing to a close! Thanks for all your efforts. -Kurt Bigler
Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision)
on 3/4/03 3:44 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > Not sure where you're going with this. A '*' in the third field is not a > wildcard. It's a modifier. An '*' in the first or second > field will ALWAYS be treated as a wildcard as long as you're using the > wildcard modifier. There's nothing confusing about that. I think I figured out where the confusion came from. You've already mentioned it, and in fact I think we visited this same point a week ago - but in all the confusion I forgot. You may be right about the reason for still keeping the @ modifier, but that aside I was trying to figure out how it could really be possible that @ and * would do the same thing IN YOUR CODE, which I finally realized was what you were probably really saying. This all comes back to the fact that wildcards can not be used with records that could list in the popup. (Last time we visited this issue I pointed out this was one possible reason to keep the separate domainmap file, although again I am not really dissappointed.) And because of that, * and @ are basically the same. Now that all that confusion is aside, I think I also figured out what the * modifier really means since it does not really mean just "enable wildcard", because there are exceptions to that. It means suppress the popup list! There are no exceptions to that. As a side-effect when the popup list is supressed is the only situation in which modifiers can be supported. Just those thoughts for now. Since this puts everything else in such a different perspective for me, I think it means I will be far less confused now. More later. I have to install your latest yet again! I tend to make at least one mistake every time, but it is getting easier. -Kurt
Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision)
This time to try to keep it shorter, I'm snipping without mentioning it in most cases, and anything I snipped out with no response is stuff I agree about, or no need to comment. on 3/3/03 6:42 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: The only reason I could think for introducing a _related_ flag might be to provide a way to show the popup list but default it to the blank item at the top. >>> >>> A blank first field should actually (in my mind) do this too. Just add a >>> record with the necessary group identifier in the modifier field and >>> insert a blank first field. Instant no default. Of coarse, this doesn't >>> work yet either... >>> >>> Does that sound right? >> >> I don't think it is necessarily a good thing. A blank field to me, and as >> gone over above (and in the following, below) means turn off all the >> feature, which means there IS no popup list. > > No, a blank field means there is no default (in my mind). In the case of > hidden > fields, this means that there is no hidden field either, but in the case of > drop > downs, it'll just mean that we default to a blank field. I think some system > account users may possibly find that useful. That in itself, sounds even better, and was one of the things I was suggested below anyway, as I guess you have seen. Maybe I only suggested it in the context of the '&' modifier, but it is the same idea. This is also related to my thought that the first field should not have to contain a * even if the 2nd field (then used only for matching) does. >>> >>> The first field doesn't have to contain an asterisk currently. I thought >>> it would be a good idea to make the code as 'dummy proof' as possible, >>> and I could >>> imagine the users yelling at me that their logindomainlist file didn't >>> work because they forgot the asterisk. >> >> But wait a minute. In my mind there is a big difference in what it means >> whether it has an asterisk or not. > > If the first field does not contain an asterisk, it looks like this: > > bob.com:bob.*:* > > or this: > > bob.com:mail.bob.com:* > > There is no magic their. I don't attempt to 'guess' where the asterisk should > go. It simply doesn't exist. > > The second example above details why I'm thinking about removing the '@' > modifier. > That example is exactly the same as an '@' modifier statement, and it only > incurs a tiny bit of extra processing time in the loop. Not clear yet. Here's a guess: are you saying that if there is only once choice in the popup domain list that is the same as showing the @domain text field? If so, there is the subtle difference that the popup allows you to switch to the blank domain - no default, which I THINK (maybe) allows the user to type another domain (not listed) explicitly? Or this might be yet another separate topic for discussion. >>> In addition, the second field doesn't have to contain an asterisk either! >>> This was implemented for the same reason as the first field. >> >> Hmm... The only way I can think of the 2nd field not needing an asterisk >> but doing something like wildcarding would be if you are saying something >> like the match can occur anywhere in the string, like saying that xyz >> (without any asterisk) might mean the same thing as *xyz* (yes, two >> asterisks - which I think we want to stay away from anyway) or maybe you >> meant *xyz or xyz*, but either way I think this is an unnecessary shortcut >> that causes problems. > > See the second example in the commentary above. It makes perfect sense, and it > avoids user error by allowing non-wildcarding without having to change the > modifier to a '@'. It's intuitive. I have to say I'm probably not getting what you mean because I have not been using this as you have. Something unspoken is happening here. I have basically no clue what you might think is made obvious by the second example above. I have one possible clue, but it is just a guess. And I think its confusing as anything, if I'm right. I thought * modifier specifially meant wildcarding. And I said ok to having that modifier (which I thought was unnecessary) but then I think it should be purely an optimization that the user lives with because it is "reasonable" as you say. But if you start using the "wildcard" modifier and it doesnt mean wildcard at all, then to me that is confusing. In that case I have to ask what does this modifier really mean then? I have the funny feeling that you are getting used to _using_ these features so that it is becoming "experiential" so to speak - this is dangerous if things that don't have obvious meanings (to the less experienced) start to become "intuitive". It happens to all of us when we get used to something. Maybe this is not what is going on, but here the test: what does the * modifier mean then? It doesn't really mean wildcarding. Does it mean something in relation to the popup being there or not? You have to spell this out because I am not
Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision)
on 3/2/03 7:13 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > Oiy! This is a long one! I'm starting to wish that I had payed attention > in typing class. :) It's all good content though. See comments below: Yes, it was long, and now it is even longer - however, I have learned my lesson - for better or worse I am putting down all my thoughts, and not being abstract (unless I slipped). My hope is this means our remaining communication will be be free from mis-guessing each others meanings. So yes, it is long, but experience in these 2 weeks has proven this will save time anyway... So here goes... (unfortunately didn't proofread every last bit carefully) > > > ----- Original Message - > From: "Kurt Bigler" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, March 01, 2003 10:46 PM > Subject: Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision) > > >> on 2/28/03 3:42 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >> >>> On Friday 28 February 2003 18:09, Kurt Bigler wrote: >>>> on 2/28/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > > > >> I certainly don't mind if you do the work! I have no real need for glory >> (referring to your point below), and don't expect much glory from putting >> icing on the cake of what you did. > > Well, I would imagine that it depends on the work being done. If we're just > talking about logic here, then I might as well do it since I screwed it up > in the first place. > > If we're talking about a genuinely _NEW_ feature (and not just a fix to my > screwy logic code), then I'll let you implement it. (Unless I really need it, > but I'm actually pretty happy with the code as is. Ok. > I can currently implement > logindomainlist rewrite rules for ALL of my domains on two different > machines with just three lines in each file. That ain't bad.) Yes, and for me it is just one line! >>> But, I really wouldn't mind having you look the code over. You haven't >>> stated >>> your aptitude or experience level in C yet, but if you're capable it never >>> hurts >>> to proof read. >> >> I guess I have been programming in mostly C and C++ for 20 years. > > Alright, well, I already had a good bit of respect for you because of your > critiques, but now I realize that it's well founded. Thanks for taking the > time to critique me and my code. This logindomainlist functionality wouldn't > be half as useful without your input. And likewise. >> The last >> 10 years have been mostly C++ years, but recently stepping back into C for >> unix server work was not at all alien. In the SqWebMail code I didn't see >> any ways that C++ would have benefited it, and I was completely comfortable >> working in the C. >> >> I would say that I usually find things wrong with almost any code I look at >> - almost instantly - a bug at a glance every 30 lines or so. > > I don't find bugs so easily, but I do generally dislike other people's coding > styles. I personally find myself wishing that the sqwebmail code was more > heavily commented at times, but people who read my patch may find themselves > wishing that I didn't comment so much! > > I'm still trying to find a happy medium, I guess. Comments are a problem. Sometimes I write them and don't understand them anyway. So often enough I write 20 or 30 line comments, knowing that a year later I won't remember the process I went through. But that is one guideline that has helped me the most. Code is often thought of too statically. But it is created as a process of successive changes. The programmer experiences the code as a process. So I find that the best comments are those that comment about the process, giving enough context that the steps can be retraced. On the other hand, if I am unclear about what I am doing, I think it is best to write no comment at all - except of course to say "not sure what I'm doing here yet". Such a comment is incredibly helpful if 2 years later there is a bug right there and I don't have to wonder whether there was some good reason that I can't see why the code is the way it is - there isn't! Rip it out! Dealing with other people's styles and aesthetics is always a challenge but necessary. Code like other's coded before you in a file, and the result will be less of a mess, even if you don't like the style. Unless you think you want to and have the right to change it all - which is sometimes important if you are really about to become the new "owner" of the code. [snip] > OK. Understandabl
Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision)
on 2/28/03 3:42 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Friday 28 February 2003 18:09, Kurt Bigler wrote: >> on 2/28/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: [snip] >> 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! > > Well, if it's easy, it would probably be better for me to do it myself since > I'm pretty familiar with my own code right now. If we wait a month, I won't > be, and I'll have to rely on my comments to jar my memory. I certainly don't mind if you do the work! I have no real need for glory (referring to your point below), and don't expect much glory from putting icing on the cake of what you did. > But, I really wouldn't mind having you look the code over. You haven't stated > your aptitude or experience level in C yet, but if you're capable it never > hurts > to proof read. I guess I have been programming in mostly C and C++ for 20 years. The last 10 years have been mostly C++ years, but recently stepping back into C for unix server work was not at all alien. In the SqWebMail code I didn't see any ways that C++ would have benefited it, and I was completely comfortable working in the C. I would say that I usually find things wrong with almost any code I look at - almost instantly - a bug at a glance every 30 lines or so. This probably reflects badly on the code I have had to work with, but I didn't find anything wrong in the SqWebMail code I looked at, which is kind of a relief. This includes your code from your previous patch, which I reviewed completely. So, I'll take a look as soon as I can, and then we can go on from there. > > If you wanna add something while you're in there, then go for it. Submit it > to the list. If they like it, then it's golden. If they don't, they'll tell > ya why. :) Kinda like you have with me this last week or so. I think I'll take the approach of doing the proposed coding (if any is needed) myself, then passing it to you. You are aware of some things that I'm not, like ISO/IEC 9899:1990 compliance. Since you have more vested interest in this particularly piece of code it is probably good if you make the final pass of clean-up edits before the next patch is posted. >> 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. > > Your code, your release. Your glory. Well, as I said, I'm not really adding much in the way of functionality (if anything). No glory expected. >> 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 > > Went away already. I'm currently just looking for an asterisk in the modifier > field. Not sure if I mentioned this in my release notes, but I meant to > mention > it in the docs which I haven't yet gotten around to writing. No I don't think you mentioned it. I'm curious how this came about. Did it require changes to your wildcard matching or did it just fall out of the code you already had? >> (2) it avoids needing to add what you were describing 2 days ago as the '-' >> modifier > > How so? I thought that modifier was pretty darn important. One of us is missing something here. I'm just going to jump in with my assumptions and you can correct me as needed. We might have to kick this back and forth a couple of times to get it clear. The way I _think_ it could/should work is that the first matching line in logindomainlist determines everything. No other lines have any effect. Sequence of lines only matters in that it deter
Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision)
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.
Re: [sqwebmail] new file proposal
on 2/26/03 11:17 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > - Original Message - > From: "Kurt Bigler" <[EMAIL PROTECTED]> > To: "Jesse Guardiani" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, February 27, 2003 12:45 AM > Subject: Re: [sqwebmail] new file proposal > > >> on 2/26/03 7:45 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >> >>> - Original Message - >>> From: "Kurt Bigler" <[EMAIL PROTECTED]> >>> To: "Jesse Guardiani" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >>> Sent: Wednesday, February 26, 2003 8:09 PM >>> Subject: Re: [sqwebmail] new file proposal >>> >>> >>>> on 2/26/03 7:40 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > > > >>> Maybe that's a hokey way to implement it... but it made sense at the time, >>> and >>> I can't think of a real compelling reason to change >>> it. >> >> Well it sounds like you are agreeing with this catch, but that you aren't a >> purist. Correct me if I'm wrong, because that is my assumption for going >> on. I am a purist not for the sake of purity alone, but because it has >> implications for the (server admin) user. If you leave it the way it is... >> >> It draws attention to a separate situation that is not really separate. It >> makes people think about what the separate thing means, when in fact they >> didn't have to think about it at all. It obscures the power of the original >> wildcard notation - it will actually prevent the mind of the person >> assimilating the doc from being able to grasp something because they will >> have assimilated something not thought out - a contradiction. If the reader >> doesn't realize the contradiction consciously then their understanding of >> the whole thing is reduced. If they do realize it consciously it will make >> them believe they are missing something else - there must be something else >> - what does this documentation really mean? >> >> In my mind this is worth fixing. Are you sure that if you were to just >> remove the option that the *:* method would just not already work in your >> existing implementation? I'm not sure it would, but it seems possible. >> Then you can just tell people that the allvirtual option was unnecessary. >> >> Sorry, I wish I had gotten this to you in time to prevent extra trouble. >> But I do really think the quality of sqwebmail will be better if its >> documentation isn't confusing the user with features that don't need to >> exist. > > To be honest, I try not to think about it that much. I think this whole file > will be a bit hard for some people to understand, but others will get it just > fine. > > I'll just write the best docs I can, then answer my lot of the questions on > the mailing list. Well, then it will help people like me a lot if the documentation explains that this option would be strictly unnecessary, and that *:* should have done the same thing except that that case was not implemented. Then none of us will be scratching their heads, and everybody will know what they need to do to get their work done. Meanwhile since I'm the "purist" I would agree to change this implementation and the doc later (or even now) if you are willing. Same offer for my other point, if it turns out to be valid. Having gone this far without having to do any work its only fair that I do some, especially under the circumstances. Thanks, Kurt Bigler
Re: [sqwebmail] new file proposal
on 2/26/03 7:30 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > - Original Message - > From: "Kurt Bigler" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, February 26, 2003 7:09 PM > Subject: Re: [sqwebmail] new file proposal > > >> on 2/26/03 3:40 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >> >>> On Wednesday 26 February 2003 18:22, Kurt Bigler wrote: >> > > > > >> Typing the domain explicitly certainly still needs to be supported. Is that >> covered by the first field being blank, as in the following? >> >> :webmail.whatever.com > > If you're using wildcarding, then it wouldn't be supported. Unless I'm missing something, this could work with wildcarding - you don't need to add yet another option that doesn't need to be there. It should be sufficient to check that the first fild is empty and that the wildcard flag is present. In that case the match is done against the second field and the login domain result is empty, which should trigger the same effect as the login domain being empty with no wildcarding. The same argument as I gave in my previous email regarding the *:* situation applies here for why it is better not to add more "apparent" functionality when there need be no additional interface presented to the user. Simplifies the doc. Simplifies the whole gestalt and how the (non-end) user will be able to receive what is being offered in this feature set. Might as well make it all look very simple, and then the details are worked out as needed, with the help of examples. The examples just then illustrate the power inherent in the underlying simple concepts. (Thanks for your forebearance.) -Kurt > However, I can fix > that by creating another modifier that explicitly specifies NO default domain. > > I'll work that into my code. Good catch. > > If you're not using wildcarding, then you can just not include the domain > you'd > like to not have a default domain in the list. (This is broken in my second > patch. I'll fix it in the third.) > > >> >> I guess this was explicitly discussed in relation to domainmap, but I don't >> remember it being described in the enhanced logindomainlist context, and I >> just looked back at the doc you wrote with the last patch and didn't see it >> mentioned. Also I didn't test that case. > > It's easy enough to work in post-patch-release. Very simple fixes. But I'll > try > to remember to include this functionality in the third patch, as I can > definately > see it's usefulness. > >> >> -Kurt >> >>> >>> The '*' modifier will become the wildcard modifier, telling my code to >>> implement >>> the wildcard algorithms. Sure, I could infer this from any field that has a >>> wildcard domain, but this would lead to syntax issues and make my code >>> harder >>> to >>> comprehend and generally slower. >>> >>> Is there a problem with that? >>> >>> >>>> >>>>> -Kurt Bigler >> >> >> > >
Re: [sqwebmail] new file proposal
on 2/26/03 7:45 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > - Original Message - > From: "Kurt Bigler" <[EMAIL PROTECTED]> > To: "Jesse Guardiani" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Wednesday, February 26, 2003 8:09 PM > Subject: Re: [sqwebmail] new file proposal > > >> on 2/26/03 7:40 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >> >> [snip] >> >>> Now, I'd like to discuss the possibility of adding some MORE functionality >> >> [snip] >> >>> Value Meaning >>> ----- >>> allvirtualdefault to displaying a hidden field with the value >>> of HTTP_HOST. This way, a server that runs all virtual >>> domains wouldn't have to enter a separate record in >>> the logindomainlist file for each domain. The >>> logindomainlist would 'overload' or 'override' the >>> default (which is to use HTTP_HOST as the login domain). >> >> Maybe I'm slow, but how is that different from: >> >> *:*:* > > I probably just wasn't clear enough on the issue. > > The 'allvirtual' string will be preceded by an asterisk. The asterisk > specifies that a special modifier is about to follow. > (allvirtual or vpopmail at this point) > > Maybe that's a hokey way to implement it... but it made sense at the time, and > I can't think of a real compelling reason to change > it. Well it sounds like you are agreeing with this catch, but that you aren't a purist. Correct me if I'm wrong, because that is my assumption for going on. I am a purist not for the sake of purity alone, but because it has implications for the (server admin) user. If you leave it the way it is... It draws attention to a separate situation that is not really separate. It makes people think about what the separate thing means, when in fact they didn't have to think about it at all. It obscures the power of the original wildcard notation - it will actually prevent the mind of the person assimilating the doc from being able to grasp something because they will have assimilated something not thought out - a contradiction. If the reader doesn't realize the contradiction consciously then their understanding of the whole thing is reduced. If they do realize it consciously it will make them believe they are missing something else - there must be something else - what does this documentation really mean? In my mind this is worth fixing. Are you sure that if you were to just remove the option that the *:* method would just not already work in your existing implementation? I'm not sure it would, but it seems possible. Then you can just tell people that the allvirtual option was unnecessary. Sorry, I wish I had gotten this to you in time to prevent extra trouble. But I do really think the quality of sqwebmail will be better if its documentation isn't confusing the user with features that don't need to exist. -Kurt
Re: [sqwebmail] new file proposal
on 2/26/03 7:40 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: [snip] > Value Meaning > ----- > allvirtualdefault to displaying a hidden field with the value > of HTTP_HOST. This way, a server that runs all virtual > domains wouldn't have to enter a separate record in > the logindomainlist file for each domain. The > logindomainlist would 'overload' or 'override' the > default (which is to use HTTP_HOST as the login domain). > > vpopmail default to setting the TCPLOCALIP environment variable > to facilitate automatic vpopmail IP-alias domain support. > This would require that IP-alias support is already > compiled into vpopmail. Is this analogous to VPOPMAIL_DOMAIN, but for the IP-based hosting side of things? If so I am just wondering whether this is another case of doing something on the IP side but omitting a trivial counterpart on the name-based side. But this it out of my territory, so I just had to ask. -Kurt > > Can anyone think of anything else that might make a good default here? > > I'm generally looking for feedback on the idea, and how many people would > use it, and if anyone can think of a better way to implement it. > > Also, I'd like to note that this COULD become a compile time flag, rather > than a flat file, but I like being able to change my defaults without > recompiling, so I'm leaning toward implementing it as a flat file. > > Thanks! > > -- > 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. > > > >
Re: [sqwebmail] new file proposal
on 2/26/03 7:40 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: [snip] > Now, I'd like to discuss the possibility of adding some MORE functionality [snip] > Value Meaning > ----- > allvirtualdefault to displaying a hidden field with the value > of HTTP_HOST. This way, a server that runs all virtual > domains wouldn't have to enter a separate record in > the logindomainlist file for each domain. The > logindomainlist would 'overload' or 'override' the > default (which is to use HTTP_HOST as the login domain). Maybe I'm slow, but how is that different from: *:*:* in the currently-proposed scheme? Or does your current scheme not handle that case? If so I think it should. It would use the expressiveness already available through the wildcard scheme rather than introducing something else which is not really conceptually something different at all. -Kurt [snip]
Re: [sqwebmail] new file proposal
on 2/26/03 3:35 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Wednesday 26 February 2003 18:05, Kurt Bigler wrote: >> on 2/26/03 2:10 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: [snip] >> I would be concerned about any implicit prefix being removed from >> HTTP_HOST. It sounded like this was going to be done. > > Not removed from the environment variable itself, but from a temporary > variable > that contains the contents of HTTP_HOST. It's just wildcarding. I look for a > match > at the beginning, and remove it, then I look for a match at the end, then > remove > it. If nothing matches, nothing gets removed, and if nothing gets removed, > then > it doesn't fit the wildcard. Ok, I get it. I was confused by how you said it. >> >> 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. > > IP hosting doesn't need funky rewrite rules. It's simple and clean. You > specify > an IP, and you're done. If someone wants to write wildcard functionality for > IPs in the future, then they're welcome, but I plan to use vpopmail to handle > this. ( thus the *vpopmail modifier ) No I don't mean the wildcarding. I was thinking of how the allvirtual and vpopmail descritions read. But I guess I can take a little more time and take a look at that again, but this will be in a separate message. I'll try to get to it right away since you are in a hurry. [snip] >> 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. > > Yes, well, I AM in a hurry, so maybe everyone could do me a favor and be > greatful for the code I have provided and allow me to have my *vpopmail > modifier. I would really appreciate it, as would many other vpopmail people > I'm sure. > > The whole 'modifier' interface is modular enough for me right now. If someone > wants to write a new modifier in the future, they just add a new if statement > in my code and start writing. No big deal. It seems to me someone was just asking for a SQWEBMAIL_LOGIN_DOMAIN environment variable to be set? Or was it that you would look for such an environment variable having been set (e.g. by apache)? Or weren't there suggestions of both kinds? It is REALLY hard at this point to go back through all the emails. I seem to recall something else you said yes maybe to that would be easy - maybe I will stumble onto this again. [snip] >> 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. > > Uhhh... sounded like you were trying to convince me to write a programming > language for domain mapping. You call that saving me trouble?? No, the whole point of introducing the programming language was to indicate that it was both potentially "called for" and a desirable thing to avoid, and could be avoided via a "hook". And the hook does NOT have to be implemented now, and the potential for it can forstall even _thinking_ about adding new KINDS of complexity to the logindomainlist file. This is still worth remembering. I guess you are comfortable with this level of work, and you have set your limit (for today anyway :) so all is well. I still want to review the allvirtual and vpopmail options more closely. -Kurt > :) > > I know you meant well. > > Thanks for the comments, > > Jesse > > >> >> Thats all for now. >> >> -Kurt Bigler
Re: [sqwebmail] new file proposal
on 2/26/03 3:40 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote (apparently off-list): > On Wednesday 26 February 2003 18:22, Kurt Bigler wrote: [snip] >> I forgot to mention one other thing I was confused about. >> >> I want to make sure that the original * and @ functionality were both being >> represented in this new offering. Somehow that wasn't clear to me. It >> sounded like @ would do what * did, and * you were calling the wildcard >> modifier. Are you saying the wildcard modifier would enable the >> interpretation of wildcards? If so they why is this needed rather than >> simply the presence of the wildcards themselves? We aren't worried about >> domain names containing *s are we? (Sorry if I read things too fast.) > > It makes the code easier to write. I can't see why anyone would prefer the old > '*' modifier over the new '@' modifier, so the new '@' modifier is taking it's > place. > > The '*' modifier will become the wildcard modifier, telling my code to > implement > the wildcard algorithms. Sure, I could infer this from any field that has a > wildcard domain, but this would lead to syntax issues and make my code harder > to > comprehend and generally slower. > > Is there a problem with that? Ok, I just figured out the problem here. (But don't worry, because the problem goes too deep to be corrected.) I was about to say that you still might want wildcard mapping when you are using the domain list popup, which requiring the * flag would preclude. But then I saw the obvious conflict! This takes me back to your originally separate domainmap file. Because I "knew" you wouldn't want wildcards (how wrong I was) I did not bother mentioning that that was the one reason that would justify keeping the domainmap file separate: because then it could use wildcards while an explicit list of domains would remain in logindomainlist. Not sure that I have any real regrets though. But thought I'd mention it for completeness. Really the problem is that thoughts fly much too quickly and most of them can't be captured in time in an email. -Kurt > > >> >>> -Kurt Bigler
Re: [sqwebmail] new file proposal
on 2/26/03 3:40 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Wednesday 26 February 2003 18:22, Kurt Bigler wrote: [snip] >> >> I forgot to mention one other thing I was confused about. >> >> I want to make sure that the original * and @ functionality were both being >> represented in this new offering. Somehow that wasn't clear to me. It >> sounded like @ would do what * did, and * you were calling the wildcard >> modifier. Are you saying the wildcard modifier would enable the >> interpretation of wildcards? If so they why is this needed rather than >> simply the presence of the wildcards themselves? We aren't worried about >> domain names containing *s are we? (Sorry if I read things too fast.) > > It makes the code easier to write. I can't see why anyone would prefer the old > '*' modifier over the new '@' modifier, so the new '@' modifier is taking it's > place. Just one thing. How is the possibility of entering the domain name in the user-id field supported now? Is the hidden field just providing a default for a domain that is otherwise entered in the user-id field? I guess I never quite knew how that was working. Typing the domain explicitly certainly still needs to be supported. Is that covered by the first field being blank, as in the following? :webmail.whatever.com I guess this was explicitly discussed in relation to domainmap, but I don't remember it being described in the enhanced logindomainlist context, and I just looked back at the doc you wrote with the last patch and didn't see it mentioned. Also I didn't test that case. -Kurt > > The '*' modifier will become the wildcard modifier, telling my code to > implement > the wildcard algorithms. Sure, I could infer this from any field that has a > wildcard domain, but this would lead to syntax issues and make my code harder > to > comprehend and generally slower. > > Is there a problem with that? > > >> >>> -Kurt Bigler
Re: [sqwebmail] new file proposal
on 2/26/03 3:05 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote: > 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: [snip] >> >> 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 availabl
Re: [sqwebmail] Last line truncated in Sent mail folder
on 2/25/03 9:39 PM, Jesse Cablek <[EMAIL PROTECTED]> wrote: > > Calling out for anyone to confirm an issue for me that I can consistently > reproduce: > > 1. In SqWebMail, compose a new message. > 2. Send to anyone, and erase EVERYTHING in the textarea body (even all > blank space) > 3. Type a few lines, put something you'll remember on the last line and > don't put a new line after it. > 4. Make sure the email saves a copy to Sent folder > 5. Send email, and go into Sent folder to read it > > Now when reading, is the last line truncated? > > I am using SqWebMail 3.5.0 - qmail as MTA - and have tried the same thing > with both virtual (vpopmail) user and a system user with the same problem. > > I have viewed the email in the Sent box with SqWebMail, Mozilla via IMAP > through Courier-IMAP, and Squirrelmail and none show the last line, so it > appears SqWebMail is truncating it if it doesn't end in a newline. > > Please confirm this issue so Sam can have a consensus to fix it ;) This might actually represent 2 bugs in SqWebMail: (1) the fact that the final newline wasn't written out (2) the fact that some other code (the display code, or earlier in the process?) depended on the final newline being there to avoid throwing away the last line Is that right? -Kurt Bigler > > Thanks, > > /jesse > > > >
Re: [sqwebmail] new file proposal
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: > > > >>> *: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 i
Re: [sqwebmail] new file proposal
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: >>> 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 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. 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. 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? 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! :) 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! -Kurt Bigler > 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 >> >> >> > > >
Re: [sqwebmail] NEW: logindomainlist patch
on 2/25/03 7:47 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> Greetings list,
>
> New! An updated version of my 'domainmap' patch, without the domainmap file,
> and with a bunch more functionality!
I did a quick test of most of the features - but only the name-based virtual
hosting side of things.
My original logindomainlist worked just as things used to work.
mapping works (name-based)
* modifier works
@ modifiers works
group identifier works
Hey! What can I say. That was easy. Thanks again.
-Kurt Bigler
>
> The logindomainlist file now takes on the following format:
>
> DOMAIN1:IP1:MODIFIER
> DOMAIN2:IP2:MODIFIER
> DOMAIN3:DOMAIN4:MODIFIER
> DOMAIN4:DOMAIN5:MODIFIER
> DOMAIN6:IP3:MODIFIER
> etc...
>
> The first field indicates the mail domain we want to log into, and the domain
> that will be displayed in the drop down list on
> login.html, if we specify that we want to see it.
>
> The second field can be either an IP or a Domain. This field is matched
> against the SERVER_ADDR and HTTP_HOST CGI environment
> variables. If a match is found, then the domain listed in field one is set to
> be the default option in the drop down, or is set to
> be the value of the 'logindomain' hidden field if a drop down is not
> specified.
>
> The third field is new. This is where the magic happens. There are currently
> THREE possible values:
>
> 1.) The third field can consist of a single asterisk ("*"). This essentially
> means, "Do not display a drop down menu on login.html
> for this domain."
>
> Example:
>
> DOMAIN1:13.13.13.13:*
>
> 2.) Also, the third field can consist of a single @ symbol! This essentially
> means exactly what the asterisk ("*") means, except the
> text "@DOMAIN1" is displayed in the drop-down's place.
>
> Example:
>
> DOMAIN2:13.13.13.14:@
>
> 3.) And finally, the third field can be a 147 character or less "group"
> identifier. This identifier can then be used to mark other
> domains as belonging to the group. All domains belonging to a group are
> displayed together in the drop down.
>
> Example:
>
> DOMAIN3:13.13.13.15:personaldomains
> DOMAIN4:13.13.13.16:@
> DOMAIN5:13.13.13.17:personaldomains
>
> In the example above, if someone logs into the following URL:
>
> http://DOMAIN3/cgi-bin/sqwebmail
>
> or
>
> http://DOMAIN5/cgi-bin/sqwebmail
>
> They will see a drop down menu containing the following:
>
> @DOMAIN3
> @DOMAIN5
>
> Conversely, if someone were to access the following URL:
>
> http://DOMAIN4/cgi-bin/sqwebmail
>
> They would see the text: "@DOMAIN4" next to their userid field.
>
> Note: You don't have to use IP addresses in field two of the logindomainlist
> file. I just used IPs for clarity.
>
> Also, this logindomainlist patch aims to be 100% backward compatible with
> previous logindomainlist implementations.
>
> Please let me know if you have any troubles with it.
>
>
> See attached for the patch.tar.gz.
>
> I created it against sqwebmail-3.5.0.20030215, so you'll need to install that
> version.
>
> You shouldn't need automake for this one, since I'm not creating any new
> defines/constants.
>
> --
> 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.
>
>
Re: [sqwebmail] Re: using aspell with SqWebMail
on 2/25/03 9:15 PM, Sam Varshavchik <[EMAIL PROTECTED]> wrote: > Kurt Bigler writes: > >> --with-ispell description elsewhere in the doc seems to confirm this. But >> in my case it was clearly necessary to set --with-ispell correctly before >> spell-checking would work. Maybe the configure script only looks in certain >> places, and maybe only for the name ispell and not aspell? I didn't check >> on this. > > Configure looks in your $PATH. Well, in theory, at least. Just to clarify the probably obvious, you must mean the $PATH in effect when the configure script is run. I end up doing the makes as root, and the $PATH for root is: /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr /X11R6/bin:/root/bin > If you installed aspell in some random place in your filesystem, you > obviously can't expect configure to find it. And aspell is located in /usr/local/bin which is on the PATH but not the last item. I could try to take a look at it I suppose. If you have any suggestions in advance for diagnosing this, let me know. (Of course, it is also possible that I forget to do this since everything is working ok for me now.) > Now, there is a small bug in the configure script where the last component > in PATH is not searched. So configure won't find anything installed in the > last directory listed in PATH, at this time.
Re: [sqwebmail] Last line truncated in Sent mail folder
Yes, I reproduced this. on 2/25/03 9:39 PM, Jesse Cablek <[EMAIL PROTECTED]> wrote: > > Calling out for anyone to confirm an issue for me that I can consistently > reproduce: > > 1. In SqWebMail, compose a new message. > 2. Send to anyone, and erase EVERYTHING in the textarea body (even all > blank space) > 3. Type a few lines, put something you'll remember on the last line and > don't put a new line after it. > 4. Make sure the email saves a copy to Sent folder > 5. Send email, and go into Sent folder to read it > > Now when reading, is the last line truncated? > > I am using SqWebMail 3.5.0 - qmail as MTA - and have tried the same thing > with both virtual (vpopmail) user and a system user with the same problem. > > I have viewed the email in the Sent box with SqWebMail, Mozilla via IMAP > through Courier-IMAP, and Squirrelmail and none show the last line, so it > appears SqWebMail is truncating it if it doesn't end in a newline. > > Please confirm this issue so Sam can have a consensus to fix it ;) > > Thanks, > > /jesse > > > >
[sqwebmail] Re: using aspell with SqWebMail
Bernd Plagge <[EMAIL PROTECTED]> wrote: > You should be using aspell in which case your config option should > be > > --with-ispell=/usr/bin/aspell I was about to say: actually in my case it turns out to be --with-ispell=/usr/local/share/aspell/ispell but then I thought hey maybe he really means to use aspell rather than aspell's ispell-compatibility command. So I tried: /usr/local/bin/aspell and now it works! So the compatibility command is not compatible. And now I see why: /usr/local/share/aspell/ispell (the compatibility command) is a shell script and I guess fork/exec doesn't work directly for shell scripts. And apparently aspell itself is already close enough to compatible with ispell, for the purposes of how SqWebMail uses it. A note about this in the documentation might be helpful, particularly for those of us who take things too literally - in this case the fact that the option is called "with-ispell". The doc currently says: > SqWebMail can use either the ispell or the aspell package for spell checking > messages. Install ispell or aspell before installing SqWebMail. I wonder what the instructions to install the spell-checker first are referring to - I never discovered a reason why this was required. I sort of thought from the sentence that that the configure script would find aspell, making it possibly unnecessary to use the --with-ispell option. The --with-ispell description elsewhere in the doc seems to confirm this. But in my case it was clearly necessary to set --with-ispell correctly before spell-checking would work. Maybe the configure script only looks in certain places, and maybe only for the name ispell and not aspell? I didn't check on this. In any case besides possibly correcting that sentence it might be useful to add the sentence: When using aspell be sure the --with-ispell option refers to the correct full path for aspell, NOT for aspell's ispell-compatibility command. or something slightly different if it turns out that ./configure is supposed to fine aspell in some cases. If somebody can explain to me exactly how this is all _supposed_ to work, then I could take a shot at a clearer improvement to the doc, and otherwise maybe somebody who already knows could take care of this? Thanks, Kurt Bigler > > Hope this helps. > > Bernd > > > on 2/24/03 11:08 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote: > >> When I try to do a spell check in a SqWebMail session I get the internal >> error >> which is an indication that ispell_run failed. From looking at the code, the >> are just lots of possible causes for this failure, and I am wondering if >> anyone can suggest what might be the more likely possible reasons. >> >> Short of that I suppose I can sprinkle enomem calls around in a bunch more >> places to narrow it down. (By the way, if I make changes to sources in the >> sqwebmail subdirectory can I do make and make install in the sqwebmail >> subdirectory and not bother doing it in the top-level directory in order to >> test changes?) >> >> I had already built SqWebMail with the option >> >> --with-ispell=/usr/bin/ispell >> >> and today I actually installed aspell, and put a symbolic link to aspell's >> ispell-compatibility executable at /usr/bin/ispell. >> >> The dictionary specifications should have matched - I tried several >> possibilities to make sure, including leaving ISPELLDICT unchanged, editing >> ISPELLDICT to contain "en_US", removing ISPELLDICT entirely, which I think >> should have caused a default to "en". >> >> Running aspell dump dicts shows: >> >> en >> en_CA >> en_CA-w-accents >> en_GB >> en_GB-w-accents >> en_US >> en_US-w-accents >> >> And aspell appears to accept "english" also. >> >> Running ispell directly appears to work fine, with or without explicit >> specification of any of the available dictionaries, including "english". >> >> Thanks for any help. >> >> -Kurt Bigler >> >> > > -- > bp mailto:[EMAIL PROTECTED] >
Re: [sqwebmail] extended logindomainlist functionality
on 2/25/03 2:34 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > Hold the phone. > > I think I may have just stuck my foot in my own mouth and > implemented this functionality, complete with grouping. > > I've just got to debug it. I'll try to release it later on > tonight. > > I couldn't resist. :) Love it. Maybe I just need to keep talking and I will never have to work again. If only someone would pay me for either one it would be great! -Kurt
[sqwebmail] using aspell with SqWebMail
When I try to do a spell check in a SqWebMail session I get the internal error which is an indication that ispell_run failed. From looking at the code, the are just lots of possible causes for this failure, and I am wondering if anyone can suggest what might be the more likely possible reasons. Short of that I suppose I can sprinkle enomem calls around in a bunch more places to narrow it down. (By the way, if I make changes to sources in the sqwebmail subdirectory can I do make and make install in the sqwebmail subdirectory and not bother doing it in the top-level directory in order to test changes?) I had already built SqWebMail with the option --with-ispell=/usr/bin/ispell and today I actually installed aspell, and put a symbolic link to aspell's ispell-compatibility executable at /usr/bin/ispell. The dictionary specifications should have matched - I tried several possibilities to make sure, including leaving ISPELLDICT unchanged, editing ISPELLDICT to contain "en_US", removing ISPELLDICT entirely, which I think should have caused a default to "en". Running aspell dump dicts shows: en en_CA en_CA-w-accents en_GB en_GB-w-accents en_US en_US-w-accents And aspell appears to accept "english" also. Running ispell directly appears to work fine, with or without explicit specification of any of the available dictionaries, including "english". Thanks for any help. -Kurt Bigler
Re: [sqwebmail] NEW: domainmap Patch
on 2/24/03 8:23 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > Kurt Bigler wrote: >> In this proposal logindomainlist would have records of this form: >> >> login-domain:web-domain-spec:group-key [snip] > Well, I definately see what you were getting at now. > > I'd be extremely interested in hearing how many people would like to see > this kind of functionality included in vpopmail (especially you, Sam). [snip] > I mean, where do we stop? Why not add a field for regular expression matches > or > external program calls? And quickly we'd be writing bloatware rather than the > lean mean sqwebmail we know and (hopefully) love. I think there is usually some intuitive place to stop - something like the place where the benefit to effort ratio suddenly rises. (And this may be perceived differently by different people.) But there is also sometimes a reason not to stop yet: when the jump to the next level would involve a significantly incompatible change that you would rather avoid doing later. In this case combining the two files in my mind brings the existing functionality to its fruition while insuring against likely incompatible changes being forthcoming - or worse yet desired changes not being forthcoming purely because of the burdern of compatibility. > I wrote my domainmap code because it was extremely quick and easy to write, > and > because it addressed an issue that I genuinely believed would do some people > good and make a few hundred thousand user's lives easier. [snip] Yes, well that does put it in a bigger perspective. I'll admit I was thinking a little smaller with mostly the server administrators in mind. (And in my case perhaps small-time server administrators!) But of course the end users are who we are ultimately serving. > If ten or twenty people write back about this thread and say, "Hey! That would > be the greatest thing next to sliced bread!", then you have my blessing to > write the code yourself. You seem to be a decent analytical thinker. I'll even > help out a little if you need some pointers. But I just can't justify writing > it myself as I'll probably never use it. If it turns out to be desirable I'll be glad to do it. I think I would only be adding 50% at the most to what you did. The small increment of effort here is part of the reason I see this level as a good "place to stop". Thanks again, Kurt Bigler > And, as always, I'd still greatly enjoy reading everyone's opinion on the > matter. > > Good luck! > > Jesse
Re: [sqwebmail] NEW: domainmap Patch
on 2/23/03 8:18 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: [snip] > Kurt Bigler wrote: >> One is that it really bugs me to have to have two parallel lists to >> maintain. > > I'm still not convinced that it's that big of a deal. I agree partially with > you about the name of the file, and the fact that users > will probably like to have everything in one place, and that it's a bit > redundant. > > I suppose the fact of the matter is that it was easier to implement it in a > separate file. But I could just as easily incorporate it > into the 'logindomainlist' file. > > Tell you what: > > I still haven't heard Mr. Sam's opinion on my patch. I don't know if he loves > it or hates it. (I would imagine that he'll like it, > though. It adds some well needed functionality.) > > Sqwebmail is his baby. Let's let him decide. If he likes it better in one > file, I'll happily rewrite the patch. No big deal. If he > likes it better separate for compatibility reasons or whatever, then I'll > leave it be and write some documentation in preparation > for including it in the distribution. [snip] I want to stay active in advocating that while these new features are being considered, that they are considered in the broadest possible way. I'm a little concerned that if we wait a few weeks as Sam suggested, that by that time there will be so much invested in the current approach that there will be no going back. I'd like to find a way to eliminate the redundancy which was my main concern about the current solution (as implemented in Jesse's patch) for those of us who will be using both the domainmap and logindomainlist feature, while keeping the solution user friendly for all kinds of use. My original proposal regarding combining the domainmap information into logindomainlist (in a compatible way) might have made it slighly more complex for people who would have otherwise used domainmap alone (using Jesse's existing patch). My past messages went into a little detail about 2 or 3 possible ways that domainmap and logindomainlist could be combined. I'd like to bring these up again to fully clarify what I mean, but just as "possibilities" because I really don't want to draw conclusions too quickly about what is the best way to structure it. I also have my suspicions that some people might be needing somewhat more flexibility than the current patch solution offers. This was reinforced by Jesse Cablek's recent email when he wrote: > I personally would prefer to keep this separate. Then hosted users > wouldn't see a dropdown list for my personal domains, and vice versa. Even though Jesse C. is happy with a solution that does not involve a popup list of domains, it seems very likely that there will be others who like the popup domain list who would also like to have some separation, possibly having different lists of domains come up when different webmail urls are accessed. So here is one possible solution, tentatively rolling everything together into the logindomainlist file. This is basically my original idea, and retains its possible disadvantages - i.e. it might be slightly more difficult for those who would have used domainmap alone. But let's not worry about that now. In this proposal logindomainlist would have records of this form: login-domain:web-domain-spec:group-key The first two fields are exactly the reverse of the domainmap fields as currently defined. Fields: login-domain is the default domain for the login, which works either with or without a popup list, as already described. web-domain-spec is a string to match against either the SERVER_ADDR or HTTP_HOST environment variables (for IP- or NAME- based virtual hosting) group-key is either: an asterisk, indicating that this is a "loner" domain - the popup domain list should be suppressed or: a string used to identify a "group" to which this domain belongs All domains sharing the same group-key will appear together on a popup domain list. The group-key field may be empty. The "empty" key is a valid group-key like any other. All domains specifying no group-key belong to the same group. Some possibilities for use of this scheme: (1) If you want ONLY logindomainlist functionality, you use logindomainlist exactly as it has always has been used. In this case the web-domain-spec and group-key fields are omitted - the colon field separators are therefore not needed. (2) If you want ONLY "domainmap" functionality, the logidomainlist file might look like: domain1:webmail.domain1:* domain2:webmail.domain2:* domain3:w
Re: [sqwebmail] NEW: domainmap Patch
on 2/22/03 8:37 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > - Original Message - > From: "Kurt Bigler" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, February 22, 2003 10:53 PM > Subject: Re: [sqwebmail] NEW: domainmap Patch > >> on 2/22/03 11:11 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >> >>> Howdy list, >>> >>> What does this patch do? >>> >>> This patch adds functionality to sqwebmail. It allows the sys admin to add a >>> file to the configuration directory >>> (/usr/local/share/sqwebmail on my FreeBSD 4.7 system) named 'domainmap'. [snip] >> I still wish the logindomainlist and domainmap could be integrated into one >> file. Compared to everything else, this is a minor issue, but any chance >> this possibility is still open to discussion? > > Sure, it's still open to discussion. I'm not the type of person that > entertains delusions of perfection. > > However, I really don't see the point. It would unnecessarily complicate > things, IMHO. When programming, I try to group things > logically, and the 'logindomainlist' file does something ENTIRELY different, > and serves an entirely different purpose, than the > 'domainmap' file. > > Why does having two separate files bother you so much? Perhaps if I knew why > it was important to you then I could better understand > your reasoning, or, at the very least, suggest a solution that might work > better. Two reasons. One is that it really bugs me to have to have two parallel lists to maintain. So far I am maintaining all my server stuff manually. I haven't yet written scripts to do things like add a domain, partly because I don't think I have enough experience yet to know how to create a good general-purpose solution. Even if I do eventually write scripts to do this, I would prefer if the scripts had to mess with fewer files to do their work. The other reason is that I actually want SqWebMail to be as successfull as possible (for totally selfish reasons), and I think it makes SqWebMail a more complex product if two separate files are used. This complexity has two aspects: the user experience and the implementation. By user I mean the administrator, not the end user. The end user won't see the difference in any of this. Regarding the user experience, I suspect other user's experiences might be simialar to mine. They will want something as simple as possible to maintain. For most people who USE both the logindomainlist and domainmap features (which I believe will sooner or later be the most everyone who uses logindomainlist), these two files will look something like this (only much longer): logindomainlist: domain1.com domain2.com domain3.com domain4.com domain5.com domainmap: webmail.domain1.com:domain1.com webmail.domain2.com:domain2.com webmail.domain3.com:domain3.com webmail.domain4.com:domain4.com webmail.domain5.com:domain5.com Thus essentially the same list of domains is repeated 3 times in 2 different files. 2 times in 1 file is much better. Maybe it is a typical thing for a relational database (which I don't really know much about) to store such information in a redundant way, with multiple tables and common keys appearing in each. But then you want a front-end that completely hides this from the user. And here we would certainly not want to create such a front end. Also, look at the file name "logindomainlist". To me, both of these files are lists of domains that relate to login - they are both login domain lists. I think this is a simple way of looking at things which I am guessing other SqWebMail administrators might relate to, not caring about the SqWebMail internals. Regarding the implementation, I suspect an implementation which combines these functions into a single file will actually be slightly simpler than the current implementation. But I might be wrong, and need to look at the code more carefully. It was just that my gut was telling me these two things are incredibly intertwined. I am also not into obscure hacks that make code smaller for the sake of small - it should also make sense from a functional level. I should take a closer look. However: I am not familiar with how the template-per-domain feature works. If in fact, the logindomainlist is part of the configuration which would be customized PER domain, where the domainmap is global, then this might be one problem with combining the two. But here is another thought: Suppose a server hosts domains for several organizations, and each organization has several domains, with emails hosted on each. End-users on this system might want to see only the domains in their organization in th
Re: [sqwebmail] Login name length
on 2/22/03 9:44 PM, Brady Owens <[EMAIL PROTECTED]> wrote: > > Hello, > > I recently installed Sqwebmail (actually using it to send this message). > But I found something very wierd and can't find any documentation on this. > It seems that any account I have setup that has three letters for the > account name (ex. [EMAIL PROTECTED]) it will not allow to be logged in via the > sqwebmail interface. Anyone have any information on this? > > Thanks > Brady It just happens that I tested a 3 letter login name a few minutes ago, and it worked fine. However, keep in mind that you are not so much talking about SqWebMail per-se her as much as the authorization scheme you are using. Before the gurus (not me) can help you further they will probably want to know what kind of authorization you are using. Check the beginning of config.log in the sqwebmail source directory, to see the "with" and "without" options you specified with ./configure. Perhaps post that line from config.log back to this list and maybe someone can better help you. -Kurt Bigler
[sqwebmail] sources for TIMEZONELIST additions
I would like to add additional time zones to TIMEZONELIST, but I have been having difficulty finding sources either on my server (man pages and elsewhere, including /usr/share/zoneinfo) that give time zone information in the form needed, i.e. not only the UTC offsets, but the correct local time zone abbreviation for normal and daylight savings time, plus any special start and end information for daylight time. The site: http://www.twinsun.com/tz/tz-link.htm contains a lot of information, but I haven't so far managed to dredge out much that is of use for a server administrator wishing to up timezone entries. In particular right now I am wishing to add time zones for europe. Thanks for any suggestions. -Kurt Bigler
Re: [sqwebmail] NEW: domainmap Patch
on 2/22/03 11:11 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > Howdy list, > > What does this patch do? > > This patch adds functionality to sqwebmail. It allows the sys admin to add a > file to the configuration directory > (/usr/local/share/sqwebmail on my FreeBSD 4.7 system) named 'domainmap'. > > Once this file has been created, it can be populated with IP:DOMAIN pairs, or > DOMAINALIAS:DOMAIN pairs. [snip] I tested this patch on my server which uses name-based virtual hosting and it works like a charm. In other words I tested the use of domainmap containing DOMAINALIAS:DOMAIN pairs. I tested it without a logindomainlist in which case the hidden field kicked in and the user id could be entered alone for a successful login. I also tested it with a logindomain list in which case the domain list popup correctly defaulted correctly. Thanks a bunch Jesse. Works like a charm! I still wish the logindomainlist and domainmap could be integrated into one file. Compared to everything else, this is a minor issue, but any chance this possibility is still open to discussion? Thanks, Kurt Bigler
Re: [sqwebmail] NEW: domainmap Patch
on 2/22/03 7:02 PM, Mark Constable <[EMAIL PROTECTED]> wrote (off-list): > Kurt Bigler wrote: >> >> confirm that it worked. Then I made a cp -R copy of the 20030215 source >> tree, cd'd to that directory and then for the first time in my life ran >> "patch", which I did as follows >> >> patch > >> and which resulted in the following output > > Perhaps try... > > cd into_sqwebmail_dir > mv sqwebmail-3.5.0.20030215-automake.patch .. > patch -p1 < ../sqwebmail-3.5.0.20030215-automake.patch > > And you may need a fresh bunzip2 of the source tree if it's > already been molested with a dud patch run. > > --markc Thanks. That worked. Taking the liberty of posting this back to the list since it resolved my issue. -Kurt Bigler
Re: [sqwebmail] NEW: domainmap Patch
on 2/22/03 11:11 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > Howdy list, > > What does this patch do? > > This patch adds functionality to sqwebmail. [snip] > What does this tar.gz contain? > -- > Included in the tar.gz file that is attached to this email are two patches > against the latest development version of sqwebmail: > > sqwebmail-3.5.0.20030215 > > The first patch: > > sqwebmail-3.5.0.20030215.patch > > is a raw patch file. It modifies sqwebmail/Makefile.am, so you'll need > automake to use it. > > The second patch: > > sqwebmail-3.5.0.20030215-automake.patch > > contains the patch above, plus a patch for the sqwebmail/Makefile.in file, as > generated by my system's automake 1.6.3. > > Note that I must not have used the correct options with automake as some > things were changed in sqwebmail/Makefile.in that shouldn't > have been changed. I'm sure Mr. Sam will want to run his own automake against > the raw patch file. Ok, so from what you wrote it sounded like if I used the second patch maybe I wouldn't need to get automake. (This sounded like a good thing since I had already spent 3 hours installing things so far, since the 20030215 version was distributed in a bz2 file which I had never heard of, and then the freebsd ports website was apparently down ... blah blah.) In any case I finally installed bzip and so was able to install 20030215 and confirm that it worked. Then I made a cp -R copy of the 20030215 source tree, cd'd to that directory and then for the first time in my life ran "patch", which I did as follows patch > -- > 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. > >
Re: [sqwebmail] Login Domain
on 2/21/03 9:15 PM, Michael Fuller <[EMAIL PROTECTED]> wrote: > Hello all, > > We are using sqwebmail to support a single domain. Now users have to type > [EMAIL PROTECTED] to login. How to get the @domain.com part as a default > setting ? logindomainlist is not working. BTW what is the format for entries > in logindomainlist [EMAIL PROTECTED] or domain.com ? The latter - no extra punctuation. > I dont want to touch the templates for this. Somebody please help. There is also a patch coming up very soon which may give you better functionality, also perhaps not requiring logindomainlist. See the recent posts. > > Regards, > Michael Fuller, > Network Administrator - RAILNET, > Signal and Telecommunication Department, > Southern Railway, > Park Town, Chennai - 600 003. > India > Phone: +91-44-25331962, +91-44-25348123 / 627 > E-Mail : [EMAIL PROTECTED] > > >
[sqwebmail] Re: default domain with domain templates
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 I have >> a distinct webmail domain of the form "webmail.". >> >> 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
Re: [sqwebmail] default domain with domain templates
on 2/21/03 1:56 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Friday 21 February 2003 16:22, Kurt Bigler wrote: >> on 2/21/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>> On Friday 21 February 2003 15:26, Kurt Bigler wrote: >>>> on 2/21/03 11:33 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>>>> On Friday 21 February 2003 13:58, Kurt Bigler wrote: >>>>>> on 2/21/03 10:07 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>>>>>> On Friday 21 February 2003 11:55, Dale wrote: >> > [snip] >> If I'm right then you could trivially include the name-hosting solution >> when you code what you are working on. I will be glad to test it and work >> on it as needed, but we might as well do both things at once if at all >> possible. Only problem may be that our schedules won't coincide and the >> process will take more time. But 9 chances out of 10 your solution will >> just work for the name-based situation if you just keep in mind HTTP_HOST >> as well as SERVER_ADDR. > > Agreed. I'll have to make sure that the HTTP_HOST variable actually contains > the data we want, and that there isn't a better variable choice out there, > but I don't see why it wouldn't work as expected. Besides HTTP_HOST there is also SERVER_NAME, which _sounds_ more analogous to SERVER_ADDR. In my test cases HTTP_HOST is the same as SERVER_NAME. However O'Reilly CGI Programming in Perl has these descriptions: SERVER_NAME The server's hostname or IP address. HTTP_HOST The hostname of the server from the requested URL (this corresponds to teh HTTP 1.1 Host field). So HTTP_HOST is probably the way to go. It is just the host part of the url, i.e no http:, no initial //, no file path or query string. A couple years back I ran a predecessor of this idea past Sam (not on the list) and he didn't balk at using HTTP_HOST, although I don't know that he thought deeply about it. -Kurt Bigler
Re: [sqwebmail] default domain with domain templates
on 2/21/03 2:53 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> On Friday 21 February 2003 17:35, Kurt Bigler wrote:
>> on 2/21/03 2:14 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>> 1.) Do you have a WORKING IMAP or POP3 server installed on the machine in
>>> question?
>>
>> Yes, qmail+vpopmail. No IMAP currently.
>>
>>> 2.) If the answer to question 1 above was 'yes', then do you have to log
>>> in with [EMAIL PROTECTED], or can you log in with just 'user', while accessing
>>> a port on 'domain'? ('yes' for '[EMAIL PROTECTED]' only. 'no' for logins with
>>> just 'user' on a port at 'domain')
>>
>> Yes, I login as just user, because the logindomainlist popup is present and
>> already defaulted to the correct domain due to my changes to sqwebmail.c.
>
> But what about POP3?? That's the whole point of these questions. Can you log
> in
> as just 'user' with POP3?
Certainly not. I have a lot of domains, and user names are not unique
across them. But just to be sure I just tried it, and no it did not work.
Just for your reference, my SqWebMail config options as shown in config.log
are:
$ ./configure --enable-webpass=vpopmail --without-authuserdb
--without-authpam --without-authpwd --without-authshadow --without-authldap
--with-authvchkpw --enable-imageurl=/images --enable-hardtimeout=10
--enable-softtimeout=10
--enable-imagedir=/usr/local/apache/htdocs/webmail/images
--enable-cgibindir=/usr/local/apache/cgi-bin --with-ispell=/usr/bin/ispell
--without-authdaemon
-Kurt Bigler
Re: [sqwebmail] default domain with domain templates
on 2/21/03 2:14 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> On Friday 21 February 2003 17:06, Kurt Bigler wrote:
>> on 2/21/03 1:56 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>> On Friday 21 February 2003 16:22, Kurt Bigler wrote:
>>>> on 2/21/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>>>> On Friday 21 February 2003 15:26, Kurt Bigler wrote:
>>>>>> on 2/21/03 11:33 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>>>>>> On Friday 21 February 2003 13:58, Kurt Bigler wrote:
>>>>>>>> on 2/21/03 10:07 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>>>>>>>> On Friday 21 February 2003 11:55, Dale wrote:
>>>
>
>
>
>>
>> No, I was just clarifying in case there was some feature of sqwebmail that
>> I didn't know about for acting as a POP3 or IMAP client. I also know there
>> are POP3/IMAP clients that will serve into Maildir's - and I want to find
>> one of those. Actually it would be great to integrate hotmail-like POP3
>> access for multiple accounts into a single webmail login. Has anyone
>> managed to do that? (Potential new thread here.)
>
> Ok. I'm confused. Let me ask these questions individually:
Sorry I just added to the confusion. I was thinking that SqWebMail was a
Maildir "client" not involving POP3/IMAP, but I had forgotten about the
login authorization issue (duh).
>
> 1.) Do you have a WORKING IMAP or POP3 server installed on the machine in
> question?
Yes, qmail+vpopmail. No IMAP currently.
>
> 2.) If the answer to question 1 above was 'yes', then do you have to log in
> with [EMAIL PROTECTED], or can you log in with just 'user', while accessing a
> port on 'domain'? ('yes' for '[EMAIL PROTECTED]' only. 'no' for logins with
> just 'user' on a port at 'domain')
Yes, I login as just user, because the logindomainlist popup is present and
already defaulted to the correct domain due to my changes to sqwebmail.c.
>
> 3.) Are you using vpopmail to authenticate these IMAP or POP3 accounts?
Yes.
>
> 4.) What is your IMAP/POP3 server type? (Courier-IMAP, Washington IMAP,
> etc...)
I have nothing else besides qmail and vpopmail. I actually can't remember
off hand which half of qmail+vpopmail actually runs the POP3 server, but I
have a totally standard configuration in that regard.
-Kurt Bigler
Re: [sqwebmail] default domain with domain templates
on 2/21/03 1:56 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Friday 21 February 2003 16:22, Kurt Bigler wrote: >> on 2/21/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>> On Friday 21 February 2003 15:26, Kurt Bigler wrote: >>>> on 2/21/03 11:33 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>>>> On Friday 21 February 2003 13:58, Kurt Bigler wrote: >>>>>> on 2/21/03 10:07 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>>>>>> On Friday 21 February 2003 11:55, Dale wrote: >> > > > >>> Can you currently log into IMAP or POP3 on your domain without specifying >>> [EMAIL PROTECTED] as the userid? >> >> Absolutely, but of course it is not a login to IMAP or POP3 but into a >> Maildir, whose contents could have been put there by any means. > > So, you've never used POP3 or IMAP? Just sqwebmail? No, I was just clarifying in case there was some feature of sqwebmail that I didn't know about for acting as a POP3 or IMAP client. I also know there are POP3/IMAP clients that will serve into Maildir's - and I want to find one of those. Actually it would be great to integrate hotmail-like POP3 access for multiple accounts into a single webmail login. Has anyone managed to do that? (Potential new thread here.) > >> So yes, I started by using the logindomainlist feature, so right away >> entering [EMAIL PROTECTED] was not necessary, but I still had to select the >> domain from the popup list. But then I changed sqwebmail.c so that it >> would set a default value for the popup list by recognizing the list item >> that matched HTTP_HOST with "webmail." prepended. As I said, not a general >> solution yet. >> > > > >> I suspect that the same configuration file could specify either a name or >> an ip, and accordingly you would match it against either SERVER_ADDR or >> HTTP_HOST. Once you do a lookup in either case you are determining a login >> domain NAME, so the rest of the implementation should be identical. > > Hmmm. That's not a bad idea. I don't remember real clearly what the HTTP_HOST > variable looks like, but I could easily do a comparison against both > variables. > > Good idea! > >> >> Can I get you to buy into the idea that this can all be done using >> logindomainlist? Use records of one of two formats: >> >> logindomain:http_host:popup_flag >> logindomain:server_addr:popup_flag > > No. I want to keep the two files separate for compatibility reasons, as well > as functionality reasons. I like the idea of "defaulting" the domain drop down > on the login page if the 'logindomainlist' file exists. I think that would > be a bit harder to implement if I overload the 'logindomainlist' file for this > new functionality. I think it might not be harder - might actually be the easiest way. (Sent you some details off-list.) -Kurt Bigler
Re: [sqwebmail] default domain with domain templates
on 2/21/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Friday 21 February 2003 15:26, Kurt Bigler wrote: >> on 2/21/03 11:33 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>> On Friday 21 February 2003 13:58, Kurt Bigler wrote: >>>> on 2/21/03 10:07 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>>>> On Friday 21 February 2003 11:55, Dale wrote: [snip] >>> The method I am working on (mostly in my head right now) will consist of >>> a comma >>> or colon delimited flat file, with one IP:DOMAIN pair per line, as in the >>> example >>> below: >>> >>> IP1:DOMAIN1 >>> IP2:DOMAIN2 >>> etc... [snip] >> My server is set up to do name-based virtual hosting, and so I haven't had >> experience with anything else. My server has only one IP address. Does >> what you are suggesting apply to this situation? Perhaps you are solving a >> problem at an entirely different level from the one I was trying to solve. >> >> So to clarify, what I would envision as a alternative to what you were >> suggesting, but which would solve the problem I need to solve, would be a >> similar table: >> >> webmail-http-domain-1:email-login-domain-1 >> webmail-http-domain-2:email-login-domain-2 >> etc. >> >> Where the first field is the HTTP_HOST value and the second field is the >> associated login domain. >> >> This is because I do not want to assume that it will always look like this: >> >> webmail.somedomain1.com:somedomain1.com >> webmail.somedomain2.com:somedomain2.com >> webmail.somedomain3.com:somedomain3.com [snip] >> How does this relate to what you are doing? > > It doesn't. My solution will only be applicable to IP based domains. > > Can you currently log into IMAP or POP3 on your domain without specifying > [EMAIL PROTECTED] as the userid? Absolutely, but of course it is not a login to IMAP or POP3 but into a Maildir, whose contents could have been put there by any means. So yes, I started by using the logindomainlist feature, so right away entering [EMAIL PROTECTED] was not necessary, but I still had to select the domain from the popup list. But then I changed sqwebmail.c so that it would set a default value for the popup list by recognizing the list item that matched HTTP_HOST with "webmail." prepended. As I said, not a general solution yet. But in any case, it is good that you are working on the _correponding_ problem, but for IP-based rather than name-based hosting. Because I'm almost sure all the external configuration issues will be analogous. In fact I suspect the implementation will also be analogous, i.e. that the same files will be touched in roughtly the same places to solve both problems. I suspect that the same configuration file could specify either a name or an ip, and accordingly you would match it against either SERVER_ADDR or HTTP_HOST. Once you do a lookup in either case you are determining a login domain NAME, so the rest of the implementation should be identical. Can I get you to buy into the idea that this can all be done using logindomainlist? Use records of one of two formats: logindomain:http_host:popup_flag logindomain:server_addr:popup_flag Perhaps name and ip-based virtual hosting can't coexist on the same server (can it?), in which case what I am proposing here is overly general solution with redundant information, i.e. every record basically specifies whether name or ip-based hosting is being used. But still perhaps this is ok. I think it is friendly for the administrator in either case. If I'm right then you could trivially include the name-hosting solution when you code what you are working on. I will be glad to test it and work on it as needed, but we might as well do both things at once if at all possible. Only problem may be that our schedules won't coincide and the process will take more time. But 9 chances out of 10 your solution will just work for the name-based situation if you just keep in mind HTTP_HOST as well as SERVER_ADDR. But if you want to code yours first and pass it to me, that is also fine. If I'm not missing something big here, I can turn it around fairly quickly. Let me know. I'll be around on and off this afternoon, until 5 or 6 pacific time. -Kurt Bigler > If you CAN, then I will try to figure out what vpopmail is doing to facilitate > this functionality. If you CAN'T, then I don't think it will be unreasonable > of me to implement this solution for IP based domains only. > > You could implement a string matching operation as you mentioned above. But > I don't run virtual DNS domains, so I wouldn't be the person to code it. > > I'd be happy to discuss implementation issue with you though. :) > > Jesse
Re: [sqwebmail] default domain with domain templates
on 2/21/03 11:33 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Friday 21 February 2003 13:58, Kurt Bigler wrote: >> on 2/21/03 10:07 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>> On Friday 21 February 2003 11:55, Dale wrote: > > > >> >> I would appreciate it if you could comment on whether your solution based >> on IP etc will make it unnecessary to do what I was suggesting in my >> original response to this thread. Although I currently use vpopmail, I >> would prefer a solution that does not depend on vpopmail. I would >> definitely like the solution to be able to provide a _default_ rather than >> a fixed domain, so that other domains can be typed or selected from a popup >> if desired. > > As I mentioned in the original post, vpopmail users can set the > VPOPMAIL_DOMAIN > environment variable from apache to facilitate transparent domain hard-coding > per > host. However, this method only applies to vpopmail users, and doesn't allow > for > a "default" as you mention above. > > The method I am working on (mostly in my head right now) will consist of a > comma > or colon delimited flat file, with one IP:DOMAIN pair per line, as in the > example > below: > > IP1:DOMAIN1 > IP2:DOMAIN2 > etc... > > I will read the IP from the SERVER_ADDR CGI environment variable (set by > apache), > and compare this IP to the flat file above. My server is set up to do name-based virtual hosting, and so I haven't had experience with anything else. My server has only one IP address. Does what you are suggesting apply to this situation? Perhaps you are solving a problem at an entirely different level from the one I was trying to solve. So to clarify, what I would envision as a alternative to what you were suggesting, but which would solve the problem I need to solve, would be a similar table: webmail-http-domain-1:email-login-domain-1 webmail-http-domain-2:email-login-domain-2 etc. Where the first field is the HTTP_HOST value and the second field is the associated login domain. This is because I do not want to assume that it will always look like this: webmail.somedomain1.com:somedomain1.com webmail.somedomain2.com:somedomain2.com webmail.somedomain3.com:somedomain3.com For example somedomain4 might be in another language, in which the term "webmail" would not apply. So I do need such a lookup list. It could be that the logindomain list can contain an optional colon followed by the HTTP_HOST value, just reversing the fields above, possibly followed by a 3rd field specifying whether a popup list should be presented for that HTTP_HOST. This avoids having to maintain yet another list of domains, but I think gives the full desired functionality. I suspect this idea might apply to your IP-based mapping, even though I don't understand that yet. In any case, the config file idea is probably easier to use than setting an environment variable per apache virtual domains. Rolling it into the existing logindomainlist without requiring a popup would be icing on the cake. How does this relate to what you are doing? -Kurt Bigler > > I _COULD_ just do a reverse DNS lookup, but this would be undesirable, since > not > every domain has proper reverse DNS available. And it's restrictive. I dislike > restrictive programming. > > I think I can implement the next step in a two part conditional: > > 1.) If the user is using the 'logindomainlist' file, we will simply default > the > list to the DOMAIN field of the matching IP:DOMAIN record in the IP lookup > flat file. > > 2.) If the user isn't using the 'logindomainlist' file, we will create a > 'logindomain' hidden field on the login.html page with a value of DOMAIN > from the IP lookup flat file. > > All of this will make IP-DOMAIN lookups usable for non vpopmail users. A > number > of improvements can be made in the future, such as CDB lookups and such, but > this > is beyond the scope of what I'd like to implement in the near future. > > I'd also like to FIX vpopmail IP-alias domain capability in sqwebmail at the > same > time. Vpopmail _SHOULD_ be capable of automatic IP-aliasing (if enabled in > vpopmail > source and with 'vipmap') by only setting the TCPLOCALIP environment variable > equal to SERVER_ADDR in the auth module, but I can't get it to fly. > > More debugging I guess. > > Anyway, that's basically what I plan to do. Shouldn't be too hard to > implement. > > What do you think Sam? Sound decent? > > I have some time today, and hopefully over the weekend, to code. I've already > promised my users that I'll get IP-alias functionality working within a month > (two weeks ago), so I'm pretty commited to getting this done soon. > > Any thoughts/input would be welcome. > > Jesse > > >> >> Thanks, >> Kurt Bigler
Re: [sqwebmail] default domain with domain templates
on 2/21/03 10:07 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Friday 21 February 2003 11:55, Dale 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 > > If you're using Vpopmail, then you can set the VPOPMAIL_DOMAIN > variable from Apache on a per-domain basis. (This is a relatively > undocumented Vpopmail feature) [snip] > Finally, I am currently working on coding functionality for and IP to domain > lookup file that will be used by sqwebmail to automatically derive the > domain from the IP address of the CGI host. This will facilitate what you > need, I believe, but it's not ready yet, and I'm not sure when it will be. > > Good luck. > > Jesse I would appreciate it if you could comment on whether your solution based on IP etc will make it unnecessary to do what I was suggesting in my original response to this thread. Although I currently use vpopmail, I would prefer a solution that does not depend on vpopmail. I would definitely like the solution to be able to provide a _default_ rather than a fixed domain, so that other domains can be typed or selected from a popup if desired. Thanks, Kurt Bigler
Re: [sqwebmail] default domain with domain templates
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 I have a distinct webmail domain of the form "webmail.". 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
Re: [sqwebmail] sqwebmail html problems as rendered by IE 5.0
on 1/31/03 6:37 PM, Sam Varshavchik <[EMAIL PROTECTED]> wrote: > I'd like to see a sample patch for a sample html template, diffed against > the current release [snip] > Fix one file. Let me kick the tires. If it looks good, send me a patch for > two or three more HTML templates. And if that looks good too, then do the > rest. Ok, here is the final installment of fixed template files. It contains changes for 22 template files: abooklist.html attachments.html autoresponder.html eventacl.html eventdaily.html eventdelete.html eventmonthly.html eventshow.html eventweekly.html expired.html filter.html gpg.html gpgcreate.html gpgerr.html invalid.html keyimport.html ldaplist.html ldapsearch.html newevent.html quickadd.html readmsg.html spellchk.html The attachment contains the merged diff -U3 output for these files. In this and the previous 2 installments, I was conservative about changes: if it wasn't causing a problem, I didn't fix it. This means that there are still a bunch of constructs (sometimes with additional fields in the ) around in places where they appeared harmless, even though the is useless and possibly questionable as the sole content of a table cell. If it was desired to get rid of all of these, for consistency, it would be easy to do this, possibly by using a global replace of the form s|> |>| Note that an " " amidst other text in a table cell is not a problem. This is why the above replace is likely get all the questionable ones. Please let me know if you find any problems with these changes, or the previous installments. -Kurt Bigler diff -U3 en-us-orig/abooklist.html en-us/abooklist.html --- en-us-orig/abooklist.html Mon Feb 3 21:45:33 2003 +++ en-us/abooklist.htmlSat Feb 15 22:30:47 2003 @@ -33,7 +33,7 @@ [#@graytopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graytopright.gif, width="11" height="11" alt="" border="0"@@#] @@ -56,7 +56,7 @@ [#@graybottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graybottomright.gif, width="11" height="11" alt="" border="0"@@#] @@ -71,13 +71,14 @@ [#@bluetopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluetopright.gif, width="11" height="11" alt="" border="0"@@#] - + + @@ -98,11 +99,12 @@ + [#@bluebottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluebottomright.gif, width="11" height="11" alt="" border="0"@@#] diff -U3 en-us-orig/attachments.html en-us/attachments.html --- en-us-orig/attachments.html Mon Feb 3 21:45:33 2003 +++ en-us/attachments.html Sat Feb 15 22:55:06 2003 @@ -35,7 +35,7 @@ [#@graytopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graytopright.gif, width="11" height="11" alt="" border="0"@@#] @@ -58,7 +58,7 @@ [#@graybottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graybottomright.gif, width="11" height="11" alt="" border="0"@@#] @@ -77,13 +77,14 @@ [#@bluetopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluetopright.gif, width="11" height="11" alt="" border="0"@@#] - + + @@ -164,11 +165,12 @@ + [#@bluebottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluebottomright.gif, width="11" height="11" alt="" border="0"@@#] diff -U3 en-us-orig/autoresponder.html en-us/autoresponder.html --- en-us-orig/autoresponder.html Mon Feb 3 21:45:33 2003 +++ en-us/autoresponder.htmlSun Feb 16 18:03:31 2003 @@ -37,7 +37,7 @@ [#@gray
Re: [sqwebmail] sqwebmail html problems as rendered by IE 5.0
on 1/31/03 6:37 PM, Sam Varshavchik <[EMAIL PROTECTED]> wrote: > I'd like to see a sample patch for a sample html template, diffed against > the current release [snip] > Fix one file. Let me kick the tires. If it looks good, send me a patch for > two or three more HTML templates. And if that looks good too, then do the > rest. Ok, here are four more files "fixed". Combined with folders.html from last time, this takes care of the most commonly used functionality. The files changed this time are: login.html newmsg.html preferences.html folder.html The diff -U3 output for these files is attached, as 4 correspondingly named .txt files. So now that I have done this, should I have combined the 4 diffs into a single file? Would that have been easier to use with patch? (I read up on diff and patch, but it is still a little bit theoretical to me.) -Kurt Bigler --- en-us-orig/login.html Mon Feb 3 21:45:33 2003 +++ en-us/login.htmlTue Feb 11 00:19:04 2003 @@ -36,7 +36,7 @@ alt="" border=0@@#] - + [#@logo.gif, width="263" height="35" alt="SqWebMail Copyright @@ -79,12 +79,12 @@ - + [#@graybottomleft.gif, width=11 height=11 alt="" border="0"@@#] - + [#@graybottomright.gif, width="11" height=11 alt="" border=0@@#] --- en-us-orig/newmsg.html Mon Feb 3 21:45:33 2003 +++ en-us/newmsg.html Tue Feb 11 00:30:27 2003 @@ -73,7 +73,7 @@ [#@graytopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graytopright.gif, width="11" height="11" alt="" border="0"@@#] @@ -96,7 +96,7 @@ [#@graybottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graybottomright.gif, width="11" height="11" alt="" border="0"@@#] @@ -111,13 +111,14 @@ [#@bluetopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluetopright.gif, width="11" height="11" alt="" border="0"@@#] - + + @@ -129,11 +130,12 @@ + [#@bluebottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluebottomright.gif, width="11" height="11" alt="" border="0"@@#] --- en-us-orig/preferences.html Mon Feb 3 21:45:33 2003 +++ en-us/preferences.html Tue Feb 11 00:35:41 2003 @@ -28,7 +28,7 @@ [#@graytopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graytopright.gif, width="11" height="11" alt="" border="0"@@#] @@ -51,7 +51,7 @@ [#@graybottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graybottomright.gif, width="11" height="11" alt="" border="0"@@#] @@ -66,13 +66,14 @@ [#@bluetopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluetopright.gif, width="11" height="11" alt="" border="0"@@#] - + + [#P#][#x#] @@ -277,11 +278,12 @@ + [#@bluebottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluebottomright.gif, width="11" height="11" alt="" border="0"@@#] --- en-us-orig/folder.html Mon Feb 3 21:45:33 2003 +++ en-us/folder.html Tue Feb 11 00:28:19 2003 @@ -46,7 +46,7 @@ [#@graytopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graytopright.gif, width="11" height="11" alt="" border="0"@@#] @@ -69,7 +69,7 @@ [#@graybottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graybottomright.gif, width="11" height="11" alt="" border="0
Re: [sqwebmail] sqwebmail html problems as rendered by IE 5.0
on 2/4/03 3:16 PM, Sam Varshavchik <[EMAIL PROTECTED]> wrote: > Kurt Bigler writes: > >> Ok, hopefully my Macintosh client gives you the text attachment in the >> desired form in this email. From what I see on this end it should be ok. > > No, it's not. Lines should be terminated by ASCII LF, not ASCII CR. Sorry, here's the attachment again with the correct line-endings. --- en-us-orig/folders.html Mon Feb 3 21:45:33 2003 +++ en-us/folders.html Mon Feb 3 21:54:31 2003 @@ -45,7 +45,7 @@ [#@graytopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graytopright.gif, width="11" height="11" alt="" border="0"@@#] @@ -68,7 +68,7 @@ [#@graybottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graybottomright.gif, width="11" height="11" alt="" border="0"@@#] @@ -141,13 +141,14 @@ [#@bluetopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluetopright.gif, width="11" height="11" alt="" border="0"@@#] - + + @@ -248,11 +249,12 @@ + [#@bluebottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluebottomright.gif, width="11" height="11" alt="" border="0"@@#]
Re: [sqwebmail] Re: sqwebmail html problems as rendered by IE 5.0
on 2/3/03 8:28 PM, Sam Varshavchik <[EMAIL PROTECTED]> wrote: > Kurt Bigler writes: > >> Ok, here is one file fixed (or so I hope) as Sam requested. >> >> I only made the changes that were essential to fix the problems that were >> visible to me. > > I can't see any visual differences, with this patch applied, and I have all > the options turned up. It looks exactly the same in Mozilla. Good. That's the desired result, right? The hope was to fix the problems in which there are white gaps between the round corners and the other table cells in browsers that have that problem, including IE 5.0 for Mac. Mozilla had no such problem, so the rendering should be nearly identical. There is one difference however: the blue area at the bottom has a little more margin on the left side of the content of the middle-middle table cell, resulting from the fact that this cell is no longer colspan=3, but rather confined to the middle cell on the middle row. The colspan change is required to eliminate part of the problem in IE/Mac, but has the side effect of changing the content positioning elsewhere. To me this positioning change actually looks a little better. > You should definitely fix line wrapping. I can accept MIME attachments, so > you can simply attach the diff output. Save the diff output as > filename.txt, so that your client will create a text/plain attachment. Ok, hopefully my Macintosh client gives you the text attachment in the desired form in this email. From what I see on this end it should be ok. --- en-us-orig/folders.html Mon Feb 3 21:45:33 2003 +++ en-us/folders.html Mon Feb 3 21:54:31 2003 @@ -45,7 +45,7 @@ [#@graytopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graytopright.gif, width="11" height="11" alt="" border="0"@@#] @@ -68,7 +68,7 @@ [#@graybottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graybottomright.gif, width="11" height="11" alt="" border="0"@@#] @@ -141,13 +141,14 @@ [#@bluetopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluetopright.gif, width="11" height="11" alt="" border="0"@@#] - + + @@ -248,11 +249,12 @@ + [#@bluebottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluebottomright.gif, width="11" height="11" alt="" border="0"@@#]
Re: [sqwebmail] Re: sqwebmail html problems as rendered by IE 5.0
on 1/31/03 6:37 PM, Sam Varshavchik <[EMAIL PROTECTED]> wrote: > Jesse Guardiani writes: > >> IMHO, it would be nice to see these changes incorporated into the distro. >> >> Especially if they don't hinder viewing from other browsers. >> >> Sam? What do you think? > > I'd like to see a sample patch for a sample html template, diffed against > the current release [snip] > Fix one file. Let me kick the tires. If it looks good, send me a patch for > two or three more HTML templates. And if that looks good too, then do the > rest. > > Oh, and use diff -C or diff -U. A plain diff is just plain worthless. Ok, here is one file fixed (or so I hope) as Sam requested. I only made the changes that were essential to fix the problems that were visible to me. Not all features are enabled in my installation - no calendaring for example. I don't know if additional problems would have shown up if additional features were enabled. I will appreciate feedback from Sam and others willing to apply this change and try it via their favorite (or most hated) browsers. You can find the diff -U3 output for my changes to folders.html here: http://breathhost.net/html/diffs/folders.txt I have never used a patch, so I hope this is really what is needed. The diff is against the templates included with sqwebmail-3.5.0. Giving the above link avoids the problems of line-wrapping that I was having in my email client. If you have a better idea, or if for some reason you would prefer an alternative to -U3, just say so. I can set up a cgi to run the diffs for this whole sequence of upcoming changes easy enough. In case you just want to see the output here, complete with line-wrapping problems, it is pasted in below. -Kurt Bigler P.S. Diff -U3 output follows. It looks from here like only 1 line was damaged by a wrap that my email client forced. --- en-us-orig/folders.html Mon Feb 3 21:45:33 2003 +++ en-us/folders.html Mon Feb 3 21:54:31 2003 @@ -45,7 +45,7 @@ [#@graytopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graytopright.gif, width="11" height="11" alt="" border="0"@@#] @@ -68,7 +68,7 @@ [#@graybottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@graybottomright.gif, width="11" height="11" alt="" border="0"@@#] @@ -141,13 +141,14 @@ [#@bluetopleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluetopright.gif, width="11" height="11" alt="" border="0"@@#] - + + @@ -248,11 +249,12 @@ + [#@bluebottomleft.gif, width="11" height="11" alt="" border="0"@@#] - + [#@bluebottomright.gif, width="11" height="11" alt="" border="0"@@#]
Re: [sqwebmail] Logging out when refreshing the page
on 2/3/03 10:44 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > On Monday 03 February 2003 12:26, home wrote: >> Dear all, Sorry if this has already been posted, I can't find the >> archives. If a user logs in to sqwebmail and the hits f5 (refresh page) it >> dumps them back to the login page. Is there any way to stop this >> happening? I have 'grep'ed the source files for any mention of this but to >> no avail. > > I can hit refresh all I want and never have a problem. > > Are you behind a firewall that does NAT? The same thing happens to me, so I have just learned not to use refresh, as someone else suggested. However this is unfriendly, since clicking on the link you are already on (Folder) is not the expected way to cause a refresh. I am behind a LinkSys router, which has minimal firewall capabilities, but does not interfere with http as far as I am aware. > >> >> Regards >> >> Jonathan
Re: [sqwebmail] Re: sqwebmail html problems as rendered by IE 5.0
on 1/31/03 6:37 PM, Sam Varshavchik <[EMAIL PROTECTED]> wrote: > Jesse Guardiani writes: > >> IMHO, it would be nice to see these changes incorporated into the distro. >> >> Especially if they don't hinder viewing from other browsers. >> >> Sam? What do you think? > > I'd like to see a sample patch for a sample html template, diffed against > the current release (the crap with 0xA0 hard spaces, which were put there by > an old version of Amaya, have been fixed several releases ago). > > I don't want anyone to go through the trouble of trying to fix all the > files, and have me reject it because of my legendary capricious nature. > > Fix one file. Let me kick the tires. If it looks good, send me a patch for > two or three more HTML templates. And if that looks good too, then do the > rest. Ok, I can probably start this in the next few days. Do I have to worry about another new release of the templates coming out during this process if it ends up taking a couple weeks? Will it work if I apply the templates from the current release to my 3.3.1 install to avoid doing the full install right now? > Oh, and use diff -C or diff -U. A plain diff is just plain worthless. I'll be sure to use -C or -U when I submit the next piece of information. But what do you need for a patch - do you need a diff -e for that? Sorry I have not been involved in patches yet, neither generating nor applying them. -Kurt Bigler
[sqwebmail] sqwebmail html problems as rendered by IE 5.0
Using sqwebmail-3.3.1, I discovered some problems with the webmail rendering in Internet Explorer 5.0 for Macintosh. There were no problems with other browsers that I know of, but a lot of people I know are using this browser. I made some experimental changes (more detail below) to the sqwebmail html templates which appear to have fixed the problem, without causing any problems in other browsers that I have tested. The problem seen in IE 5.0 is that the round corner gray or light blue gifs do not join seamlessly with the other table cells having a matching background color. The solution requires around 9 individual changes per affected html template file. At least this is true for folders.html, the template for the "Folders" page. There is a curious thing which occurs in these files, and perhaps there is some reason for it that someone can fill me in on. In quite a few places there are some non-printing characters between a and the corresponding . These characters trigger about half of the problems I was seeing in IE with the alignment of the round corners. The characters appear in vi as "\xa0" (quotes mine) a display of 4 characters used to indicate the single character. I take it this is a character with hexadecimal value a0, which would be like a space, but with the high bit set. Apparently the presence of these characters causes the cell height of the middle-top and middle-bottom table cells to take on the height of the font currently in effect, which in this case turns out to be taller than the round-corner gifs. Removing these characters eliminates the vertical aspect of the round-corner alignment problem. This takes care of all the problems in the upper gray table area which appears on most pages. The lower light blue table area also has a horizontal problem which is apparently caused by IE getting confused about the colspan="3" which is used in the middle row of the bottom table. It is easy enough to work around this problem by eliminating the colspan (or changing it to 1) and adding two new empty cells for the narrow columns to the left and right of the previouly colspan 3 cell. This change eliminates the horizontal aspect of the round-corner alignment that appears in the light blue area. The first change of eliminating the extra characters between and seems highly advisable in any case, from what I can tell, but please inform me if you know more. For example O'Reilly's Web Design in a Nutshell in Chapter 10, page 188 has this to say: Returns and spaces with s The problem most often lites within the cell () tag. Some browsers will render any extra space within a tag, such as a character space or a line return, as white space in the table. The chracter in question actually appears to behave as a space on the Mac. I did not check what kind of space it is. The second change, involving eliminating the colspan, also does not have any adverse consequences that I can see. It is slightly less efficient in use of horizontal space, this does not appear to be a problem. At least in most cases the contents of the blue area do not require up a lot of horizontal space. The change has the result of increasing the margin around the content. To me this change is actually an improvement even in browsers that do not have the alignment problem. There are other places where the "\xa0" characters appear but cause no problem. As an example, here is the output of diff for the changes I made. I might have eliminated some spaces that were not actually causing a problem, but I think that at most 2 of the changes might be extraneous. Note that the "\xa0" characters appear (at least to me) as spaces here: 47c47 < --- > 53c53 < --- > 65c65 < --- > 70c70 < --- > 144c144 < --- > 150c150,151 < --- > > 248a250 > 253c255 < --- > I hope this information is of some use. If these changes are good idea, it would be nice if they could make it into a future version of sqwebmail. It did not take me very long to make these changes in my template files, maybe an hour. The patterns are almost identical everywhere they occur: the space between and and the colspan="3". Regards, Kurt Bigler
Re: [sqwebmail] (CODE Q) floating curly braces
on 1/29/03 10:16 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> Actually, this appears to be part of the if statement before it.
>
> A complete listing would be this (again, from main2() in sqwebmail.c):
>
> if (!ip_addr) ip_addr="127.0.0.1";
The above is a one-line if statement. With no braces immediately after the
if closing parenthesis, only the single statment ip_addr="127.0.0.1" is
conditionally executed.
Many people prefer to use indentation clarify it:
if (!ip_addr)
ip_addr="127.0.0.1";
Other people would like to see the braces even if they are not required:
if (!ip_addr)
{
ip_addr="127.0.0.1";
}
and using the braces there would certainly reduce the visual ambiguity (for
some of us).
>
> umask(0077);
The umask is executed unconditionally, as is the block below.
>
> {
> const char *p=getenv("SQWEBMAIL_TIMEOUTHARD");
>
> if (p && *p)
> timeouthard=atoi(p);
> }
The block (probably should be called a "compound statement"?) restricts the
scope of the variable p, which can be useful in making code more readable,
and potentially to help the optimizer.
Whever a block like this follows something above it that looks like it might
have a block following it, it can be confusing. I have been confused by
code like this, some of which I had written.
But this is all pretty much a matter of opinion. We all see code
differently, and have different processes for interacting with it.
Basically I think we each try to develop ways of coding that reduces the
number of mistakes we make when we are maintaining our own code. For those
who can not type fast, shortcuts will also be desirable.
>
> I understand the curly braces now, I think, but when are the lines
> before the curly braces (and after the 'if') executed?
>
> Always?
>
> Very confused. Thanks.
>
> Jesse
>
>
> On Wednesday 29 January 2003 12:47, Jesse Guardiani wrote:
>> Mr. Sam,
>>
>> I noticed that you use "floating" curly braces throughout Sqwebmail,
>> like this (taken from main2() ):
>>
>> umask(0077);
>>
>> {
>> const char *p=getenv("SQWEBMAIL_TIMEOUTHARD");
>>
>> if (p && *p)
>> timeouthard=atoi(p);
>> }
>>
>>
>> I've never seen that done before.
>>
>> Why do you do that?
>>
>>
>> Thanks,
Re: [sqwebmail] Re: Import Outlook address book?
on 1/27/03 2:41 PM, Sam Varshavchik <[EMAIL PROTECTED]> wrote: > Benjamin Smith writes: > >> What's the easiest way (short of re-typing) to inport an Outlook address book >> into SQWebmail (or synch?) > > sqwebmail's address book is a plain text file, with a rather simple, obvious > format. > > If you can manage to get your Outlook to spit out the address book in some > semi-parsable plain text file, a Perl script should be able to do the rest. In Outlook Express for Macintosh, the method I have used for generating the plain text file as input is: (1) select the entire content of your address book (2) click the New Message To button (3) Save the message so it appears in Drafts (required for step 4) (4) select View Source The last step gives you a window you can copy/paste from which looks like: User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.3 Date: Tue, 28 Jan 2003 21:30:40 -0800 Subject: From: Kurt Bigler <[EMAIL PROTECTED]> To: Joe <[EMAIL PROTECTED]>, Jack <[EMAIL PROTECTED]>, Jill <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The details for Outlook are probably different, but with any luck you can do it there too. But I wish it were even easier! And I would like to provide a way that any with an account on my server could do this, by just sending the message like the one above to some special email address. But getting off-topic here. -Kurt Bigler
