[sqwebmail] Re: customizing sqwebmail, nwe look
As told to me off-list by matti, if you go to the demo page https://karhula.taivassalo.fi/cgi-bin/demo and login explicitly then you get the usual sqwebmail-in-frames. Regards, Brian.
[sqwebmail] Re: customizing sqwebmail, nwe look
Brian Candler writes: As told to me off-list by matti, if you go to the demo page https://karhula.taivassalo.fi/cgi-bin/demo and login explicitly then you get the usual sqwebmail-in-frames. If you tried it and it works then the thing is actually secure after all and the apparent insecurity is an artefact of the way he set up his demo. Which makes his demo a less-than-effective test because it does not reproduce actual working conditions in at least one respect. And that defect is a rather unusual one coming from somebody who claims to be concerned by usability issues. Either you make the demo work exactly like the real thing or you document the differences, *if you understand them*. The fact that he did not immediately, upon first criticism, explain that it was merely an artefact of the test implies to me that he had no understanding of what people were complaining about or why people had an issue with it. OK, it's probably safe to use as far as the URL hiding goes. Dunno about you, but for various reasons it just doesn't appeal to me. YMMV. -- Paul Allen Softflare Support
[sqwebmail] Re: customizing sqwebmail, nwe look
Brian Candler writes: On Tue, Sep 30, 2003 at 09:27:00AM +, Paul L. Allen wrote: Not only that, most of the new functionality, which is in demand, is missing from your implementation. When you say something like that, perhaps you could reference an explicit list of those things which you think are missing? Riwos' combined folder/message view and the clean templates without rounded corners are two very big improvements IMO. I would drop sounds entirely though; that's just an annoyance and a waste of code. The amount of customisation which should be possible using *only* CSS is huge. Have a look at http://www.csszengarden.com/ for some superb examples. If sqwebmail could work in that model, then we could happily allow end-users to customise their templates without meddling with the HTML at all. That of course would mean dropping explicit support for non-CSS browsers, since sqwebmail purposely mixes CSS and non-CSS attributes to get some reasonable rendering on ancient browsers. Personally I would go that route; the number of users without CSS1-aware browsers must be pretty small by now, and the page would render visibly anyway. But I do think it's important to support text-only browers (for accessibility) and non-Javascript browsers (for security). (csszengarden renders perfectly cleanly under lynx, incidentally) Regards, Brian. Brian, thanks for an excellent css reference site. George
[sqwebmail] Re: customizing sqwebmail, nwe look
matti writes: [...] Comments are welcome. One of the points you seem proud of is that you have eliminated frames. Yet a cursory inspection of the SECURITY readme shows why frames are used. The fact that you blithely eliminate a security feature without apparently understanding why it is there scares me. If you miss the blindingly obvious, what else have you missed? Not only that, most of the new functionality, which is in demand, is missing from your implementation. If there were one change I could make to sqwebmail and have it included in the mainstream version, it would be to adopt the mechanism (or something with similar functionality) in the newer releases of qmailadmin for multilingual support. Instead of Username the templates would have #001 (or something along those lines) and that would be substituted by the appropriate language file. Something like that would be for more likely to generate multilingual support. Qmailadmin has not had this feature for long but already there are many translation files. Sqwebmail has had its multilingual support far longer and still only supports US English because it is a nightmare trying to translate the templates. -- Paul Allen Softflare Support
Re: [sqwebmail] Re: customizing sqwebmail, nwe look
On Tue, Sep 30, 2003 at 09:27:00AM +, Paul L. Allen wrote: Not only that, most of the new functionality, which is in demand, is missing from your implementation. When you say something like that, perhaps you could reference an explicit list of those things which you think are missing? Riwos' combined folder/message view and the clean templates without rounded corners are two very big improvements IMO. I would drop sounds entirely though; that's just an annoyance and a waste of code. The amount of customisation which should be possible using *only* CSS is huge. Have a look at http://www.csszengarden.com/ for some superb examples. If sqwebmail could work in that model, then we could happily allow end-users to customise their templates without meddling with the HTML at all. That of course would mean dropping explicit support for non-CSS browsers, since sqwebmail purposely mixes CSS and non-CSS attributes to get some reasonable rendering on ancient browsers. Personally I would go that route; the number of users without CSS1-aware browsers must be pretty small by now, and the page would render visibly anyway. But I do think it's important to support text-only browers (for accessibility) and non-Javascript browsers (for security). (csszengarden renders perfectly cleanly under lynx, incidentally) Regards, Brian.
[sqwebmail] Re: customizing sqwebmail, nwe look
One of the points you seem proud of is that you have eliminated frames. proud ? Yet a cursory inspection of the SECURITY readme shows why frames are used. The I have not changed this. Matti Riikari email [EMAIL PROTECTED] tel +358405544545 mail Paltvuori 23310 Taivassalo FIN web http://www.riikari.net _
[sqwebmail] Re: customizing sqwebmail, nwe look
Brian Candler writes: On Tue, Sep 30, 2003 at 09:27:00AM +, Paul L. Allen wrote: Not only that, most of the new functionality, which is in demand, is missing from your implementation. When you say something like that, perhaps you could reference an explicit list of those things which you think are missing? They are listed in the horrible readme (if he thinks that is good web design then I am worried). I can see some of our clients with dedicated mail servers wanting the GPG functionality. I can see more of our clients wanting the calendaring stuff, even though the user interface is awkward. But the biggest demand is the mail filters. Exchange (spit) allows you to set up rules that filter mails and delivers selected messages to a sub-folder. Exchange allows vacation messages (done sensibly, not the qmailadmin/autoresponder broken way). People WANT those things. They want them a LOT. They want them enough that if we cannot offer equivalent functionality they will go to an ISP running Exchange (spit) servers. Sqwebmail with maildrop offers equivalent functionality. Riwos does not. Yes, the filters are relatively new to Sqwebmail, but that is no excuse for Riwos not to have them. You and I might be able to live without those features, but the people we are trying to sell accounts to are unwilling to. Riwos' combined folder/message view Dunno about that. I went to his page, skimmed through it and didn't see any obvious info about the test account. But I didn't look very hard after I read that he was proud of losing a security feature. Yes, I hate frames, but Sqwebmail uses them for a reason (there are other solutions to the security problem but buttons are rather clunky and a JavaScript solution locks out Lynx). and the clean templates without rounded corners are two very big improvements IMO. You, sir, are a techy. My PHB *loves* the rounded corners. They are the sort of touch that give PHBs orgasms. Our users love them even more. I hate anything that slows things down with needless graphics, but I too am a techy. I would drop sounds entirely though; that's just an annoyance and a waste of code. Riwos has sounds? I am glad I didn't find the test account. Seriously, I can see some people liking them. But they'd have to be something you could enable or disable as a preference. And I would still like the timezone to be a preference rather than a login option. If you're not in the server's timezone then selecting your timezone each time you login is a pain. The only good thing I saw in the blurb about Riwos was the warning that your session was about to expire. But I would rather Sqwebmail/Riwos had some mechanism of saying Your session expired while you were creating that message, which is reproduced below, login again and I'll send it. Too many people (including me) have been bitten by that one. :( Even though I have now learned to copy the message if I think my session is about to expire, too often I forget. The amount of customisation which should be possible using *only* CSS is huge. I know. CSS is under-utilized by most people. :( That of course would mean dropping explicit support for non-CSS browsers, since sqwebmail purposely mixes CSS and non-CSS attributes to get some reasonable rendering on ancient browsers. Personally I would go that route; I did that for years to ensure compatibility with browsers that are now ancient. These days I use just CSS, but try to limit myself to stuff that works reasonably sensibly on older browsers. the number of users without CSS1-aware browsers must be pretty small by now, Lynx is your friend. :) -- Paul Allen Softflare Support
Re: [sqwebmail] Re: customizing sqwebmail, nwe look
On Tue, Sep 30, 2003 at 10:23:03AM +, Paul L. Allen wrote: Not only that, most of the new functionality, which is in demand, is missing from your implementation. When you say something like that, perhaps you could reference an explicit list of those things which you think are missing? They are listed in the horrible readme (if he thinks that is good web design then I am worried). Oh I see what you mean: new functionality already in sqwebmail is missing from riwos. I originally read it as there are new functions which are missing from sqwebmail which are also missing from riwos Exchange allows vacation messages (done sensibly, not the qmailadmin/autoresponder broken way). Now that I *strongly* disagree with. Exchange's autoresponders are totally broken. Auto-replies are sent to mailing list messages; and replies are sent to the From: header and not the envelope-sender (Return-Path:). I do auto-responders using an LDAP attribute and exim, by the way. Users can't use sqwebmail to set them, so they have to go in through our database 'self-care' interface. Riwos' combined folder/message view Dunno about that. I went to his page, skimmed through it and didn't see any obvious info about the test account. Yes it was not obvious from the given link, you have to click something like home page then test it which takes you to http://riikari.net/cgi-bin/test.cgi and the clean templates without rounded corners are two very big improvements IMO. You, sir, are a techy. I am, but that's an orthogonal issue. Hard-coding this design in the HTML is very poor, and more importantly, the existing design does not allow the colours of the boxes to be changed in the stylesheet; you are stuck with Laura Ashley grey and blue. I have patched the templates to allow those colours to be changed in the stylesheet, but those patches have not made it into the source distribution. There's no way I will let our users touch the HTML itself; it would lock us in to one version of sqwebmail and make it impossible to upgrade in future without manually tweaking *all* their templates to match. I would drop sounds entirely though; that's just an annoyance and a waste of code. Riwos has sounds? I am glad I didn't find the test account. Seriously, I can see some people liking them. But they'd have to be something you could enable or disable as a preference. You can (and it's off by default). But it's an unnecessary option IMO; it simply shouldn't be there in the first place. Smacks of hey I'm clever, I can code HTML which makes sounds in your browser. Like all those old Flash-based websites which were packed-full of animation which made it completely impossible to view the actual content. Regards, Brian.
[sqwebmail] Re: customizing sqwebmail, nwe look
Brian Candler writes: Oh I see what you mean: new functionality already in sqwebmail is missing from riwos. I originally read it as there are new functions which are missing from sqwebmail which are also missing from riwos Sorry if my statement was ambiguous. The new functionality in sqwebmail is one of the reasons I managed to persuade my PHB not to switch to Exchange for mail servers, because without that functionality we'd slowly lose all our clients. Exchange allows vacation messages (done sensibly, not the qmailadmin/autoresponder broken way). Now that I *strongly* disagree with. Exchange's autoresponders are totally broken. I have never, ever used Exchange, so I had to go by what others told me. It does not surprise me that Exchange's vacation responders are broken (does it still default to being an open relay and require an undocemented registry hack to stop it being wide open). But so is qmailadmin's, because it uses autoresponder which is designed to respond to everything. The maildrop responder is much smarter in many ways since it can be told to ignore certain messages based on sender, recipient address or content, and can be told not to reply to the same sender within a user-specified period, as well as ignoring mailing lists. I do auto-responders using an LDAP attribute and exim, by the way. Users can't use sqwebmail to set them, so they have to go in through our database 'self-care' interface. I prefer the Sqwebmail filters, simply because it's all in one place. The less glue and customization I have to provide, the better. and the clean templates without rounded corners are two very big improvements IMO. You, sir, are a techy. I am, but that's an orthogonal issue. Nope, you expressed an aesthetic preference there. :) Hard-coding this design in the HTML is very poor, Now that is a technical issue. And you are correct that hard-coding it is bad. But whether or not rounded-corners look better is a matter of aesthetics and, on slow lines, usability. How the corners are implemented is the technical issue. and more importantly, the existing design does not allow the colours of the boxes to be changed in the stylesheet; Also not good. :( Even Microsoft and Netscape regretted introducing their font tag abominations less than a year after they had done so. CSS is the way to do it, and has been for many years. There's no way I will let our users touch the HTML itself; Nor us. Not just because it complicates matters and increases bandwidth but from the certainty that they'll mess things up completely and then demand we fix it for them even though they're not paying for support. it would lock us in to one version of sqwebmail and make it impossible to upgrade in future without manually tweaking *all* their templates to match. That too. Nightmare time. Even tweaking the templates once to give it our look and feel is a pain. I suspect that when sqwebmail started out it was simple enough that the template design was workable but now sqwebmail complexity has outgrown it. Riwos has sounds? I am glad I didn't find the test account. Seriously, I can see some people liking them. But they'd have to be something you could enable or disable as a preference. You can (and it's off by default). But it's an unnecessary option IMO; it simply shouldn't be there in the first place. Smacks of hey I'm clever, I can code HTML which makes sounds in your browser. Actually, some people would find it useful, believe it or not. You're busy working in another window and oblivious to the passage of time. Hours later you remember to check your mail and see that you received an urgent message a couple of hours ago. I did enable sound on Nagios once so it alerted me to problems when I was working in another window but had to disable it because the sound played repeatedly instead of a one-off alert. There are times when an e-mail sound would be very useful to me, provided I could make it apply only to certain folders (don't bother me for mailing list stuff but do bother me if it's support mail). Like all those old Flash-based websites which were packed-full of animation which made it completely impossible to view the actual content. Flash is very good for animations which themselves ARE the content of the site (see, for example, URL: http://www.bushflash.com ). But when used for navigation menus and/or for presentation it should be called Flush because a site that uses it that way has gone down the toilet. Please note that my PHB, our head graphics guy and most of our clients disagree with me on that one, which is why our own site uses Flush for navigation (I hate our own site intensely - but I'm a techy). -- Paul Allen Softflare Support
[sqwebmail] Re: customizing sqwebmail, nwe look
matti writes: One of the points you seem proud of is that you have eliminated frames. proud ? So it appeared from your readme, which complained about sqwebmail's use of frames. Yet a cursory inspection of the SECURITY readme shows why frames are used. The I have not changed this. Unless I misunderstood your readme, you appear to have eliminated frames. The frames are there for security reasons and ONLY for security reasons. -- Paul Allen Softflare Support
[sqwebmail] Re: customizing sqwebmail, nwe look
So it appeared from your readme, which complained about sqwebmail's use of frames. The word frames is used once in the readme: The riwos implementation does not use frames. No complaints. Where did you read that? I've added does not use frames to create the multi viewing setup. Yet a cursory inspection of the SECURITY readme shows why frames are used. The I have not changed this. Unless I misunderstood your readme, you appear to have eliminated frames. The frames are there for security reasons and ONLY for security reasons. You did. You also missed this: All changes are focused on how to produce a good graphical output and increased usability of the application. matti Matti Riikari email [EMAIL PROTECTED] tel +358405544545 mail Paltvuori 23310 Taivassalo FIN web http://www.riikari.net _
[sqwebmail] Re: customizing sqwebmail, nwe look
matti writes: The word frames is used once in the readme: The riwos implementation does not use frames. In the sqwebmail source you will find a file called SECURITY (or SECURITY.html if you prefer that). I suggest you read one or other of them. I've added does not use frames to create the multi viewing setup. Please also add and is therefore a SEVERE security risk. You did. You also missed this: All changes are focused on how to produce a good graphical output and increased usability of the application. I am in favour of increased usability, but not when it results in a SEVERE security risk. It doesn't matter how good it looks and how usable it is if security is compromised. I am also worried by anyone who decides to recode an application without reading important files that document why certain design decisions had been taken and is also unable to figure out for himself why abandoning frames is a SEVERE security risk even without reading those files. I consider it essential to read a file called SECURITY before I install something, let alone if I want to mess with the code. Here's a hint for you. One of the reasons people want webmail is so that they can check their mail when away from their own computer, such as when making a business visit to a client or when in a library or cybercafe. In those environments, others will access the same computer after they have read their mail. Some people don't bother to log out after checking their mail with webmail, they just close the browser window. Without frames, in some circumstances, the brower history will allow other people to read that mail after the user has gone. With frames, this is not possible with most popular browsers. Here's another hint: if you looked at the URL as you used Riwos to deal with your mail, you ought to have figured this out without reading the SECURITY file. The whole point of frames in sqwebmail is to stop certain URLs appearing in the address bar and history. Your usability enhancements mean that the way webmail is used by ordinary people compromises their security. It is no good expecting them to logout rather than just closing the window. That too is a matter of usability - you have to cater for what people DO, not what you want them to do. Frames are almost always a bad thing. In this case, what is usually a major disadvantage of frames (that the content of the individual frames is not recorded in the history) is used to enhance security. Now, if you missed something as obvious as that, what might you have missed in your other changes that compromises security? I don't know, and I have no intention of doing a detailed comparison to find out. The one obvious mistake you made is enough to ensure that I will never install Riwos without me having to look for more reasons. -- Paul Allen Softflare Support
[sqwebmail] Re: customizing sqwebmail, nwe look
Paul L. Allen writes: In the sqwebmail source you will find a file called SECURITY (or SECURITY.html if you prefer that). I suggest you read one or other of them. Matti has since contacted me directly to explain that Riwos does use frames to maintain security but does not use ADDITIONAL frames for any purpose. Therefore Riwos is not a security risk in that way. Matti also suggested that I could have verified this for myself on the test account. But the details of how to get there were obscure and the documentation of the time made it clear to me that it was not worth even trying because of the security risk. I make no apology for taking the documentation at face value and assuming it to be correct... -- Paul Allen Softflare Support
Re: [sqwebmail] Re: customizing sqwebmail, nwe look
On Tue, Sep 30, 2003 at 01:24:02PM +, Paul L. Allen wrote: In the sqwebmail source you will find a file called SECURITY (or SECURITY.html if you prefer that). I suggest you read one or other of them. Matti has since contacted me directly to explain that Riwos does use frames to maintain security but does not use ADDITIONAL frames for any purpose. Therefore Riwos is not a security risk in that way. I'm not convinced. If you go to his test page, http://riikari.net/cgi-bin/test.cgi you get a button which opens in a new window: https://karhula.taivassalo.fi/cgi-bin/[EMAIL PROTECTED]password=demo Now, the test page uses Javascript to open this URL in a window with no toolbar, and so you can't see each page's URL. But if you paste the above URL directly into your browser, then you'll find that it is not inside a frame, and that each sub-page accessed does appear in your browser history. So, it does *not* appear to use frames to maintain security. It does try to use a different method (but one which would probably be bypassed if you went directly to the webmail URL) Brian.
RE: [sqwebmail] Re: customizing sqwebmail, nwe look
With this in mind, Is there any sign of any sqwebmail templates appearing yet ? Matt. -Original Message- From: Brian Candler [mailto:[EMAIL PROTECTED] Sent: 30 September 2003 15:03 To: Paul L. Allen Cc: [EMAIL PROTECTED] Subject: Re: [sqwebmail] Re: customizing sqwebmail, nwe look On Tue, Sep 30, 2003 at 01:24:02PM +, Paul L. Allen wrote: In the sqwebmail source you will find a file called SECURITY (or SECURITY.html if you prefer that). I suggest you read one or other of them. Matti has since contacted me directly to explain that Riwos does use frames to maintain security but does not use ADDITIONAL frames for any purpose. Therefore Riwos is not a security risk in that way. I'm not convinced. If you go to his test page, http://riikari.net/cgi-bin/test.cgi you get a button which opens in a new window: https://karhula.taivassalo.fi/cgi-bin/[EMAIL PROTECTED]passwor d=demo Now, the test page uses Javascript to open this URL in a window with no toolbar, and so you can't see each page's URL. But if you paste the above URL directly into your browser, then you'll find that it is not inside a frame, and that each sub-page accessed does appear in your browser history. So, it does *not* appear to use frames to maintain security. It does try to use a different method (but one which would probably be bypassed if you went directly to the webmail URL) Brian.
[sqwebmail] Re: customizing sqwebmail, nwe look
On Tue, Sep 30, 2003 at 11:34:47AM +, Paul L. Allen wrote: Exchange allows vacation messages (done sensibly, not the qmailadmin/autoresponder broken way). Now that I *strongly* disagree with. Exchange's autoresponders are totally broken. I have never, ever used Exchange, so I had to go by what others told me. I just go by the high annoyance factor of receiving Exchange autoresponses from people subscribed to mailing lists. Riwos has sounds? I am glad I didn't find the test account. Seriously, I can see some people liking them. But they'd have to be something you could enable or disable as a preference. You can (and it's off by default). But it's an unnecessary option IMO; it simply shouldn't be there in the first place. Smacks of hey I'm clever, I can code HTML which makes sounds in your browser. Actually, some people would find it useful, believe it or not. You're busy working in another window and oblivious to the passage of time. Hours later you remember to check your mail and see that you received an urgent message a couple of hours ago. That would be useful, but I don't think it notifies you on incoming mail; it's more like background sounds (at least, only the Sea scheme says it has sound) It would be hard to arrange anyway - server push? Client auto-refresh every 60 seconds? Cheers, Brian.
[sqwebmail] Re: customizing sqwebmail, nwe look
Brian Candler writes: [sound for incoming mail] It would be hard to arrange anyway - server push? Client auto-refresh every 60 seconds? Our standard mod is a meta refresh on the folder list so people can see when stuff arrives. Yes, it also means that it defeats the soft timeout, making it slightly more likely that people walk away, forget to log out, and somebody else reads their mail. However, most of our users actually prefer it that way because they were getting really fed up of having to log back in after inactivity when they were sat at their desk all the time doing other things. I can't think of any *simple* way of stopping a sound playing automatically without using JavaScript, so that would also mean that it would have to be started by the same JavaScript. But that would be necessary anyway so it can also remember the unread message count (so it didn't play each time the page refreshed or each time another mail arrived after the first unread one. Oh, and probably an option for those people who DO want it to play for each new mail even though there is already at least one unread mail. And an option for those who do really want it to sound on every refresh because the window is hidden and they went to the toilet when the mail came in (those people will then be killed shortly thereafter by their cow-orkers in adjacent cubicles, but think of it as evolution in action). Keeping a read message count updated across refreshes is left as an exercise for the reader, but a hint is available in the genesis of this thread. This one is way down my personal wish-list but I do know people who would welcome it. They're the people who have to deal with mail as soon as it arrives while also trying to do other things. Rather than having to bring the mail client window to the top every five or ten minutes, they listen for the beep. Obviously, it would have to be on a per-folder basis for those who filter incoming mail into subfolders automatically and have assign different priorities to different folders. That's feasible in JavaScript on the folder list but would not be remembered across sessions, a rework of the preferences code would be necessary to have it remembered, and I suspect that isn't going to happen. -- Paul Allen Softflare Support
