>SquirrelMail is still in the final phases of approval here at TI, the only >remaining thing we are waiting on is documentation and communication.. >(30,000 users makes deploying a new product a very time consuming effort) >from my perspective, this has been one of the best products we've brought >in to TI so far.. our old webmail reader (Java based) is *seriously* due to >be replaced, and when I rolled out a demo of SquirrelMail on my Sun >workstation (a Blade 100, Ultrasparc IIe/500 MHz 512mb RAM), I never >expected the results.. on word of mouth only, over 250 people are regularly >reading their e-mail from my "test" installation of SquirrelMail, with no >training or documentation (other than SquirrelMail's built in help system).
Thank you for taking the time to write this email and share it with the rest of us.I find it very useful information and appreciate the time and effort spent in writing it.Like you I am using and testing as well a variety of webmail systems,however, at a much smaller level of 800+ users. Over the course of the past 3 months I have gathered a lot of information and have a pretty good idea as to what the issues are for webmail systems in general. While I have been using Linux for years and years, and thus free software in general, I have come to appreciate PHP and Apache which have shaped up to be an excellent web server and development platform bar none. Now I would like to make it clear right now that the text that follows is not meant to be a war against Squirrel Mail or any other webmail package. I like SM to a very respectable level,and it's developer base seem to be much more friendlier than a lot of 'free' or 'open source' projects I've monitored over the years. >Picking plugins has been an interesting adventure - SquirrelMail in itself >provides some nice basic functionality, but there were a few that I have >added that make sense for our environment - since we're a mixed environment >(Solaris/Cyrus/Sendmail and Exchange 5.5/Exchange 2000), the >attachment_tnef plugin makes decoding the winmail.dat files easier.. Cyrus >supports a server side filtering language known as Sieve, and the avelsieve >plugin makes managing rules very nice and speedy (the SquirrelMail >"filters" plugin tends to slow SM down quite a bit if you write more than a >few rules). Visual plugins like msg_flags and legend are helpful for >usability, and the IMAP quota_usage plugin gives the end user a good idea >of how close they are to having a full mailbox. I have found the SM plug in capability superior and is probably its finest feature if I had to choose only one. Still, there is much work to be done because there is no single 'authentication' mechanism amongst the different plug ins, no common interface in place to allow plug in capability to groups which is extremely important in a diverse environment. Further, only a small subset of components in the SM environment support a database back end, without which makes it more difficult to scale, and to administrate. In contrast the Horde framework has a very rich database back-end functionality using PEAR and subsequently scalable is more mature in this respect. Filtering at the IMAP level is very inefficient. This is why I use procmail and let postfix use it to deliver the mail. Doing it in this way will have no noticeable performance issues that I've been able to see. For my use, I have chosen Courier Imap because it is very light weight memory wise and it has performed just fine. Running this on Dell PowerEdge 2600, Raid5, dual 2.4G Xeon's and 4G ram. It may seem overkill, but this machine provides a variety of services other than web. >I'm also using timeout_user to keep people from staying logged in >indefinitely, even though you can't protect some users from themselves. One >plugin I really want to employ is the view_as_html plugin - since I have >the default set to viewas plaintext (and I want to encourage non-HTML >e-mail viewing) this gives the user a quick way to switch to HTML on a >per-message basis, in hopes that they will not change their preferences to >"View as HTML" by default. HTML e-mail really does make things messy- for >example, some embedded style sheets screw up the SquirrelMail interface, >and other messages that contain images become a problem to display (for >example, if the base url for images is in the HTML head tag, SquirrelMail >strips the head section since it has already generated one, so using >embedded images (img src="cid:MIME-content-ID";) or using a full URL becomes >important for an end user to actually see the message as the author >intended.) Indeed. In fact this is something that Horde/Imp is missing entirely and is quite problematic in general on workstations that are shared by different users. The timeout_user solves a lot of problems. I feel your pain on the HTML viewing. Fortunately for us, we are on a private wan, and a lot of users are not allow email to or from the Internet. So HTML messages are not so great a security risk as they might be otherwise. Still, I try to lock down a lot of options and do not allow the end users to make very many changes. It reduces support issues, and most of our users are not all that technical anyway so they never miss the functionality to begin with. IMP seems to center their functionality a lot around IE and I think this is wrong. Besides, it does not do us a whole lot of good anyway, since we do not use IE; either Konqueror or Mozilla. So in the name of supporting the 'most commonly used' browser, they continue to contribute to it's status quo by concentrating functionality using IE, and for some things this is not good. >Using aspell (and configuring the squirrelspell plugin appropriately for >aspell) makes things very nice- I have 4 language dictionaries in place, >and it works very well. I had to clean up the timezones >(locale/timezones.cfg and the 'zic' command to generate "missing" ones), as >well as the multiple SquirrelMail "interface" languages make this one of >the better products to support international users - since we have a number >of users in Asia that will be using SquirrelMail.. by the way, PHP 4.3.2 >was needed to get some of the multibyte stuff working properly. I've had to make some small sysctl mods to kernel parameters especially when aspell is in use by a lot of concurrent users on really large email. It would be nice if aspell supported a mysql back-end, but I've not heard of any project working on anything like this. but you did not allude to having any performance issues with this. >In an effort to squeeze as much performance out of SquirrelMail as >possible,I've been using the PHP accelerator >http://www.php-accelerator.co.uk/) and the IMAP Proxy >(http://www.imapproxy.org/) and this makes things lightning fast.. >the only concern I've seen here is some users complaining about the proxy >server not working well (IMAP connections being dropped?) - my workaround >was to place the IMAP proxy ON the actual IMAP post office, and I haven't >had any noticeable problems out of this. Tried several, ended up using the zend_optimizer which seems to do a better job and is more stable for me. Tried the imapproxy but it does not seem to give any benefit for only 800 or so users. Or at least that has been my experience. >For usability, I'm considering disabling some of the themes- I can see it >now, some user complaining all of their e-mails are blank, because of a >whacky color scheme in an HTML e-mail.. and while the rotating themes is a >novel idea, this is sure to really confuse someone. I don't mean to sound like I'm ingrateful to the developers of the themes, but a pox on the one's that change!! These themes generate help desk incidents. I've had the help desk people beg me to remove them, but compromised and figured out the best colors and made them static. So at least they didn't lose all the themes (there seems to be more rotating themes than not). >The only remaining issue I'm investigating is trying to figure out how to >store preferences in a database and use the multilogin plugin so I can have >a single instance of SquirrelMail accessing all of our IMAP post offices >(for an external single-point webmail server) and sharing preferences with >the internal instances of SM - I believe this is possible, but it looks to >be somewhat tedious. I think your answer is to just look at how Horde does it's back ends. Database back-end support in SM is very immature. SM lacks the ability to have true distribution lists, and even it's global address book capability is primitive and inflexible for all but the smallest setups. The 'global' address book is a hack, it's not paginated, and has serious enough usability issues to render it almost useless. And this, coupled with lack of mature database back-end support is in my opinion what makes SM fall short of being an otherwise great Enterprise solution. Nothing that adding some code won't fix :). Oh I'm not a Horde zealot either. It has it's usability problems as well, and the developers seem to focus primarily on IE compability which is very much a problem for me. Configuring Horde to use everything in a database back-end can be problematic if you make changes to the code, and while their back ends are more mature, they are highly inefficient. The SQL code needs 'much' work. Looking at the mysql log of a typical session will show a horrendous amount of session data that renders horde/imp to be much slower than SM. But they have a decent framework to work in, and I'm thinking seriously about yanking out IMP and porting SM over to it. SM would benefit tremendously by interfacing with Turba and Kronolith. Or to have plug in equivalents of these programs. The current shared calendar is a step in the right direction. But have had trouble when there are tens of dozens of shared calendars in active use. My biggest problem with web mail in general, is none of them seem to know how to word wrap text in an intelligent manner. Text formatting takes effort and is in my experience less than perfect at least in konqueror and Mozilla and if not careful can result in an email that looks as if a 6 month old child had been tapping the enter key at random places in the text. Very very annoying and is without a doubt the #1 complaint I hear. Sm seems to have this problem a little less than IMP but the problem is still there. > The only thing I haven't seen in SquirrelMail is a plugin to use wvWare >(and xlhtml) to render MS Word/Excel/Powerpoint files as HTML in the >reader.. sure >wvWare may be a best attempt (and knowing how MS behaves it >probably won't work with the next version of office), but not having to >boot a PC to launch word or fire up StarOffice just to read an attached >.doc was a great time saver. I turn this stuff off in IMP. IMP doesn't render inline html nearly as good as SM does. wvWare and xlhtml are immature, and current versions can crash the browser. I've found them of only marginal use, but I've learned that my world is not back and white. Other people would consider this an important feature they could not live without. SM needs a decent preview, or at least my users seem to think it does. I've already added 'Tool Tips' previews ala IMP to SM CVS. Let me rephrase that. My version of SM CVS which I've not updated in a while has it. Works much the same way as IMP does and is easy to implement. Unfortunately I got tired of having to repatch the sources every time I updated the snapshot so I stopped bothering. Maybe if I submitted the code, the SM folks might add it. What a concept :). I should probably try it sometimes. >If there is interest from a few others, I would love to see a list (or >wiki-doesn't matter to me) with notes on large-scale rollouts of >SquirrelMail! You bet there is.. provided my very verbose reply has not put you and everyone else asleep. Cheers Ron ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 -- squirrelmail-users mailing list List Address: [EMAIL PROTECTED] List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id)95 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
