Comments on Webmail wanted

Monday 05 May 2003 2:36:16 pm

Hi

First, i want to thank you for your iniciative.

IMHO the webmail module should use IMAP because os quotas. Will you create a quota module? Even so, seen this example: everyone in a company had quota os 50MB of mail, except 10 guys with no quota limit and they save all their mail, this could be large GB of mail, I don't really know which option is the best. I still bet in IMAP.

Squirrelmail is fantastic (their plugins capacity is great), but his look is not very costumizable. Will addressbook be separated of ez :-( :-( ? Or create a plugin for squirrel to get addresses in and ez3 DB.

Best regard

Paulo Almeida

PACPI.COM Internet Consulting
http://pacpi.com

Monday 05 May 2003 3:14:52 pm

Yes, i prefer imap, just because imap already has that implemented.

To addressbook I don't seen the necessity of create a fixed form, just create something like users module. The admin can create an class with attributes that he need, webmail module only need to know the first and second name, and email address, easilly addressed to an ini file (i think).
Or (even better) to create totally the contact module of ez2.2, we need an contact class, and an email class (to enable lots of email addresses per contact). With this webmail "search" all email nodes with that the contact as parent node (i hope you understand what i am talking about :-P ).

Paulo Almeida

PACPI.COM Internet Consulting
http://pacpi.com

Monday 05 May 2003 3:52:23 pm

Gabriel,
I like your initiative in writing solutions for eZ publish and contributing to this community.

Here are my thoughts about webmail.

>- Mail storage. There are two basic possibilities for this: IMAP (in which
>case I'd use PEAR's IMAP module to avoid having cclient installed) or the
>SQL DB itself in which case you need to configure the mail server to feed
>data in there.

Personally, I think any webmail client should be built around IMAP. Why? Collaboration, collaboration, collaboration! Why would you want to rebuilt the wheel?
Remember that "integration" is part of ONE unified system so, no matter where people are, they should always be able to get their messages anywhere. This includes all folders created in the user's mailbox (inbox, drafs, sent, deleted, subfolder, etc.) This could also make eZ publish appealing for other users to migrate over :P.

>If going the IMAP route, how are the feelings about iframe'ing an existing webmail
>client (probably Squirrelmail which is by far the nicest one I've tried, the UI might
>be very 96'ish but it's fast and universally useable)

The UI should be unified with eZ publish standard template system, so if people modify the "main" template in eZ publish the webmail UI should also change. Frames should not be used because it's not supported in all browsers, let your cell phone's Web browser read those framed pages. There is also an advantage in making plain vanilla HTML pages (CSS perhaps), for example when you want to notify users that they have 96 new messages in their inbox, you might want to show it like this on a left column: Inbox (96)
As the user clicks on a new message perhaps on the right side of the window, the whole page refreshes this way updating the inbox status to: Inbox (95).

>with some modifications to allow
>for single logon? I think the GREAT advantage of that approach is that you can save
>tremendous amounts of server resources as there's no need for ezpublish to be
>invoked at all if the user is only using the webmail client.

Solutions:
1. Liberty Alliance Project (http://www.projectliberty.org)
2. Add new tables to eZ publish database with this fields to be added by the user in their profile's page:

MAIL SERVER SETTINGS:

Incoming Mail Server (IMAP):
Outgoing Mail Server (SMTP): << You will need SMTP for sending mail, IMAP can't do this!
Username:
Password:

[SAVE SETTINGS] << Button

User's name and other info can be obtained from eZ publish default user table and auto-filled by the module, but open if the users want to change it later.

I really like your idea and I wish you good luck. I wish I help you code, but I am no programmer. If you need testers let me know.

Regards,

geo

Monday 05 May 2003 4:36:25 pm

Geovanni:
That's the main reason why I'd go for IMAP, too. However, there are a certain things that I like about RDBMS backed mail storage, mostly easy audit and full text search. Then again if you do what Tony suggests and just build CRM features into ezpublish, that's mostly a moot point.

Actually, it might make sense to write a small script that parses mails and adds them into ezpublish for archiving purposes. When I come to think of it, that's probably what I'm gonna do next. It's reasonably straight forward (I have root access on all my servers so I can do whatever I want with my MTA, like piping mails into the scripts).

>The UI should be unified with eZ publish standard template >system, so if people modify the "main" template in eZ publish >the webmail UI should also change.

Not gonna happen. It's just too much work to get Squirrelmail to do that. If you want to do that, you're speaking about writing a webmail app from scratch. And I'm quite certain that I know why eZ didn't do that this time. I don't know whether you know Squirrelmail yourself, but that one does exactly what you mean WRT to sticking to HTML. It doesn't look very nice but it gets the job done. And it's fast if you're in some internet cafe that got a 33.6k uplink somewhere on the other side of the world. I happen to like to travel to distant places and there has been more than one occasion where I was thankful our webmail client was so lightweight.

projectliberty: I didnt like the Passport concept and I don't like a more open approach to the same either. In fact, I'm not gonna use sites that use that web wide single sign on crap. Bad enough they track my IP, they don't need to get force fed my data.

SMTP server is not needed, PHP's mail function takes care of that already.

User's realname, emailaddress, IMAP server/login/password can easily be stored as three new fields in the user class (first two are already there) and retrieved from there.

As to not using frames, there aren't any really useable webmail clients without them. If you want to read mail on your mobile, buy one that supports POP3 (Sony Ericsson t68i does an acceptable job, their P800 an outstanding one), WML is a seriously flawed technology and IMNSHO it's wasted time trying to render anything into WML as nobody is using it anyway.

Visit http://triligon.org

Monday 05 May 2003 5:29:28 pm

Gabriel:

>Actually, it might make sense to write a small script that parses mails and adds them
>into ezpublish for archiving purposes. When I come to think of it, that's probably
>what I'm gonna do next. It's reasonably straight forward (I have root access on all my
>servers so I can do whatever I want with my MTA, like piping mails into the scripts).

Huh?! Do you mean to add all your messages in eZ publish? What happened to whole concept of the mail server and have one centralized placed where all messages are saved? Doesn't the mail server do all the 'messaging'? Why not distribute the workload? You have to remember that eZ pulbish is a Content Management System not a Messaging System!

>Not gonna happen. It's just too much work to get Squirrelmail to do that.

I didn't know you were modifying (porting) SquirrelMail!!

>And I'm quite certain that I know why eZ didn't do that this time.

Actually, I think they didn't implement this because they didn't have the functionality written on time, but it's coming in version 3.1. Read it yourself...

eZ bulk mail
Requires some new functionality, which will be introduced in 3.1.

http://www.ez.no/developer/news/how_to_implement_ez_publish_22_functionality_in_30

>ProjectLiberty: Bad enough they track my IP, they don't need to get force fed my data.

I agree with you on this.

>SMTP server is not needed, PHP's mail function takes care of that already.

You're right. I forgot about this, but if the message could send to the mail server for delivery it would be much better. Plus a copy of the message will be sitting in the 'Sent' folder.

>User's realname, emailaddress, IMAP server/login/password can easily be stored as
>three new fields in the user class (first two are already there) and retrieved from there.

This is a good idea. :)

>If you want to read mail on your mobile, buy one that supports POP3 (Sony Ericsson t68i
>does an acceptable job, their P800 an outstanding one)

Do you think people are going to replace their mobile phone just because they don't a mail client on their phone?
Believe me, people take a lot of time to adapt to new technologies, and they are not going to buy the 'Sony Ericsson t68i'.

POP3? Again, why store your message elsewhere?

Regards,

geo

Tuesday 06 May 2003 3:25:21 am

Geovanni:

As to storing the mails in ezpublish: that allows for centralized, eternal storage of all mails. In many companies I've worked with, mail was the primary medium where any information got entered, even very important stuff you want to have for future reference.

Knowing that their email is available for everyone will also stop employees from using company email accounts for private purposes which is a good thing as it means the company has less liability.

Furthermore, you definitely want to have a central mail storage for auditing purposes, we've encountered various cases where employees sent mails that were diametral to the companies interests and in court, a central DB will come in very handy.

This doesn't mean that the users won't be able to use POP3 or IMAP for their mail retrival if they want so. It's not even really the same feature, think of it as email archive integrated into ezpublish more than a messaging solution (though you could of course push it to be a messaging solution with some more work).

ezbulkmail: is a news letter system which is trivial compared to a good webmail client. Not what I'm working on in any case.

SMTP: mail() will already send mails to SMTP hosts if you want it to. I'm not going to reinvent the wheel here. As to storing messages in Sent, that's easily done.

Mobile mail retrieval: GPRS costs in Europe are outrageous so few people in my target market will even use their phone for mails. The ones who do, already have phones capable of doing so, the other ones can't be bothered. And then there are the ones like me who actually have phones that can act as email client but can't be bothered to work with such a small screen keyboard.

POP3 is also easily provided by running another daemon. Many environments will actually be running IMAP and POP3 side by side, accessing the same storage, not a problem at all.

Visit http://triligon.org